sel4test: Handle retain attr issue in build args#102
sel4test: Handle retain attr issue in build args#102kent-mcleod wants to merge 1 commit intoseL4:masterfrom
Conversation
It seems that detecting support for the right keywords used to instruct the linker to retain symbols is pretty unstable. Alternative approach is to move conditional check into the build script and pick behavior based on the toolchains selected. Signed-off-by: Kent McLeod <[email protected]>
|
With GCC this gets rid of the errors for With LLVM ( |
|
Adding "-fno-lto" should fix Ivan's Clang warning. I think we should disable link time optimisation by default for both clan and gcc. Edit: Created PR #103 that limits retain for Clang at compile time, keeping the existing has attribute check. |
| #if defined(__has_attribute) && __has_attribute(retain) | ||
| #define ATTR_USED_RETAIN __attribute__((used,retain)) | ||
| #else | ||
| #define ATTR_USED_RETAIN __attribute__((used)) | ||
| #endif | ||
|
|
There was a problem hiding this comment.
We still want to keep this check though, so instead of a Cmake check, can't we add defined(__clang__) here?
| list(SORT deps) | ||
|
|
||
| add_library(sel4test STATIC EXCLUDE_FROM_ALL ${deps}) | ||
| if(CMAKE_C_COMPILER_ID STREQUAL "Clang") |
There was a problem hiding this comment.
What happens if you compile with GCC but link with ld.lld or compile with Clang but link with ld.bfd?
There was a problem hiding this comment.
I don't think we have to worry about anyone compiling with gcc and linking with ld.lld. Clang has better checks for has-retain attribute checks, unlike the buggy gcc one which says it's fine and then complains. So supposedly Clang with ld.bdf should be fine.
There was a problem hiding this comment.
Fair enough. It's usually the case though that Clang will fall back to ld.bfd (and using GCC's libgcc.a etc) even implicitly if it is not told explicitly to use ld.lld. This has been the case for seL4 building with LLVM/Clang before I pushed support for ld.lld.
There was a problem hiding this comment.
Sure, but does Clang support GCC's link-time optimisation format? I don't expect it does, in which case it shouldn't do link-time optimisation when using ld.bdf.
There was a problem hiding this comment.
I don't have a strong opinion, but just for completeness:
Clang supports two types of link time optimization:
- Full LTO, which is the traditional approach also used by GCC where the whole link unit is analyzed at once. Using it is no longer recommended.
- ThinLTO, where the link unit is scanned and split up into multiple parts.
If you're using LLVM/Clang to build, and unlike GCC/ld.bfd, you'll need to manually tell your linker (ld.lld) where to find -lgcc (or ideally compiler_rt). You can do this by passing the GCC's libgcc.a directory e.g., |
4 participants
It seems that detecting support for the right keywords used to instruct the linker to retain symbols is pretty unstable. Alternative approach is to move conditional check into the build script and pick behavior based on the toolchains selected.
An approach to address #97