Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Builds fail when different execstack options are around in objects #18522

Open
chrysn opened this issue Aug 28, 2022 · 7 comments
Open

Builds fail when different execstack options are around in objects #18522

chrysn opened this issue Aug 28, 2022 · 7 comments
Assignees
Labels
Area: toolchain Area: toolchains; everything related to compilation, libc, linking, … Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)

Comments

@chrysn
Copy link
Member

chrysn commented Aug 28, 2022

Something in the latest Debian sid updates (possibly some experimental packages, couldn't pin it down yet) makes builds fail if one of the objects involved has the .note.GNU-stack section present indicating a non-executable stack, and one of the objects has not. This is the case, typically, when Rust programs are built, as the Rust compiler apparently never needs an executable stack.

That'd generally not fatal (it just triggers a "ld: warning: lib_a-nano-msizer.o: missing .note.GNU-stack section implies executable stack" / "ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker"), but as we build with -Wl,--fatal-warnings, it becomes fatal as "collect2: error: ld returned 1 exit status".

The best workaround I've found is to explicitly set -z execstack or -z noexecstack (I'd need to look into the platforms to see what is actually the case, probably execstack, but if we don't use it and have an MPU, maybe make it noexec?); weirdly, both are accepted by the linker.

If this is becoming common even on systems w/o experimental, this may need an urgent fix and backport. (But if so, it'd be a simple-to-test one as it wouldn't affect built binaries, just make the linker happy).

@chrysn chrysn added Area: toolchain Area: toolchains; everything related to compilation, libc, linking, … Area: Rust Area: Rust wrapper labels Aug 28, 2022
@chrysn chrysn self-assigned this Aug 28, 2022
@chrysn
Copy link
Member Author

chrysn commented Sep 20, 2022

This is not Rust specific -- I get the same issue when just using clang:

$ make -C examples/hello-world TOOLCHAIN=clang BOARD=microbit-v2

@chrysn chrysn removed the Area: Rust Area: Rust wrapper label Sep 20, 2022
@chrysn
Copy link
Member Author

chrysn commented Sep 20, 2022

I'd consider removing the -Wl,--fatal-warnings as this really is a warning, and maybe linker authors have gotten wiser in what they classify as critical. (IMO a warning should be just that, an error should be an error).

The flag was introduced in ba2d4a0 as part of #3120 -- @jnohlgard, where would you place this warning in the area between "there is a warning we should address but it's not broken yet" (but -Wl,--fatal-warnings makes it break things) and "the binary is probably broken anyway"?

@OlegHahm
Copy link
Member

On OpenSUSE with GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.39.0.20220810-1 on recent master I get

/usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: warning: /home/oleg/RIOT/examples/hello-world/bin/native/cpu/tramp.o: missing .note.GNU-stack section implies executable stack
/usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
/usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: warning: /home/oleg/RIOT/examples/hello-world/bin/native/hello-world.elf has a LOAD segment with RWX permissions

when building the helloworld example for native.

The last warning also appears on Arch Linux with GNU ld (GNU Binutils) 2.39.0.

@chrysn
Copy link
Member Author

chrysn commented Oct 19, 2022 via email

@OlegHahm
Copy link
Member

Nope - neither on Arch nor on OpenSUSE. (Talking about the C helloworld example, not RUST.)

@chrysn
Copy link
Member Author

chrysn commented Oct 19, 2022 via email

@OlegHahm
Copy link
Member

Nope, I tested with TOOLCHAIN set to the default value (gcc I assume). With TOOLCHAIN=llvm I don't any of these warnings.

chrysn added a commit to chrysn-pull-requests/RIOT that referenced this issue Nov 4, 2022
chrysn added a commit to chrysn-pull-requests/RIOT that referenced this issue Nov 4, 2022
@maribu maribu added the Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) label May 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: toolchain Area: toolchains; everything related to compilation, libc, linking, … Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)
Projects
None yet
Development

No branches or pull requests

3 participants