[PATCH] D69755: [LLD] Add NetBSD support as a new flavor of LLD (nb.lld)

Tue Nov 5 10:47:46 PST 2019

MaskRay added a comment.

In D69755#1731420 <https://reviews.llvm.org/D69755#1731420>, @krytarowski wrote:

> In D69755#1731394 <https://reviews.llvm.org/D69755#1731394>, @MaskRay wrote:
>
> > I still have the feeling that such configurations should be added to clangDriver/gcc specs or a shell script wrapper of lld.
>
>
> OK, as you allow now a shell wrapper of lld, this is a progress. nb.lld is a C++ wrapper on steroids doing the right job and part of the upstream repo (this is required).
>
> We do not allow downstream LLVM/Clang/... patches in our basesystem and keeping this code upstream is required. Also from maintenance burden as LLVM APIs evolve quickly.

Yes, by upstreaming you will share maintenance burden with the upstream.. but do we really need it? LLVM and Clang APIs and unstable and evolve quickly, but that is unrelated to the linker. I have reviewed the options added in this patch. These GNU ld options (with the exception or --no-rosegment and --image-base) have been so ingrained that I don't think the lld upstream can suddenly stop supporting some options or make disruptive changes that break the behaviors.

>> How do you decide to handle "Handling of indirect shared library dependencies"? It does not seem to be favored by lld contributors.
> 
> The modern Linux/GNU behavior is rejected in NetBSD and we keep the traditional behavior that is considered by our community as desired.

Can you give links about the (1) rejection and (2) community needs? I am under the impression that some of the decisions are simply GNU hatred. I've mentioned in previous review comments that I don't like many GNU ELF things (STB_GNU_UNIQUE, STT_GNU_IFUNC, 4-byte Elf64_Nhdr fields, `strip/objcopy --strip-all` not stripping non-SHF_ALLOC, etc), some are bearable, because diverging the behavior may just cost more. However, for this particular `DT_RUNPATH` case, I don't really understand what it will cost if you follow the GNU behavior.

>    // force-disable RO segment on NetBSD due to ld.elf_so limitations
>   args.push_back("--no-rosegment");

I hope you can fix the limitation soon. I just implemented the --only-keep-debug feature for llvm-objcopy. My observation is that `--no-rosegment` can make the debug file produced by --only-keep-debug larger (larger readonly sections such as .dynsym, .dynstr, .rodata and .eh_frame will occupy much space that can be eliminated). Mixing sections of different permission in the same RX segment does not look nice, either.

> This is another topic and indeed probably our next major target to get to work within LLD.

I'm very concerned about this...... This traditional behavior will bring much complexity to the linker, while its usefulness is still very unclear to me.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69755