[PATCH] D95755: [ELF] Support a few elf32lriscv_* & elf64lriscv_* emulations

Jessica Clarke via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Jan 31 20:36:23 PST 2021


jrtc27 added a comment.

In D95755#2533115 <https://reviews.llvm.org/D95755#2533115>, @jimw wrote:

> The binutils folks used to make a joke "The correct way to spell GNU ld is GCC".  Use of ld directly is discouraged.  However, we do have default paths in the linker, and those paths must be correct.  There are some situations where calling ld directly is not hard.  And there are people with 20 year old code that uses ld directly that still needs to work if it isn't wrong.  So I believe we need the emulations.

That doesn't quite follow. The code needs patching *anyway* to support RISC-V if it needs the emulation to be specified, so *how* you require it to be patched is entirely up to you. You could instead just say "don't do that" and make them write sane code rather than hacky BFD-specific code, whereas instead if you invoke LD directly and need to support multiarch then you need to have some hacky config stuff to detect what ABI is in use (which, incidentally, always ends up being parsing the output of `cc -v`'s --with-abi which is extremely GCC-specific and makes zero sense for Clang due to being much more flexible). Or you could pass `-L /foo/lp64d` rather than `-m elf64lriscv_lp64d`. So I disagree with that statement.

> The emulations are only visible between gcc and ld.  If you don't plan to support using gcc with lld then you don't need the emulations.

We do, but that makes no sense. GCC shouldn't need the emulations because it can just give the right search paths like Clang does. That's far cleaner, and more flexible, than having a whole family of emulations just to be able to configure ld's default search path.

> Or we could have a configure option or command line option to tell gcc that it will be used with lld instead of ld,, and then change the emulation names depending on which linker is being used.  I see that we already have the -fuse-ld= option in gcc that we could use.  There are also --enable-ld=X and --enable-gold configure options, but they don't seem to do much, other than setting a configure variable to give the name of the ld to use.  It seems to be primarily useful if doing a combined tree build (binutils+gcc) in which case gcc needs to know which of the two linkers (l.d.bfd or gold) to use.  It is also used to simplify some feature tests, for features which are known to be supported in gold and/or bfd.  Anyways, it doesn't seem to be used to control how gcc emits linker options.  But we could extend it for that use.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95755/new/

https://reviews.llvm.org/D95755



More information about the llvm-commits mailing list