<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 Arm simple BuildAttributes handling leads to incorrect disassembly"
href="https://bugs.llvm.org/show_bug.cgi?id=47996">47996</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>LLD Arm simple BuildAttributes handling leads to incorrect disassembly
</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>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</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>smithp352@googlemail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org, smithp352@googlemail.com
</td>
</tr></table>
<p>
<div>
<pre>In Summary: LLD should retain the SHT_ARM_ATTRIBUTES section with the highest
architecture (armv8 preferred to armv7) rather than picking the first
SHT_ARM_ATTRIBUTES section.
Arm (32-bit, not AArch64) relocatable object files have a section of type
SHT_ARM_ATTRIBUTES described by
<a href="https://developer.arm.com/documentation/ihi0045/latest/">https://developer.arm.com/documentation/ihi0045/latest/</a>
The build attributes contain information about what architecture and procedure
call standard the object was compiled to. The intention is that a static linker
use these attributes to reason about compatibility between relocatable objects
and to use them to guide the use of instructions in linker generated content
like Thunks.
LLD's handling of build attributes is minimal. It does what it needs to do to
detect the architecture so that it can use Arm v7 instructions in Thunks.
The meaning of BuildAttributes in executables and shared objects is not defined
by the ABI. The GNU tools have included it in the executable and certain
disassemblers including llvm-objdump use it to determine what architecture to
disassemble for.
LLD does the simplest possible thing and retains the first SHT_ARM_ATTRIBUTES
section with the theory that on a Linux/Android build people will compile all
their objects with the same flags anyway. This worked well for applications
targeting Armv7 as this is pretty much the baseline. Applications targeting
Armv8 using Armv8 features such as load-acquire and store-release instructions
have a problem as the first object is often crt0 or one of the other C-library
object files and this is Armv7. As a result LLD outputs build attributes
claiming to be Armv7 and the file doesn't disassemble properly.
The simplest way to fix this is to read the architecture build attributes and
prefer the SHT_ARM_ATTRIBUTES from the highest architecture. Note that a full
implementation of build attributes would do this for every individual build
attribute, issuing error messages for incompatible ones, this could be useful
for bare-metal embedded systems where there can be a lot of incompatibilities
between objects, probably not as important for A-profile linux/android.
Example:
// ldab.s armv8 only
.text
.thumb
ldab r0, [r0]
nop
// nop.s
.text
.thumb
nop.w
lvm-mc -filetype=obj -o ldab.o ldab.s --triple=armv8a
--arm-add-build-attributes
lvm-mc -filetype=obj -o nop.o nop.s --triple=armv7a --arm-add-build-attributes
ld.lld nop.o ldab.o -o ldab
llvm-objdump -d ldab
# nop.o first use Armv7 build attributes, ldab is not known
Disassembly of section .text:
000200b4 <$t.0>:
200b4: af f3 00 80 nop.w
000200b8 <$t.0>:
200b8: d0 <unknown>
200b9: e8 8f ldrh r0, [r5, #62]
200bb: 0f 00 movs r7, r1
200bd: bf <unknown>
ld.lld ldab.o nop.o -o ldab
llvm-objdump -d ldab
# ldab.o first use Armv8 build attributes, ldab is known
Disassembly of section .text:
000200b4 <$t.0>:
200b4: d0 e8 8f 0f ldab r0, [r0]
200b8: 00 bf nop
200ba: d4 d4 bmi #-88
000200bc <$t.0>:
200bc: af f3 00 80 nop.w</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>