Build of picolibc module with LTO fails #81674
Comments
|
Tested the same minimal project with the zephyr SDK 0.17.0, same result: |
|
Changing the prj.conf to |
|
Running arm-none-eabi-nm on the resulting zephyr.elf for Do I understand this correctly that I'm pulling in memset from the SDK, although |
|
I'm happy to help out, but this sure looks like a compiler issue and not something the library has any control over. |
|
Ok, I did some experiments using the above project to see what's up. The compiler flags for picolibc and the rest of Zephyr do differ a bit (picolibc enables some floating point consistency flags). I hacked things up to make the flags match as closely as I could manage; picolibc still requires |
|
Do you mind sharing your patch with the differences in the flags? I suppose getting them as close as possible would be a good idea anyway, although it might not solve this problem. And for the actual problem: I still think something with the module version of picolibc is off, because why would it pull in for this case memset from the SDK? Or am I missing something? |
The two math options are necessary so that picolibc gets built correctly, but we should probably let Zephyr control the I assume it's pulling in the function from the SDK because it couldn't find it in the module? Why is it even referencing the SDK library at all though? |
|
Triggering the failure is the following command: memset is defined in the last file libc.a: But still bfd fails to find it. If I add the object file, which contains the memset definition, manually to the link command bfd is able to find memset. Linking still fails due to other undefined symbols, but memset can be found: So there seems to be a difference in the handling of archive files and object files. Anybody an idea what is going on here? |
|
I think I was able to narrow it down even further. Running Hence, I'm slowly starting to suspect a gcc bug to be the cause of this issue. |
|
I wonder if something in -lgcc is referencing memset and that's causing problems? libgcc is probably not built with -lto enabled. |
|
It rather looks like some functions should be generally excluded from LTO: Edit: fixed link |
|
Result of the discussion with the gcc-guys:
|
|
Their answer makes sense -- you can't LTO a function used in the late stages of code generation. This shouldn't include all of libc, but that's certainly an easy answer. Have we tried -ffat-lto-objects when building the C library? That should provide both LTO and regular binary bits for every function. |
|
Unfortunately I've been trying to adapt cmake to get rid of LTO just for picolibc, but I'm failing to achieve something useful. My approach would have been to add a And then using this in a cmake generator expression to get rid of LTO if this has been set: But clearly my cmake-foo is too weak. @keith-packard Could you maybe help me out a little bit? Or do you have a different suggestion? |
|
Consider the cmake modifications in the previous comment just as a basic idea, they are definitely wrong with respect to cmake syntax. |
The compiler requires that much of the C library be built without using LTO so that various symbols are available for use by generated code, including things like memset and memcpy. Add -fno-lto when building both picolibc itself as well as the Zephyr interface bits. Closes: zephyrproject-rtos#81674 Signed-off-by: Keith Packard <[email protected]>
Describe the bug
Building a minimal example with the picolibc module and LTO fails with a bunch of undefined references.
To Reproduce
CMakeLists.txt:
prj.conf:
main.c:
Expected behavior
It should be possible to build the picolibc module with LTO.
Impact
It is not possible to use the picolibc module in combination with LTO.
Logs and console output
Environment
Zephyr Version 6843240
The text was updated successfully, but these errors were encountered: