[llvm-bugs] [Bug 34407] New: lld does not seem to honour the linker script load address

[via llvm-bugs]

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

            Bug ID: 34407
           Summary: lld does not seem to honour the linker script load
                    address
           Product: lld
           Version: unspecified
          Hardware: Other
                OS: other
            Status: NEW
          Severity: normal
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: eblot.ml at gmail.com
                CC: llvm-bugs at lists.llvm.org

It seems that LLD ignore the AT() directive from the linker script, such as:

    .ARM.exidx :
    {
        *(.ARM.exidx* .gnu.linkonce.armexidx.*)
    } > FLASH

    __etext = .;

    .data : AT (__etext)
    {
    /* ... */
    } > RAM

as the .data section storage location in ELF file is indicated as its virtual
address, not its physical address.

It does not emit any warnings/errors, and silently generates an invalid output
ELF executable file.

The .data section, dumped with readelf -l, are as follow:

lld:
  LOAD           0x004800 0x20002800 0x20002800 0x00080 0x00080 RW  0x1000
gnuld:
  LOAD           0x012800 0x20002800 0x00021820 0x00080 0x000b0 RW  0x10000


The issue with the current example is that the .data section is not available
at run time, and the application therefore crashes as random data are copied
then used from the defined storage location (FLASH) into the section VMA (RAM),
while the source .data section is not filled in in FLASH.

Here is the output of the readelf tool. The first ELF file is linked with GNU
ld, the second ELF is linked with LLD. See below.

Both ARMv7 EABI ELF files are generated from the same object files - built with
clang 5.0.0-rc4.

readelf -l gnu.elf lld.elf 

File: gnu.elf

Elf file type is EXEC (Executable file)
Entry point 0x1ffd9
There are 4 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  EXIDX          0x011818 0x00021818 0x00021818 0x00008 0x00008 R   0x4
  LOAD           0x000000 0x00010000 0x00010000 0x11820 0x11820 R E 0x10000
  LOAD           0x012800 0x20002800 0x00021820 0x00080 0x000b0 RW  0x10000
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x10

 Section to Segment mapping:
  Segment Sections...
   00     .ARM.exidx
   01     .isr_vector .text .ARM.exidx
   02     .data .bss
   03

File: lld.elf

Elf file type is EXEC (Executable file)
Entry point 0x20eed
There are 7 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x0001e034 0x0001e034 0x000e0 0x000e0 R   0x4
  LOAD           0x000000 0x0001e000 0x0001e000 0x03ab4 0x03ab4 R E 0x1000
  LOAD           0x004800 0x20002800 0x20002800 0x00080 0x00080 RW  0x1000
  LOAD           0x004880 0x20002880 0x20002880 0x00000 0x00030 RW  0x1000
  GNU_RELRO      0x004880 0x20002880 0x20002880 0x00000 0x01000 R   0x1
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0
  EXIDX          0x0037bc 0x000217bc 0x000217bc 0x002f8 0x002f8 R   0x4

 Section to Segment mapping:
  Segment Sections...
   00
   01     .isr_vector .text .pwr_mgmt_data .ARM.exidx
   02     .data
   03     .fs_data .bss
   04     .fs_data .bss
   05
   06     .pwr_mgmt_data .ARM.exidx

-- 
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/20170901/28768876/attachment-0001.html>