[llvm-bugs] [Bug 43457] New: attributes that force symbols into named sections can create broken ELF output

[via llvm-bugs]

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

            Bug ID: 43457
           Summary: attributes that force symbols into named sections can
                    create broken ELF output
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: MC
          Assignee: unassignedbugs at nondot.org
          Reporter: bd1976llvm at gmail.com
                CC: llvm-bugs at lists.llvm.org

Attributes that force the compiler to place symbols into the same section can
create broken ELF output if those symbols are incompatible.

Consider the following test case:

@foo = unnamed_addr constant [4 x i32] [i32 1, i32 0, i32 0, i32 1], align 16
"rodata-section"=".explicit" 

@bar = unnamed_addr constant [9 x i64] [i64 0, i64 0, i64 0, i64 0, i64 0, i64
0, i64 0, i64 0, i64 1], align 16 "rodata-section"=".explicit" 

which if run through llc results in:

        .type   foo, at object             # @foo
        .section        .explicit,"aM", at progbits,16
        .globl  foo
        .p2align        4
foo:
        .long   1                       # 0x1
        .long   0                       # 0x0
        .long   0                       # 0x0
        .long   1                       # 0x1
        .size   foo, 16

        .type   bar, at object             # @bar
        .globl  bar
        .p2align        4
bar:
        .quad   0                       # 0x0
        .quad   0                       # 0x0
        .quad   0                       # 0x0
        .quad   0                       # 0x0
        .quad   0                       # 0x0
        .quad   0                       # 0x0
        .quad   0                       # 0x0
        .quad   0                       # 0x0
        .quad   1                       # 0x1
        .size   bar, 72

The entsize of the resulting .explicit section is less than the size of symbol
bar. This is an incorrect ELF as the linker can merge entsize pieces of this
section at link time which will result in incorrect output, given this input.

In this case the compiler has created an incorrect SHF_MERGE section as two
constant symbols with different sizes were placed in the same section and, at
the time of writing, the created section derives its properties from the first
symbol to be placed in the section - which is why the entsize for the .explicit
section is 16.

GCC does not produce a mergable section for this test case.

In terms of clang source code:

#pragma clang section ... -
https://clang.llvm.org/docs/LanguageExtensions.html#specifying-section-names-for-global-objects-pragma-clang-section

and

_attribute_ ((section ("section-name"))) -
https://clang.llvm.org/docs/AttributeReference.html#section-declspec-allocate

map to IR attributes that can cause this bug.

Ideas for a fix:

- Allow these attributes to create multiple sections, each with the same name,
rather than a single section. This can be done by checking if the section
properties required for a given symbol are incompatible with any existing
section of the same name and creating a new section if they are.

- Try to create sections that can safely have different kinds of symbols placed
into them. Error if symbols are truly incompatible.

For the specific case of SHF_MERGE sections a simple fix is to not put symbols
into SHF_MERGE sections if they have been explicitly assigned to a section.
This misses out on the SHF_MERGE optimizations in the linker - but only for
symbols that have been explicitly placed in a section (rare?). This change may
be worth making first before tackling the larger problem.

-- 
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/20190926/9490c345/attachment.html>