[llvm-bugs] [Bug 43094] New: Potential bug for merging COMDAT groups with LOCAL signature symbols

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Aug 22 11:56:15 PDT 2019


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

            Bug ID: 43094
           Summary: Potential bug for merging COMDAT groups with LOCAL
                    signature symbols
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: leonardchan at google.com
                CC: llvm-bugs at lists.llvm.org, peter.smith at linaro.org

Created attachment 22415
  --> https://bugs.llvm.org/attachment.cgi?id=22415&action=edit
reproducer.tar.gz

When a particular symbol table entry is used as the signature symbol for a
comdat group, does it matter if the symbol is LOCAL when comdats are merged?
That is, if the signature symbol for comdat group `A` is LOCAL, is that comdat
group different from another one that also contains a symbol `A`? My
understanding is that if `A` in the first group is a LOCAL symbol, then it
cannot represent the symbol for any other object file, and thus the comdat
groups are different.

Example:

```
$ cat tmp1.s
.section .text.foo,"axG", at progbits,foo,comdat
.local foo
foo:
$ cat tmp2.s
.section .text.foo,"axG", at progbits,foo,comdat
.global foo
foo:
$ cat tmp3.s
.globl _start
_start:
  jmp foo
$ clang tmp1.s -c
$ clang tmp2.s -c
$ clang tmp3.s -c
$ ld.lld tmp1.o tmp2.o tmp3.o
ld.lld: error: relocation refers to a symbol in a discarded section: foo
>>> defined in tmp2.o
>>> section group signature: foo
>>> prevailing definition is in tmp1.o
>>> referenced by tmp3.o:(.text+0x1)
$ ld.lld tmp2.o tmp1.o tmp3.o  # Works fine
```

-- 
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/20190822/6f84f057/attachment.html>


More information about the llvm-bugs mailing list