[llvm-bugs] [Bug 31850] New: Revisit how we handle conflicts with section symbols

[via llvm-bugs]

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

            Bug ID: 31850
           Summary: Revisit how we handle conflicts with section symbols
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: MC
          Assignee: unassignedbugs at nondot.org
          Reporter: rafael.espindola at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

The gnu assembler rejects

.section foo,"a", at progbits
foo:
.data
.quad foo

and accepts

foo:
.section foo,"a", at progbits
.data
.quad foo

producing a relocation with the section foo.

clang accepts both and produces relocations with the symbol.

The gas behaviour really doesn't seem intentional. There is no good reason to
prefer a section name over another symbol or vice versa.

The current clang behaviour was implemented in bug 26941, but I think the
diagnostic there  is incorrect. The only reason gcc accepts

int xxx;
__attribute__((section("xxx"))) int f() { return xxx; }

is that gcc print ".comm xxx" before ".section xxx". The gnu assembler rejects
the current clang produced .s.

What bug 26941 is really about is a IR linker bug. From comment 5 we see that
the section is from one file and the symbol from another. Just like with any
other local symbol, the IR linker should detect that it conflicts with a symbol
(the section symbol) in another module and rename it.

And I think MC should just reject both cases listed in this bug.

-- 
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/20170202/1d741172/attachment.html>