[llvm-bugs] [Bug 45594] New: lld resolves reloc to sym in discarded section to 0 if sym_name < originating_sym_name

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=45594

            Bug ID: 45594
           Summary: lld resolves reloc to sym in discarded section to 0 if
                    sym_name < originating_sym_name
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: rprichard at google.com
                CC: llvm-bugs at lists.llvm.org, smithp352 at googlemail.com

Created attachment 23386
  --> https://bugs.llvm.org/attachment.cgi?id=23386&action=edit
lld-comdat-missing-diag.sh

If an object file has a relocation to a symbol from a discarded section, lld
normally issues an error:

    ld.lld: error: relocation refers to a symbol in a discarded section: zzz

I've found a case where ld.lld doesn't issue the error, though, and instead
resolves the relocation to 0:
 - the object file is in an archive
 - the relocation target symbol's name comes before the name of the function
containing the relocation (e.g. in ASCII order).

e.g. If "mmm2" calls "aaa", there is no diagnostic, and the program crashes,
but if it calls "zzz", there is an linker error.

I tried ld.bfd and ld.gold, and both issue a linker error even when "mmm2"
calls "aaa".

The diagnostic is issued if the archive is surrounded with --whole-archive /
--no-whole-archive on the linker command-line.

I tried debugging it a little, and it seemed that the discarded symbol was not
of kind Symbol::UndefinedKind but of kind Symbol::LazyArchiveKind.

I originally noticed this problem in the Android platform, on 32-bit x86, where
we have various copies of the __x86.get_pc_thunk.bx function floating around,
some in .gnu.linkonce.t.__x86.get_pc_thunk.bx sections and others in
.text.__x86.get_pc_thunk.bx sections. lld drops the .gnu.linkonce.* copy (which
is fine) but then produces an executable without the function, with calls to
address "0". I'd expect lld to either use the .text.* copy or issue an error.
Either is OK -- Android should switch over to comdat. I opened
http://b/154376560 in Google's tracker for that.)

I'll attach scripts for reproducing:
 - the problem with comdat section groups
 - the problem with .gnu.linkonce.t.__x86.get_pc_thunk.bx

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200418/10ebadce/attachment.html>