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

Sun Jan 31 18:56:45 PST 2021

jrtc27 added a comment.

In D95755#2533069 <https://reviews.llvm.org/D95755#2533069>, @jrtc27 wrote:

> In D95755#2533064 <https://reviews.llvm.org/D95755#2533064>, @MaskRay wrote:
>
>> In D95755#2532983 <https://reviews.llvm.org/D95755#2532983>, @luismarques wrote:
>>
>>> Overall seems fine to me.
>>
>> Thanks!
>>
>>> I don't know if it's worth it more thoroughly testing the various suffix combinations?
>>
>> That is excessive and does not seem to useful to me. I don't intend to add them in my binutils emulation & target triple patch https://sourceware.org/pipermail/binutils/2021-January/115156.html
>>
>> Actually, I am not sure adding `_ilp32f`/`_ilp32`/`_lp64f`/`_lp64` suffixes is a good idea if the only difference is the different library paths (which can be suppressed by `ld -nostdlib`). https://sourceware.org/bugzilla/show_bug.cgi?id=22962 @jimw
>>
>> LLD does not have the concept of default library paths. It works for all targets we support because the compiler drivers pass through the library paths.
>
> Yeah I really don't like the ABI emulations. elfXXlriscv is sufficient, the others should go (or at least never see the light of day in LLD if BFD needs to keep them for backwards compatibility).

And really people are supposed to invoke the linker through the GCC or Clang driver, that's the only supported interface. Anything else and they can deal with having to specify the search path manually, but 99% of the time the code is bad and can just use the driver, perhaps with the odd -Wl,-foo. Then you get the right search path by virtue of -mabi, no need for hacky emulations to support dubious glibc RISC-V-specific multiarch silliness.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95755