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



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to