<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - attributes that force symbols into named sections can create broken ELF output"
href="https://bugs.llvm.org/show_bug.cgi?id=43457">43457</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>attributes that force symbols into named sections can create broken ELF output
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Windows NT
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>MC
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>bd1976llvm@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>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,@object # @foo
.section .explicit,"aM",@progbits,16
.globl foo
.p2align 4
foo:
.long 1 # 0x1
.long 0 # 0x0
.long 0 # 0x0
.long 1 # 0x1
.size foo, 16
.type bar,@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 ... -
<a href="https://clang.llvm.org/docs/LanguageExtensions.html#specifying-section-names-for-global-objects-pragma-clang-section">https://clang.llvm.org/docs/LanguageExtensions.html#specifying-section-names-for-global-objects-pragma-clang-section</a>
and
_attribute_ ((section ("section-name"))) -
<a href="https://clang.llvm.org/docs/AttributeReference.html#section-declspec-allocate">https://clang.llvm.org/docs/AttributeReference.html#section-declspec-allocate</a>
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>