Tracking issue for -Z linker-flavor #49794

Activity

1. japaric

   added

   C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFC

   on Apr 8, 2018
2. alexcrichton commented on Apr 9, 2018

   

   alexcrichton

   on Apr 9, 2018

   Member

   More actions

   I think I'd personally be ok avoiding an RFC on this so long as we've got a solid design. One step I'd preferrably like to see before stabilization is some documentation which rationalizes -C linker and a hypothetical -C linker-flavor argument as well (aka do they affect each other in terms of defaults?).

   For example we may be able to avoid stabilizing linker-flavor in the near term altogether by doing some "simple inference" based on the linker's file name, although we'd likely still want to one day stabilize -Z linker-flavor
3. japaric commented on Apr 10, 2018

   

   japaric

   on Apr 10, 2018

   ContributorAuthor

   More actions

   we may be able to avoid stabilizing linker-flavor in the near term altogether by doing some "simple inference" based on the linker's file name

   This sound like a good step forwards. I can look into it, probably by next week.

   Two questions though: when you do -C linker=lld do you always get the LLD shipped with the Rust toolchain, or is the LLD in the unmodified user PATH, if any, the preferred LLD? In either case will we ever want some special -C linker argument to express preference for one or the other: for example -C linker=rustc.lld will always give you the LLD in the sysroot.

   The other question is: are there any stability guarantees around -C linker=lld (i.e. use the LLD in the sysroot)? Will we ever remove the LLD binary in the sysroot in favor of having rustc call LLD as a library?

   👍React with 👍1Reacted by James Munns
4. alexcrichton commented on Apr 10, 2018

   

   alexcrichton

   on Apr 10, 2018

   Member

   More actions

   Heh all excellent questions! I'm detecting a trend as well with the topic :)

   Honestly I'm not entirely sure what to do about the stability of LLD. Today, and historically for a very long time, we have prepended the sysroot bin path to PATH when invoking the linker unconditionally. This means:

   • If we ship LLD in that sysroot location then it will always be preferred.
   • The only way to switch to a system LLD would be to use -C linker=/path/to/lld
   • Using LLD would be "insta stable", as you've realized, because -C linker=lld works

   The reason we unconditionally prepend PATH is related to MinGW and the rust-mingw component where we ship a gcc.exe linker for Windows users so they otherwise wouldn't need to install a large development environment to get up and running with Rust. This also has cons, however, in that it means we accidentally prefer our own gcc.exe even when C code may have been compiled with an external gcc.exe, causing link errors from time to time.

   Now we don't have to put LLD in the same location, nor do we need to give LLD similar treatment. At the time of implementing LLD support it was basically the easiest option.

   So another question entirely about stabilizing LLD is whether its command line options are stable. For example does LLD remove options arbitrarily? Tweak and/or making breaking changes to its interface? Today we'd inherit such breakage and expose rustc users to that possibly.

   As to whether we'll ever invoke LLD as a library, I sort of doubt it. I would personally prefer to do that because it's cheaper than spawning a process, but LLD is internally architected for abort-on-error from what I could tell so we wouldn't get a chance to gracefully handle failures in rustc. As a result it seems like a safe bet that we'll be using it as a binary for the forseeable future.

   ---

   Where that leaves us, I'm not sure. I think using a binary file name like rustc-lld makes sense in that it'll make it much easier to use LLD externally installed on the system. I feel like we're going to get the most bang for our buck by just shipping LLD and praying, but such a strategy is almost guaranteed to cause a huge amount of pain down the road when something breaks.

   I guess this is sort of the same bucket of all LLVM tooling. We'd love to expose it but run a high risk of causing a large amount of pain as soon as anything has a backwards-incompatible change (which everything else in LLVM seems to do fairly often). Maybe LLD isn't in this class of tools though? I think it's supposed to be a drop-in replacement for existing tools with stable interfaces, so as long as we use those stable interfaces (aka ld-like options) we may be in the clear
5. japaric commented on May 1, 2018

   

   japaric

   on May 1, 2018

   ContributorAuthor

   More actions

   So another question entirely about stabilizing LLD is whether its command line options are stable.

   If we go with rustc-lld equals "always the LLD in rustc sysroot" then we can provide more
   stability for rustc-lld than what we can provide for external linkers.

   If the CLI of LLD changes in a future LLVM release then we can fix that transparently by having a
   special linker flavor for rustc-lld. This special (always used when linker = rustc-lld) and
   internal (not exposed via -Z linker-flavor) RustcLld linker flavor will use the right CLI args
   for the LLD version we ship.

   We can't provide this kind of CLI stability for external linkers because the user can use any
   version of e.g. GNU LD. Unless we make rustc probe at runtime the version of the linker (ld -v) to adjust how it invokes the linker but that sounds like a lot more work than what's required
   for stable rustc-lld.

   TL;DR I don't see much hazard in stabilizing -C linker=rustc-lld; we control and thus know the LLD
   version that's shipped with rustc so we can guarantee that LLD will always be invoked with the
   right CLI.

   ---

   we may be able to avoid stabilizing linker-flavor in the near term altogether by doing some
   "simple inference" based on the linker's file name

   This sound like a good step forwards. I can look into it, probably by next week.

   I have a WIP PR for this: #50359

   I also think it makes sense to rename rustc's LLD to rustc-lld to avoid shadowing the lld in the
   user's PATH.
6. alexcrichton commented on May 1, 2018

   

   alexcrichton

   on May 1, 2018

   Member

   More actions

   Heh I'm not sure I 100% agree with the rationale but I definitely agree with the conclusion :)

   The main part is that users can still specify custom arguments via -C link-arg, and I'm not sure how we'd solve that with a shim over LLD. Regardless I like renaming to rustc-lld to avoid clashing with PATH and allowing usage of LLD in PATH anyway.
7. davidthomaswood commented on Aug 22, 2019

   

   davidthomaswood

   on Aug 22, 2019

   More actions

   From looking at cambridgeconsultants/rust-beagleboardx15-demo#1, this flag was stabilized in 9536d04, and is now -C linker-flavor
8. jonas-schievink commented on Nov 26, 2019

   

   jonas-schievink

   on Nov 26, 2019

   Contributor

   More actions

   Uh okay, closing I guess ¯\_(ツ)_/¯
9. jonas-schievink

   closed this as completedon Nov 26, 2019