You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
warnings generated by retain attribute in sel4test library header #97
There doesn't seem to be a way to reliably test if gcc supports the retain attribute as __has_attribute(retain) returns 1 anyway.
Is there an alternative approach here? (ping @heshamelmatary)
This makes the current sel4test manifest fail to build now, when building with arm-gnu-toolchain-12.2.rel1-x86_64-aarch64-none-elf, because of -Werror.
Reverting 12d0d97 (in seL4_libs) and be8277a84c0c59b472909877540d55d53739001e. (in seL4_tools) allows this to build.
It works on the versions of the toolchains provided by the docker containers, which is why the changes haven't been reverted yet.
If there's an easy way to conditionally compile based on lld then that would be good, but I'm not sure what the condition would be. Unless it's a conditional on clang vs gcc.
We could add some cmake tests that checks if the toolchain supports retain and then conditionally use it based on that. But that's more maintenance effort.
The documentation on the used attribute 1, explains that for ELF targets the retain attribute is needed to prevent unused sections from being stripped during linker section GC.
We could probably, in cmake, check for the binutils version and conditionally add -z nostart-stop-gc for older versions
Considering the problems this gives with gcc, I propose we remove the newly added retain keyword altogether and just use -z nostart-stop-gc to fix the original llvm problem. Any downsides to that?
Alternatively we could unwind the previous commit and make the retain keyword conditional of the compiler-linker selection that's known in CMake scope. In the draft PR i just conditioned on Clang or !Clang because I don't have toolchains to test with in front of me: #102
Considering the problems this gives with gcc, I propose we remove the newly added retain keyword altogether and just use -z nostart-stop-gc to fix the original llvm problem. Any downsides to that?
Won't we then have to detect and handle cases where nostart-stop-gc isn't supported by the linker?
Alternatively we could unwind the previous commit and make the retain keyword conditional of the compiler-linker selection that's known in CMake scope. In the draft PR i just conditioned on Clang or !Clang because I don't have toolchains to test with in front of me: #102
That seems the best short-term fix, yes. Except if we can find a better solution.
Considering the problems this gives with gcc, I propose we remove the newly added retain keyword altogether and just use -z nostart-stop-gc to fix the original llvm problem. Any downsides to that?
Won't we then have to detect and handle cases where nostart-stop-gc isn't supported by the linker?
Yes, but if the linker ignores unknown options it's an improvement. We'd add it only for llvm, until gcc also enables LTO by default. Anyway, limiting retain to Clang is probably the better solution, but this is something we need to keep in mind.
Activity
Indanz commentedon Feb 27, 2025
binutils 2.36 or newer is required according to this, otherwise you get that warning. There is a bug report by the same llvm dev for gcc 11 here with some more info: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99587
heshamelmatary commentedon Feb 28, 2025
@kent-mcleod I believe @Indanz is right. I also left a comment back then to address this issue that might solve those warnings? seL4/seL4_tools#173 (comment)
Please let me know if this issue still holds
midnightveil commentedon Mar 19, 2025
This makes the current sel4test manifest fail to build now, when building with
arm-gnu-toolchain-12.2.rel1-x86_64-aarch64-none-elf, because of-Werror.Reverting 12d0d97 (in seL4_libs) and be8277a84c0c59b472909877540d55d53739001e. (in seL4_tools) allows this to build.
Indanz commentedon Mar 19, 2025
We have multiple options:
I have no opinion about the way forward.
12.2 was released in 2022, do any newer versions have the same problem? Current release is 14.2.
kent-mcleod commentedon Mar 19, 2025
It works on the versions of the toolchains provided by the docker containers, which is why the changes haven't been reverted yet.
If there's an easy way to conditionally compile based on lld then that would be good, but I'm not sure what the condition would be. Unless it's a conditional on clang vs gcc.
We could add some cmake tests that checks if the toolchain supports retain and then conditionally use it based on that. But that's more maintenance effort.
The documentation on the
usedattribute 1, explains that for ELF targets the retain attribute is needed to prevent unused sections from being stripped during linker section GC.heshamelmatary commentedon Mar 19, 2025
We could probably, in cmake, check for the binutils version and conditionally add
-z nostart-stop-gcfor older versionsIvan-Velickovic commentedon May 21, 2025
Tried with
aarch64-none-elf-gcc (GCC) 14.2.1 20250322andGNU ld (GNU Binutils) 2.44but still the same issue.Indanz commentedon May 21, 2025
Considering the problems this gives with gcc, I propose we remove the newly added retain keyword altogether and just use
-z nostart-stop-gcto fix the original llvm problem. Any downsides to that?kent-mcleod commentedon May 22, 2025
Alternatively we could unwind the previous commit and make the retain keyword conditional of the compiler-linker selection that's known in CMake scope. In the draft PR i just conditioned on Clang or !Clang because I don't have toolchains to test with in front of me: #102
Won't we then have to detect and handle cases where nostart-stop-gc isn't supported by the linker?
Indanz commentedon May 23, 2025
That seems the best short-term fix, yes. Except if we can find a better solution.
Yes, but if the linker ignores unknown options it's an improvement. We'd add it only for llvm, until gcc also enables LTO by default. Anyway, limiting
retainto Clang is probably the better solution, but this is something we need to keep in mind.This post is very illuminating.
Network manager had the same issue and they solved it by wrapping retain around a __clang__check too.
midnightveil commentedon May 30, 2025
Just for the record: elfloader-tool also needs to be fixed https://github.com/seL4/seL4_tools/blob/34bb2ca78418f3347e7b3aad7e4b5035339f8a5d/elfloader-tool/include/drivers/common.h#L46