[llvm-bugs] [Bug 33651] New: lld --oformat binary fails to insert padding between sections.

[via llvm-bugs]

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

            Bug ID: 33651
           Summary: lld --oformat binary fails to insert padding between
                    sections.
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: jnosh+llvmbugs at jnosh.com
                CC: llvm-bugs at lists.llvm.org

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 (http://llvm.org/git/lld.git
10ece687e960a10492d17df88d010edfa0c7592c)
Apple LLVM version 9.0.0 (clang-900.0.26)

-- 
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/20170630/6f012c6c/attachment.html>