pass correct pie args to gcc linker by canarysnort01 · Pull Request #48076 · rust-lang/rust

canarysnort01 · 2018-02-08T19:40:05Z

When linking with gcc, run gcc -v to see if --enable-default-pie is
compiled in. If it is, pass -no-pie when necessary to disable pie.
Otherwise, pass -pie when necessary to enable it.

Fixes#48032 and fixes#35061

rust-highfive · 2018-02-08T19:40:11Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @eddyb (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

nagisa · 2018-02-08T20:08:03Z

Can we pass the -no-pie and -piealways, without checking for the gcc?

canarysnort01 · 2018-02-08T20:10:06Z

no, the -no-pie flag will cause older versions of gcc to error out because it doesn't recognize the flag.

eddyb · 2018-02-08T21:03:29Z

r? @alexcrichton

alexcrichton · 2018-02-08T22:46:07Z

Thanks for the PR @canarysnort01! Would it be possible to avoid running gcc --version to figure out if it supports this though? This looks like it'd by default unconditionally run gcc --version on all platforms for all executables, right?

canarysnort01 · 2018-02-09T09:55:44Z

Yes, this would run the version check on all platforms on all executables when the link step is configured to use gcc. The benefit here is we know for sure how gcc is configured and we're doing the right thing.

An alternative approach would be:

Do like @nagisa said and always pass -pie or -no-pie
Check if gcc fails when we pass -no-pie
If so, check if stderr contains unrecognized command line option ‘-no-pie’
If so, restart the link step without the -no-pie argument, making the assumption that gcc doesn't have --enable-default-pie, which seems like a valid assumption to make.

The benefit to this approach would be the user only has to pay for the extra linker invocation when it is actually necessary, and would get used less and less as the user base upgrades gcc.

alexcrichton · 2018-02-09T15:20:55Z

When was -no-pie added to gcc? Was it recently?

canarysnort01 · 2018-02-09T15:54:01Z

According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867853 around gcc 5.3, so a couple years, although it doesn't appear to have been documented until 6.1. The gcc 6.3 in debian stable (stretch) accepts -no-pie, but the gcc in debian oldstable (jessie) (I think 4.8) does not.

alexcrichton · 2018-02-09T15:56:04Z

Ok thanks for the info! I think that sounds like a reasonable approach in that case. I believe by default all Rust executables are pie and so it won't hit the "slow path" anyway, but in those cases it does then a gcc upgrade should do it!

alexcrichton · 2018-02-10T18:58:38Z

To help prevent an accidental infinite loop, could this also have a clause that the cmd has an argument of -no-pie in it?

alexcrichton · 2018-02-11T16:32:46Z

@bors: r+

bors · 2018-02-11T16:32:47Z

📌 Commit bc82fec has been approved by alexcrichton

kennytm · 2018-02-12T13:57:50Z

@bors r-

Failed on macOS (x86_64-apple-darwin). (Note that on macOS, gcc is an alias of clang.)

[00:50:12] Compiling smallvec v0.6.0
[00:50:12] error: linking with `cc` failed: exit code: 1
[00:50:12] |
[00:50:12] = note: "cc" "-m64" "-L" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/stage1-rustc/release/build/rustc-4f5f147d2791f6cc/build_script_build-4f5f147d2791f6cc.build_script_build0-4bc55960443ab03659164fb01578882c.rs.rcgu.o" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/stage1-rustc/release/build/rustc-4f5f147d2791f6cc/build_script_build-4f5f147d2791f6cc.build_script_build1-4bc55960443ab03659164fb01578882c.rs.rcgu.o" "-o" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/stage1-rustc/release/build/rustc-4f5f147d2791f6cc/build_script_build-4f5f147d2791f6cc" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/stage1-rustc/release/build/rustc-4f5f147d2791f6cc/build_script_build-4f5f147d2791f6cc.crate.allocator.rcgu.o" "-Wl,-dead_strip" "-no-pie" "-nodefaultlibs" "-L" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/stage1-rustc/release/deps" "-L" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/libstd-b6e500af6452e0a0.rlib" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/libpanic_unwind-3528cd949b3bc67b.rlib" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-62f3c8961bd8f6ac.rlib" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/libunwind-84ae26c870c8d23a.rlib" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/liballoc_system-9c91e2a7474fac77.rlib" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/liblibc-e5643cf30768d91d.rlib" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/liballoc-52f38c4b90af6884.rlib" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/libstd_unicode-a24b64a7dffe4b1c.rlib" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/libcore-37c193a05e2b91ed.rlib" "/Users/travis/build/rust-lang/rust/build/x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/libcompiler_builtins-aa4abcbca82f4be1.rlib" "-l" "System" "-l" "resolv" "-l" "pthread" "-l" "c" "-l" "m"
[00:50:12] = note: clang: error: unknown argument: '-no-pie'
[00:50:12] [00:50:12] [00:50:12] error: aborting due to previous error
[00:50:12] [00:50:12] error: Could not compile `rustc`.

kennytm · 2018-02-12T14:13:57Z

This should check for "error: unknown argument" as well.

alexcrichton · 2018-02-12T18:54:33Z

Since this probably isn't applicable to OSX as well, could this logic only get triggered on unix targets?

canarysnort01 · 2018-02-12T19:40:21Z

@alexcrichton IIUC you want to check if the target is an OSX target and, if so, never issue the -no-pie argument at all?

It looks like clang might follow in gcc's footsteps in this respect, here's an open issue to do just that: https://bugs.llvm.org/show_bug.cgi?id=13410

Also, it looks like -no-pie was added in clang 5.0 as a no-op for compatibility: https://reviews.llvm.org/rL308268

I'm concerned if we add this exception and osx upgrades/patches their clang to default to pie it will break.

alexcrichton · 2018-02-12T20:15:35Z

Is the -pie and/or -no-pie argument recognized on OSX? The fact that this caused a failure on CI (where everything we build should be "as position independent as possible") is pretty worrying. In theory, despite changes here, we shouldn't hit an error in CI

canarysnort01 · 2018-02-13T01:12:53Z

Ah I think see where you are coming from now. I was thinking the build failure from @kennytm was from the test suite like in #47037 which I would expect to hit this code path, but iiuc now all builds on OSX failed. (I don't have a mac to test with).

Which makes sense now that I see that position-independent-executables isn't set in OSX's target or the mac base target.

Which leads back to does pie mean anything on OSX... hmm good question.

canarysnort01 · 2018-02-13T02:01:45Z

I don't have an answer yet, but I think one option to address this would be to make position-independent-executables have three possible values: yes, no, default.

Yes would pass -pie
No would pass -no-pie and hit the new code in this PR
Default would not pass any argument to the linker and take whatever it's default is

alexcrichton · 2018-02-13T15:51:13Z

Invoking the linker tends to be a fickle beast so it's often best to leave it as is unless we need to change it, so perhaps a flag could be added to only pass the flag when linker_is_gnu?

canarysnort01 · 2018-02-14T01:38:38Z

That seems like a reasonable solution.

When linking with gcc, run gcc -v to see if --enable-default-pie is compiled in. If it is, pass -no-pie when necessary to disable pie. Otherwise, pass -pie when necessary to enable it. Fixesrust-lang#48032 and fixesrust-lang#35061

Recent versions of gcc default to creating a position independent executable and must be explicitly told not to with the -no-pie argument. Old versions of gcc don't understand -no-pie and will throw an error. Check for that case and retry without -no-pie. This is safe because these old versions of gcc should never default to creating a position independent executable.

canarysnort01 · 2018-02-14T03:31:09Z

Should I update this PR description to the current solution? Is that what gets put in the merge commit description?

canarysnort01 · 2018-02-14T04:29:44Z

@alexcrichton this pr will conflict with #48125

alexcrichton · 2018-02-14T16:03:01Z

@bors: r+

Ah that's fine! We can see how @bors arbitrates

bors · 2018-02-14T16:03:02Z

📌 Commit ab9cae1 has been approved by alexcrichton

pass correct pie args to gcc linker When linking with gcc, run gcc -v to see if --enable-default-pie is compiled in. If it is, pass -no-pie when necessary to disable pie. Otherwise, pass -pie when necessary to enable it. Fixesrust-lang#48032 and fixesrust-lang#35061

Rollup of 17 pull requests - Successful merges: #47964, #47970, #48076, #48115, #48166, #48281, #48297, #48302, #48362, #48369, #48489, #48491, #48494, #48517, #48529, #48235, #48330 - Failed merges:

rust-highfive assigned eddyb Feb 8, 2018

rust-highfive assigned alexcrichton and unassigned eddyb Feb 8, 2018

arazabishov added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 8, 2018

alexcrichton reviewed Feb 10, 2018
View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 11, 2018

kennytm mentioned this pull request Feb 12, 2018
Rollup of 8 pull requests #48158
Closed

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 12, 2018

kennytm reviewed Feb 12, 2018
View reviewed changes

Comment threadsrc/librustc_trans/back/link.rs Outdated
kennytmFeb 12, 2018
Copy link
Copy Markdown
Member
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should check for "error: unknown argument" as well.

canarysnort01 added 5 commits February 13, 2018 22:10

pass correct pie args to gcc linker
1635052
When linking with gcc, run gcc -v to see if --enable-default-pie is compiled in. If it is, pass -no-pie when necessary to disable pie. Otherwise, pass -pie when necessary to enable it. Fixesrust-lang#48032 and fixesrust-lang#35061

verify passed -no-pie arg before retrying failed link
f0e9af1

handle -no-pie error from clang
c8def92

only pass -no-pie if linker_is_gnu
ab9cae1

canarysnort01 force-pushed the fix_pie branch from d5d4edf to ab9cae1Compare February 14, 2018 04:26

kennytm added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 14, 2018

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 14, 2018

xd009642 mentioned this pull request Feb 15, 2018
link error with undefined reference to `main' on Arch xd009642/tarpaulin#23
Closed

kennytm added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 21, 2018

kennytm mentioned this pull request Feb 25, 2018
Rollup of 17 pull requests #48531
Merged

bors merged commit ab9cae1 into rust-lang:masterFeb 25, 2018

sfackler mentioned this pull request Mar 9, 2018
Latest changes in nightly cause it to produce executable named "-pie" in the crate directory. #48884
Closed

SimonSapin mentioned this pull request Mar 23, 2018
run-make/relocation-model: "final link failed: Nonrepresentable section on output" #47037
Closed

davidalber mentioned this pull request Mar 24, 2018
Do something with the contributor list rust-lang/highfive#41
Open

cuviper mentioned this pull request Apr 4, 2020
Enabling static-pie for musl #70740
Merged

jebrosen mentioned this pull request Jun 2, 2020
[Mac] could not compile libcrwf2/Rocket#1321
Closed

Uh oh!

Uh oh!

Conversation

canarysnort01 commented Feb 8, 2018

Uh oh!

rust-highfive commented Feb 8, 2018

Uh oh!

nagisa commented Feb 8, 2018

Uh oh!

canarysnort01 commented Feb 8, 2018

Uh oh!

eddyb commented Feb 8, 2018

Uh oh!

alexcrichton commented Feb 8, 2018

Uh oh!

canarysnort01 commented Feb 9, 2018

Uh oh!

alexcrichton commented Feb 9, 2018

Uh oh!

canarysnort01 commented Feb 9, 2018

Uh oh!

alexcrichton commented Feb 9, 2018

Uh oh!

alexcrichtonFeb 10, 2018

Choose a reason for hiding this comment

Uh oh!

alexcrichton commented Feb 11, 2018

Uh oh!

bors commented Feb 11, 2018

Uh oh!

kennytm commented Feb 12, 2018

Uh oh!

kennytmFeb 12, 2018

Choose a reason for hiding this comment

Uh oh!

alexcrichton commented Feb 12, 2018

Uh oh!

canarysnort01 commented Feb 12, 2018

Uh oh!

alexcrichton commented Feb 12, 2018

Uh oh!

canarysnort01 commented Feb 13, 2018

Uh oh!

canarysnort01 commented Feb 13, 2018

Uh oh!

alexcrichton commented Feb 13, 2018

Uh oh!

canarysnort01 commented Feb 14, 2018

Uh oh!

canarysnort01 commented Feb 14, 2018

Uh oh!

canarysnort01 commented Feb 14, 2018

Uh oh!

alexcrichton commented Feb 14, 2018

Uh oh!

bors commented Feb 14, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants