<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 - lld --oformat binary fails to insert padding between sections."
href="https://bugs.llvm.org/show_bug.cgi?id=33651">33651</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>lld --oformat binary fails to insert padding between sections.
</td>
</tr>
<tr>
<th>Product</th>
<td>lld
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</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>All Bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>jnosh+llvmbugs@jnosh.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>The '--oformat binary' option should produce a raw binary representation of the
programs sections. However, at least under certain circumstances, LLD seems to
just output section contents directly after each other instead of at their
actual offsets as determined during linking. i.e. it does not add any padding
between sections.
Take the following simple example:
main.c:
'''
__attribute__ ((noinline))
__attribute__ ((optnone))
void consume_string(const char* data) { }
void _start() {
consume_string("Hello World!\n");
}
'''
link.lds:
'''
SECTIONS
{
.text :
{
*(.text)
}
*/ Depending on the assembly your compiler generates, you might have to
increase the alignment here to reproduce the issue. */
.rodata ALIGN(16) :
{
*(.rodata)
}
}
'''
Compile & link:
$ clang -c -target aarch64-arm-none -O2 -nostdlib -static main.c
$ ld.lld -nostdlib --oformat binary -T link.lds main.o -o binary.bin
(YMMV depending on versions of the involved tools but for me:)
If you look at the contents/disassembly of binary.bin you can see that the
address (PC-relative for aarch64) that is used for the string in the code
disassembly doesn't match that address the string is actually placed at in the
binary file.
The alignment of the .rodata section in the resulting binary file is of course
also wrong but I think the above is an even more obvious issue.
Compare this with a normal ELF binary:
$ ld.lld -nostdlib -T link.lds main.o -o prog.elf
Here the .text and .rodata section share a single segment but padding has been
placed between them to make sure their offsets are correct.
I'm not sure if there is any clear specification/documentation for '--oformat
binary' but I would expect it to be reasonably similar to 'objcopy -O binary'
and the result here seems pretty clearly broken...
I've tested both 'objcopy -O binary' and 'ld.gold --oformat binary' and both
produce the expected result in this case.
I haven't done any exploration if this only occurs under specific
configurations other than checking that it also occurs when compiling for a
'x86_64-none' target (and it does).
Versions used in my testing:
LLD 5.0.0 (<a href="http://llvm.org/git/lld.git">http://llvm.org/git/lld.git</a>
10ece687e960a10492d17df88d010edfa0c7592c)
Apple LLVM version 9.0.0 (clang-900.0.26)</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>