<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 does not seem to honour the linker script load address"
href="https://bugs.llvm.org/show_bug.cgi?id=34407">34407</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>lld does not seem to honour the linker script load address
</td>
</tr>
<tr>
<th>Product</th>
<td>lld
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>other
</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>ELF
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>eblot.ml@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>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</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>