[PATCH] D86142: [LLD] Search archives for non-tentative defintions.

Mon Aug 24 16:49:57 PDT 2020

MaskRay added a comment.

In D86142#2234472 <https://reviews.llvm.org/D86142#2234472>, @sfertile wrote:

> In D86142#2225679 <https://reviews.llvm.org/D86142#2225679>, @psmith wrote:
>
>> Given that BFD supports this behaviour but Gold and LLD do not I suspect that the risk of breaking existing programs is small, especially as LLD tends to be used with more recent programs where -fno-common is the default. However I think we should be cautious and perhaps enable under a command line option, especially as it looks like this is a convention rather than part of a specification. If anyone has better references, then I'm happy to retract.
>
> I agree the new behavior needs an option to enable it and disable it. Initially I considered having the Fortran driver pass the option to LLD, but after discussing it offline with @rzurob I think it might be best to enable the behavior by default. The consumer of these libraries aren't necessarily Fortran programs, and as you mentioned its likely to be lower risk because we are adopting a behavior already implemented in ld.bfd.

There are 4 combinations: (ArchiveFile,LazyObjFile) x (ELF, BitcodeFile). LazyObjFile is for --start-lib/--end-lib. Do you think whether it is worth making LazyObjFile or BitcodeFile consistent with ArchiveFile x ELF behavior? If we add an option (say, `--fortran-linking`, the Dec 1999 binutils thread suggested but did not adopt), we will have better justification that we don't make LazyObjFile or BitcodeFile consistent.

I do worry a bit about the time complexity of the regular-overriding-common behavior, which may be a problem for my internal users (Bazel: --start-lib; we use very few `ArchiveFile`s) and external users (mostly `ArchiveFile`s).

> In D86142#2225447 <https://reviews.llvm.org/D86142#2225447>, @MaskRay wrote:
>
>> If we end up patching LLD, we should avoid making Symbol::resolveLazy complex.
>> We need to think hard doing symbol resolution in batch, in
>> ArchiveFile/LazyObjFile::parse. For the tests, all the code is insignificant.
>> My example at https://sourceware.org/pipermail/binutils/2020-August/112878.html
>> is probably sufficient. As you can see, bitcode LazyObjFile requires special handling.
>> I need to think about the interaction and I may be able to send a patch.
>
> That is why I posted a WIP patch early. So we could figure out what the best direction is. I'm open to any suggestions.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86142