Guidence for integration of RVfplib into eclipse RISC-V projects.

[CharlesScoville]

I'll try to keep it as short as possible so as not to waste your precious time...

Both Espressif's RISC-V and WCH's RISC-V IDE offerings are built on some form of Eclipse.

RVfplib is a hand tuned assembler floating point library targeting the RISC-V ISA.

I would very much like to use RVfplib in either or both environments, but I can't seem to translate that library's instructions into something I can use in eclipse.

....I expect this to be very simple. It is simple enough from the command line.

I have gotten as far as compiling the library from source into functional object files. However, I cannot figure out how to link them into GCC via the eclipse user interface. The closest I have gotten is by going to "project>properties>C/C++ Build>Settings>Tool Settings>GNU RISC-V Cross C Linker"... which REALLY feels like the area I should be putting the link commands, but I can get NOTHING to work.

Has anyone got this library working in eclipse? Any advice?

I'm highly motivated and usually adept at these sorts of things, been writing embedded software since PIC and AVR were written with command line programs, so I shouldn't need too much hand holding. I just need an explanation of the eclipse side of things and I should be golden.

Please, and thank you.

[jld01]

How would you include the library when linking your application on the command line? If you can share your link command it will help us to advise on how to translate that into the Eclipse toolchain settings UI.

[jld01]

In the UI, you might include the library as follows:

[CharlesScoville]

TY!

This looks nice. I'm going to try this right now, as this looks like the intended way to do things. Will report back if this works also.

[CharlesScoville]

.... I think this may actually be the correct answer, and the other isn't. I'll explain...

The other answer appeared like it was working, because it wasn't throwing any errors. But, on closer inspection (disassembly view) the built in routines were not actually getting replaced with the external library equivalents. :/

Using the method here though, I am actually getting errors related to linking in the specific functions I am calling. What is interesting (assuming I am interpreting the error correctly) is that the errors are calling out that it can't link in routines for RVE target. If I am right, (no time to test tonight, I'm afraid) this error is related to the fact that the whole library was, in fact, built for the non embedded flavor of the RISC-V arch, i.e. built for the full 32 registers. The RV32E flavor, however, only has 16 registers... which would explain the issue, Hence the can't link to RVE target.

The only thing that goes against this theory is that the readme for the library specifically call out the "nd" versions of the archives as being "compatible with RV32EM[C] processors" of which the uC I'm writing for is a member. Not sure though, as I certainly built the lib fully intending it to be used in RV32IMC parts (ESP32-C3 originally.)

. . . Needs more testing.

[CharlesScoville]

So, yeah, it appears as though it is as I suspected above. T.T

The make file I have builds RVfplib using -march=rv32imc, which is incompatible with -march=rv32e, in-spite of what the readme for the RVfplib may suggest. So, I will need to find some time to build using corrected flags with the one vendor's GCC distribution.

Edit: Not that this has anything to do with the scope of the discussion anymore. I am past the "include the libs" hill now.

[CharlesScoville]

I know the ship sailed and it's out of scope and all that... but surely some net surfer is going to stumble across this while looking for answers to their own similar problem. SO I feel obligated to at least leave my ultimate findings.

I tried to build RVfplib using the correct flags, but got build errors. Looking at them and at what I was trying to do, I realized something deal breaking. The library in question does indeed support the embedded variation of RISC-V CPU, but it also requires that the CPU supports hardware integer multiply instructions or the "M" instruction extension. I hadn't noticed this detail.... I have been trying to build for WCH's 'CH32V003F' processor, which sadly lacks such hardware.

Considering that a lot of the speed advantage of the above lib comes from careful use of the hardware integer multiplier, I don't see meaningful value in continuing to try to get this lib to work on these CPU's.

I am falling back to an oldie but goodie, 'libfixmath' for all my real number processing needs on this component. I would recommend others do the same.

[jantje]

I just need an explanation of the eclipse side of things and I should be golden.

What you do not know is that you are using CDT component managed build. It is a old component that has withstood the test of time but has been modified in so many ways that it never really behaving like you think it should.
I have been using managed build for over a decade now and I'm currently rewriting it; so I feel like I'm entitled to speak about it (FYI I'm not a CDT developer)

The closest I have gotten is by going to "project>properties>C/C++ Build>Settings>Tool Settings>GNU RISC-V Cross C Linker"

This sounds like the right place for you but ... the "GNU RISC-V Cross C Linker" indicates you are not using a "pure CDT managed build" but a project type provided by a third party.
When a third party provides a project type they can change virtually anything, so the expected behaviour is unknown to the CDT team. The people who provide the project type are in a better position to help you out.

That being said.
In the barebones managed build with the cross gcc toolchain project>properties>C/C++ Build>Settings>Tool Setting looks like this.

You can basically put any command you want in the green marked field and it should execute when managed Build wants to execute the tool.
All other fields are one way or another ($FLAGS is an important one) incorporated in that field.

EDITED: I fixed some typo's and replaced some instances of toolchain by project type.

[CharlesScoville]

OK. The correct variable for at least one IDE arrangement ("MounRiver Studio Community" ... WCH's offering) is "${workspace_loc:/${ProjName}/}" I expect it is similar to Espressifs setup. My complete modified command is now. . .

-L "${workspace_loc:/${ProjName}/lib}" -lc -lm -lrvfp_nd

And is inserted in between ${FLAGS} and ${OUTPUT_FLAG}

[jantje]

Great you got it to work.

1. $(BASE_DIR)
   Environment variable expansion is difficult when there are multiple environments.
   I did you notice $(BASE_DIR) is with brackets (not curly brackets) and as such would not be resolved by eclipse but would be resolved by Make.
2. ${workspace_loc:/${ProjName}/lib}
   If you go to project properties->C/C++ build->Build variables and turn "show system variables" on you will find ProjDirPath which may meet your needs more.
   Notice that more variables may be available in the Environment page.
   

[CharlesScoville]

Possible false positive on this being the correct answer..... See my latest comments further up.

[jantje]

In my view both answers are correct. (there are indeed many ways to skin a cat)

Both answers allow you to modify the command line generated by managed build; as your request was about modifying the command line; the command line changes are what you need to look at to validate the answer.

To validate the answer the question to ask is: "Do I get the command line changes I want/expect during the build" (You should be able to see the command in the console)
This is an important question because the CDT responsibility (and that of the project Type provider) ends at executing the "correct" command line.

The @jld01 answer is the intended managed build way to "add libraries to the command line" (For example adding "something" here results in the ${FLAGS} variable to contain "-L something" and therefore the command line should contain "-L something".)

Note that @jld01 answer is dependent on having (I guess >90% chances to be true)

1. The project type needs to adhere to the default behaviour in regards to command line generation. (very likely)
2. the library options to be displayed (depends on the project type -I know one that doesn't)
3. The ${FLAGS} to be present in the command line pattern (depends on the project type -I know one that doesn't)

My answer allows you to completely bypass all intended managed build and simply force your command to be run (except for maybe unwanted environment expansions) during the build. I think this is great for trouble shooting and a nice to know for someone who is highly motivated and adept at these sorts of thing.
Because you stated "which REALLY feels like the area I should be putting the link commands, but I can get NOTHING to work" I thought it would be a good idea to add another way to skin the cat.

Note that my answer is dependent on having (I guess >95% chances to be true)

1. The project type needs to adhere to the default behaviour in regards to command line generation.

Anyway:

To validate the answer you need to validate the executed command not the result of the executed command.

[CharlesScoville]

Right! Looking back at the scope of the problem, your first and your final statement sums it up perfectly to be sure.

More than one way to skin a cat. If the commands get through to the underlying tools, then it's "mission complete" as far as eclipse is concerned.