On Tue, Sep 19, 2023 at 3:55 AM Matthew Maurer <mmaurer@xxxxxxxxxx> wrote: > > On Mon, Sep 18, 2023 at 11:43 AM Nick Desaulniers > <ndesaulniers@xxxxxxxxxx> wrote: > > > > On Mon, Sep 18, 2023 at 9:38 AM Matthew Maurer <mmaurer@xxxxxxxxxx> wrote: > > > > > > On Mon, Sep 18, 2023 at 8:25 AM Nick Desaulniers > > > <ndesaulniers@xxxxxxxxxx> wrote: > > > > > > > > What happens if you invoke the linker directly? > > > Rust unfortunately currently doesn't support invoking the linker > > > directly: https://github.com/rust-lang/rust/issues/73632 > > > > Wait; does Rust have its own linker? It doesn't use the system linker? > > Perhaps that's necessary for the rust module format? If so, TIL. > It does use the system linker (this is what -C linker is controlling), > but the command line passed to the linker may change, extra object > files may be added to the command line, etc. > > > > > > Generally, the kernel either invokes the compiler or the linker > > > > directly. (For assembler, it is typically preprocessed, as are linker > > > > scripts!) So invoking the linker directly is a common pattern in > > > > kbuild. It also makes me slightly sad if the rust compiler ends up > > > > invoking a c compiler, even if it's simply to drive the linker. > > > As mentioned earlier, we could pass $HOSTLD, but if the linker isn't > > > named something accurate (e.g. if the linker is not named lld, but is > > > lld), we need to know how to pass a flavor: > > > https://doc.rust-lang.org/rustc/codegen-options/index.html#linker-flavor > > > Would it be appropriate to just assume the linker is named correctly? > > > > If it were not, what does failure look like? > That depends. I think it will usually look like "unrecognized flag: > blah blah", but that's not guaranteed. > > > > command not found: asdfadfasdf > This isn't about command-not-found, it's about "I set > HOSTLD=foo/bar/weirdname, and it is an lld-like linker. rustc invoked > it assuming it is an ld-like linker." > > > > Seems fine to me. If the user mis-specifies HOSTLD=, then they will > > get a similar error, which should be prescriptive enough for them to > > figure out how exactly they're "holding it wrong." > > > > > > For example, Android carries a downstream patch to set `-fuse-ld=lld` > > > > for $KBUILD_HOSTCFLAGS, because its build environment doesn't contain > > > > GNU binutils ("guilty, officer"). > > > Oddly, the Android kernel environment (Kleaf) is the one that I needed > > > this patch to build in, but it seemed to be working without a manual > > > KBUILD_HOSTCFLAGS forwarding. > > > > Surprising that worked. > > > > > Overall, it sounds like you'd prefer if I set this to use > > > `KBUILD_HOSTLD` and `KBUILD_HOSTLDFLAGS`, and leave the linker flavor > > > to autodetect? > > > > Yes for the first two. > > > > Dunno, what precisely is a linker flavor? Is that like a flavor of ice cream? > > Oh, right looking at your link: > > https://doc.rust-lang.org/rustc/codegen-options/index.html#linker-flavor > > Seems like if `LLVM=1` is set, or `LD=ld.lld`, or CONFIG_LD_IS_LLD, then > > the flavor should be set to ld.lld, else ld. Then the > > KBUILD_HOSTLDFLAGS need to be passed, probably. > > > > But how are there "linker flavors" like ld or ld.lld if you just said > > "Rust unfortunately currently doesn't support invoking the linker > > directly: https://github.com/rust-lang/rust/issues/73632";. I'm having > > trouble reconciling the two. > Yes, what I meant by that is that *rustc* wants to invoke the linker, > rather than having the surrounding build system invoke the linker. The > exact command line passed to the linker in the final link, including > potential synthetic objects, is considered an internal detail. > > > > Can we do something more like the below? > > > > ifdef CONFIG_LD_IS_LLD > > hostrust_flags += -C linker-flavor=ld.lld > > else > > hostrust_flags += -C linker-flavor=ld > > endif > > hostrust_flags += -C linker=$(HOSTLD) <todo: figure out how to pass > > KBUILD_HOSTLDFLAGS> > Yes, I can make host linking use `$(HOSTLD)` and pass the flavor based > on CONFIG_LD_IS_LLD. I'll send a variant that does that this > afternoon. CONFIG_LD_IS_LLD=y states that the linker for the kernel space is LLD. Host programs should not be affected. -- Best Regards Masahiro Yamada
