[llvm-bugs] [Bug 47996] New: LLD Arm simple BuildAttributes handling leads to incorrect disassembly

[via llvm-bugs]

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

            Bug ID: 47996
           Summary: LLD Arm simple BuildAttributes handling leads to
                    incorrect disassembly
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: smithp352 at googlemail.com
                CC: llvm-bugs at lists.llvm.org, smithp352 at googlemail.com

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
https://developer.arm.com/documentation/ihi0045/latest/

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

-- 
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/20201028/f8c73b51/attachment.html>