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

Tue Aug 18 22:04:24 PDT 2020

MaskRay added a comment.

Alan Modra kindly shared with me the history
https://sourceware.org/pipermail/binutils/1999-December/002952.html See
elf_link_is_defined_archive_symbol in bfd/elflink.c, which checks whether
a common symbol is a regular definition in an archive member.
LLD's current semantics are compatible with gold, and GNU ld 20 years ago
(before https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=a3a8c91d411abe91720a2ac92b8140e1bdb41282)
(I have to blame Sun/HP ld that time.... Note that `undef.o -lweak -lglobal` will
pick libweak.a and ignore libglobal.a if libglobal.a does not need fetching.)

Before we jump directly into a fix, can you create a FORTRAN example where this
special common symbol handling is reasonably used? (I use uppercase FORTRAN
because I think this is FORTRAN 77 legacy...) I know that it matches GNU ld, but
this is rather bizarre.  I hope the additional (very high; likely 100+ lines)
complexity in ArchiveFile and LazyObjFile's symbol resolution can be justified.

There are 3 directions:

- We don't need to address it at all. However, it seems that you may raise a reasonable FORTRAN use case.
- Add a Mach-O style -c option to llvm-ar (ranlib): don't add common symbols to the archive index. See below. (LazyObjFile will be inconsistent but your user does not likely use it I guess)
- We patch LLD.

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.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86142