llvm-objdump doesn't recognise HVC instructions for arm32

[andyhhp]

Given

$ cat hvc.S
        .text
        .code 32

hvc:
        hvc #0xea1

Clang happily compiles the file, given -march=armv7ve

$ clang-15 --target=arm-linux-gnueabihf -march=armv7ve -c hvc.S -o hvc.o

but llvm-objdump doesn't tolerate the instruction

$ llvm-objdump-15 -d hvc.o

hvc.o:	file format elf32-littlearm

Disassembly of section .text:

00000000 <hvc>:
       0: 71 ea 40 e1  	<unknown>

GNU objdump is happy

$ arm-linux-gnueabihf-objdump -d hvc.o

hvc.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <hvc>:
   0:	e140ea71 	hvc	3745	; 0xea1

In this case, HVC instructions are present because this is a micokernel. Given that HVC is a valid instruction in arm32, llvm-objdump should decode it.

[llvmbot]

@llvm/issue-subscribers-tools-llvm-objdump

[llvmbot]

@llvm/issue-subscribers-backend-arm

[efriedma-quic]

On ARM, llvm-objdump guesses what target you're using based on the arm elf attributes. For compiler-generated output, those are usually accurate, but if you're writing assembly by hand, they likely aren't present. In that case, objdump currently just defaults to ARMv4. You can override this analysis using --mattr=+v7 or something like that.

It's possible that llvm-objdump should just assume armv8-a encodings in the absence of other information.

[andyhhp]

This was a very simplified example. The code I took it from was C with inline assembly generating the HVC.

$ cat hvc.c
void hvc(void)
{
    asm ("hvc #0xea1");
}

with

$ clang-15 --target=arm-linux-gnueabihf -march=armv7ve -c hvc.c -o hvc.o

still yields

$llvm-objdump-15 -d hvc.o 

hvc.o:	file format elf32-littlearm

Disassembly of section .text:

00000000 <hvc>:
       0: 71 ea 40 e1  	<unknown>
       4: 1e ff 2f e1  	bx	lr

The entire object file is:

$ readelf -Wa hvc.o
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          420 (bytes into file)
  Flags:                             0x5000000, Version5 EABI
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         10
  Section header string table index: 1

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .strtab           STRTAB          00000000 000138 00006c 00      0   0  1
  [ 2] .text             PROGBITS        00000000 000034 000008 00  AX  0   0  4
  [ 3] .ARM.exidx        ARM_EXIDX       00000000 00003c 000008 00  AL  2   0  4
  [ 4] .rel.ARM.exidx    REL             00000000 000130 000008 08   I  9   3  4
  [ 5] .comment          PROGBITS        00000000 000044 000055 01  MS  0   0  1
  [ 6] .note.GNU-stack   PROGBITS        00000000 000099 000000 00      0   0  1
  [ 7] .ARM.attributes   ARM_ATTRIBUTES  00000000 000099 000046 00      0   0  1
  [ 8] .llvm_addrsig     LOOS+0xfff4c03  00000000 000138 000000 00   E  9   0  1
  [ 9] .symtab           SYMTAB          00000000 0000e0 000050 10      1   4  4
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  D (mbind), y (purecode), p (processor specific)

There are no section groups in this file.

There are no program headers in this file.

There is no dynamic section in this file.

Relocation section '.rel.ARM.exidx' at offset 0x130 contains 1 entry:
 Offset     Info    Type                Sym. Value  Symbol's Name
00000000  0000022a R_ARM_PREL31           00000000   .text

Unwind section '.ARM.exidx' at offset 0x3c contains 1 entry:

0x0: 0x1 [cantunwind]


Symbol table '.symtab' contains 5 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 00000000     0 FILE    LOCAL  DEFAULT  ABS hvc.c
     2: 00000000     0 SECTION LOCAL  DEFAULT    2 .text
     3: 00000000     0 NOTYPE  LOCAL  DEFAULT    2 $a.0
     4: 00000000     8 FUNC    GLOBAL DEFAULT    2 hvc

No version information found in this file.
Attribute Section: aeabi
File Attributes
  Tag_conformance: "2.09"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv3
  Tag_Advanced_SIMD_arch: NEONv1
  Tag_ABI_PCS_R9_use: V6
  Tag_ABI_PCS_RW_data: PC-relative
  Tag_ABI_PCS_RO_data: PC-relative
  Tag_ABI_PCS_GOT_use: GOT-indirect
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Unused
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_VFP_args: VFP registers
  Tag_ABI_optimization_goals: Aggressive Debug
  Tag_CPU_unaligned_access: v6
  Tag_ABI_FP_16bit_format: IEEE 754
  Tag_MPextension_use: Allowed
  Tag_DIV_use: Allowed in v7-A with integer division extension
  Tag_Virtualization_use: TrustZone and Virtualization Extensions

so the virt extensions are noted in the file attributes.

[efriedma-quic]

The deduction code is at

llvm-project/llvm/lib/Object/ELFObjectFile.cpp

Line 158 in 985eaa1

SubtargetFeatures ELFObjectFileBase::getARMFeatures() const {

.

It looks like it's not parsing MPextension_use or Virtualization_use; that's a bug.

[MaskRay]

Is it useful to port https://reviews.llvm.org/D128029 ([AArch64] Add target feature "all") to ARM?

[efriedma-quic]

In general, ARM compilers for ELF generally encode information about the target into object files, so it's not as much of an issue. But it might be useful: if the code is doing runtime feature detection, or we're dealing with at handwritten assembly, some available instructions might not be automatically detected.

It's a little complicated, though, because the armv8-m instruction set has significantly diverged from armv8-a. Not sure if that means we want separate "all-a" and "all-m" features.