[PATCH] D95985: [ELF] Resolve defined symbols before undefined symbols

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

In D95985#2541317 <https://reviews.llvm.org/D95985#2541317>, @peter.smith wrote:

>> The real world case is reduced from a Fuchsia PGO usage: a.a(a.o) has a constructor within COMDAT group C5
>> while a.a(b.o) has a constructor within COMDAT group C2. Because they use
>> different group signatures, they are not de-duplicated.
>
>
>
>> LLD selects the PGO counter section (__profd_*) from a.a(b.o) and the
>> constructor section from a.a(a.o). The __profd_* is a SHF_LINK_ORDER section
>> linking to its own non-prevailing constructor section, so LLD errors
>> sh_link points to discarded section. This patch fixes the error.
>
> Can you write out the example in full, I'm not sure I got it. I would expect that if C5 and C2 have different signatures they should both be loaded as to the linker they are entirely separate entities. If the __profd_* sections have link order dependencies into group sections are not in the same group I think we have a problem with ELF file and not with the linker. Have I misunderstood the example?
>
> Will need to have a think. I don't have any particular attachment to the way that we resolve undefined symbols today so I'm not going to object if there are other benefits.



  parse ArchiveFile a.a
    entry fetches a.a(a.o)
    parse ObjectFile a.o
      define entry
      define foo
      reference b
      b fetches a.a(b.o)
      parse ObjectFile b.o
        define prevailing __profd_foo
      define (ignored) non-prevailing __profd_foo

Is the reduced example. The original case is (folks may not want to read it):

  parse ArchiveFile libunwindstack.a
    _ZN11unwindstack8Unwinder6UnwindEPKNSt3__26vectorINS1_12basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEENS6_IS8_EEEESC_ fetches libunwindstack.Unwinder.cpp.o
    parse ObjectFile libunwindstack.Unwinder.cpp.o
      _ZN11unwindstack3Elf12GetLastErrorEPNS_9ErrorDataE fetches libunwindstack.Elf.cpp.o
      parse ObjectFile libunwindstack.Elf.cpp.o
        _ZN11unwindstack12ElfInterface11GetLoadBiasI10Elf32_Ehdr10Elf32_PhdrEEmPNS_6MemoryE fetches libunwindstack.ElfInterface.cpp.o
          parse ObjectFile libunwindstack.ElfInterface.cpp.o
            _ZN11unwindstack19DwarfEhFrameWithHdrIjE12GetFdeFromPcEm fetches libunwindstack.DwarfEhFrameWithHdr.cpp.o
            parse ObjectFile libunwindstack.DwarfEhFrameWithHdr.cpp.o
              defines _ZN11unwindstack19DwarfEhFrameWithHdrIjEC2EPNS_6MemoryE
              references __profd__ZN11unwindstack19DwarfEhFrameWithHdrIjEC2EPNS_6MemoryE
                libunwindstack.ElfInterface.cpp.o defines __profd__ZN11unwindstack19DwarfEhFrameWithHdrIjEC2EPNS_6MemoryE
  
  Let me abbreviate the long symbol to xxx6MemoryE.
  
  If we let the ancestor parsing frame (libunwindstack.ElfInterface.cpp.o; simplified as b.o in my example) to define `__profd_xxx6MemoryE`, `xxx6MemoryE` and `__profd_xxx6MemoryE` will be defined by the same file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95985