Add Linker Support For L4Re

[humenda]

L4Re uses a linker script called l4-bender used within the L4Re build system to cross-compile (/link) to L4Re. This PR adds l4-bender as another linker variant to Rustc.

[rust-highfive]

r? @davidtwco

(rust_highfive has picked a reviewer for you, use r? to override)

[rust-highfive]

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:04:32] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:04:32] tidy error: /checkout/src/librustc_codegen_llvm/back/linker.rs:1218: trailing whitespace
[00:04:32] tidy error: /checkout/src/librustc_codegen_llvm/back/linker.rs:1232: trailing whitespace
[00:04:34] some tidy checks failed
[00:04:34] 
[00:04:34] 
[00:04:34] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:34] 
[00:04:34] 
[00:04:34] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:34] Build completed unsuccessfully in 0:00:49
[00:04:34] Build completed unsuccessfully in 0:00:49
[00:04:34] make: *** [tidy] Error 1
[00:04:34] Makefile:79: recipe for target 'tidy' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:01c003d8
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:047ab3fa:start=1537535545822976725,finish=1537535545829289459,duration=6312734
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0a0fb95f
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:16fb6cee
travis_time:start:16fb6cee
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:04a410e0
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[davidtwco]

Thanks for the PR!

This looks pretty good to me, I've got a question and a few minor nits.

[davidtwco]

nit: could you format this so the indentation is more consistent with other parts of the code.

L4Bender {
    cmd,
    sess,
    hinted_static: false,
}

or

L4Bender { cmd, sess, hinted_static: false, }

[davidtwco]

nit: could you remove this commented import?

[davidtwco]

Is there a reason that the flags -C link-arg or -C link-args to rustc (in combination with RUSTFLAGS for use with cargo build, etc.) can't be used instead of introducing new environment variables and a function to split them?

[humenda]

Thanks for your comments!

+ if let Ok(l4bender_args) = env::var("L4_BENDER_ARGS") { + L4Bender::split_cmd_args(&mut cmd, &l4bender_args); + } + + cmd.arg("--"); // separate direct l4-bender args from linker args + + if let Ok(l4_ld_opts) = env::var("L4_LD_OPTIONS") { + L4Bender::split_cmd_args(&mut cmd, &l4_ld_opts); + } Is there a reason that the flags `-C link-arg` or `-C link-args` to `rustc` (in combination with `RUSTFLAGS` for use with `cargo build`, etc.) can't be used instead of introducing new environment variables and a function to split them?

I need to position the arguments, so that a call looks roughly like this: l4-bender -SPECIAL_L4BENDER_ARG1 … -- -MOSTLY_NORMAL_LD_COMMAND1 … I don't see how I could pass a few options before the `--` and a few after; maybe this works and I overlooked something?

[davidtwco]

I'm not sure how that works either. Otherwise, this LGTM but I'll ping @alexcrichton who is more familiar with this part of the code.

r? @alexcrichton

[humenda]

@davidtwco You were right. L4_LD_OPTIONS replicates -C link-arg. However,
the other variable is still mandatory, since I need a way to correctly position
the bender-specific arguments on the command-line.
Is it fine in this case to introduce one more environment variable for the L4Re
target?

[davidtwco]

@humenda I'm not sure what the preferred approach here is. I've found an old post by @alexcrichton that suggests (to me) that we'd prefer to not support new environment variables or flags for this sort of thing. I'm not too sure though. Hopefully @alexcrichton would be able to elaborate more on a preferred approach here.

That all said, I've found a handful of older commits that (to my untrained eye) seem like they might be relevant or useful and could give you a way to do this without a new flag or env variable:

• I think there is an unstable -Z pre-link-arg flag. I found this commit about it.
• You could also try using -C linker="l4-bender --l4-specific-flag" -Z linker-flavour=l4-bender - I've seen similar referenced in this commit.

[alexcrichton]

Ah yeah sorry I've been slow to get here, the PR looks mostly good! I agree that we should avoid new env vars if possible (additionally avoiding trying to shell parse flags if we can). It looks like it should be possible to avoid here though, right?

[humenda]

- I think there is an unstable `-Z pre-link-arg` flag.

The commit message says: `and can be used to pass extra arguments at the *beginning* of the linker invocation, before the Rust object files are passed.` Looking at the code, it appears to me that the pre-link-args are indeed not the first arguments to the linker invocation, for instance the CTRN-files are passed before. Though this is not the case for l4re-uclibc, it seems very fragile to bet on pre-link-args to be the first. The definition of it really would need to be "before any linker arguments are passed."

- You could also try using `-C linker="l4-bender --l4-specific-flag" -Z linker-flavour=l4-bender`

I would like to, but the arguments look like this: [l4-bender] --spec=path -Dlinker="ld -m …" -Dfoo=bar There needs to be a way to mark argument boundaries, `-Dlinker="…"` needs to be *one* argument and spaces in there would ideally be preserved. The latest commit removed one of the variables, for the second I'm still not sure how to properly deal with it.

[alexcrichton]

Sorry for being slow to reply, but if linker arguments must be at the front, can't a shell script be used to make sure they're placed at the front?

Otherwise the "pre" in "pre link args" I think means they'll always be sufficiently at the front

[TimNN]

Ping from triage @humenda: Some additional clarifications have been requested for your PR.

[humenda]

Passing pre-link-args and link-args seems not possible with Cargo command-line flags ATM. There is CARGO_RUST_FLAGS, but my flags contain spaces and hence this is not an alternative. I suppose we'll need new Cargo options before this PR can be merge, hence I'm closing it for now.