[llvm-bugs] [Bug 32331] New: symbol defined in linker script populated with incorrect address

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Mar 17 14:31:43 PDT 2017


            Bug ID: 32331
           Summary: symbol defined in linker script populated with
                    incorrect address
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: superjoe30 at gmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 18122
  --> https://bugs.llvm.org/attachment.cgi?id=18122&action=edit

Using the below linker script, the attached LLVM IR module, and the below LLD
invocation, the symbol __bss_end gets the address 0x547 instead of 0xad54 as

clang -o clashos.o -c main.ll
ld.lld -T linker.ld --gc-sections -m armelf_linux_eabi -Bstatic -o clashos
clashos.o memset.o memcpy.o compiler_rt.o



    . = 0x8000;

    .text : ALIGN(4K) {

    .rodata : ALIGN(4K) {

    .data : ALIGN(4K) {

    __bss_start = .;
    .bss : ALIGN(4K) {
    __bss_end = .;

What appears to be happening is that __bss_end is equal to __bss_start, because
there are no .bss section global variables. Using GNU binutils ld, __bss_start
and __bss_end both get the same address, as expected. With LLD, __bss_end gets
an address that is less than __bss_start, which is unexpected, and causes an
integer overflow in code that expects to be able to do __bss_end - __bss_start
to get the size of the .bss section.

When I add a global variable that goes in the .bss section, LLD then correctly
sets __bss_end.

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/20170317/24cd2527/attachment.html>

More information about the llvm-bugs mailing list