Commit Graph

6 Commits

Author SHA1 Message Date
Fangrui Song 66bcbdbc9c [AArch64InstPrinter] Change printADRPLabel to print the target address in hexadecimal form
Similar to D77853. Change ADRP to print the target address in hex, instead of the raw immediate.
The behavior is similar to GNU objdump but we also include `0x`.

Note: GNU objdump is not consistent whether or not to emit `0x` for different architectures. We try emitting 0x consistently for all targets.

```
GNU objdump:       adrp x16, 10000000
Old llvm-objdump:  adrp x16, #0
New llvm-objdump:  adrp x16, 0x10000000
```

`adrp Xd, 0x...` assembles to a relocation referencing `*ABS*+0x10000` which is not intended. We need to use a linker or use yaml2obj.
The main test is `test/tools/llvm-objdump/ELF/AArch64/pcrel-address.yaml`

Differential Revision: https://reviews.llvm.org/D93241
2020-12-16 09:20:55 -08:00
Fangrui Song 7f36cb1f1a [AArch64InstPrinter] Change printAlignedLabel to print the target address in hexadecimal form
Similar to D76580 (x86) and D76591 (PPC).

```
// llvm-objdump -d output (before)
10000: 08 00 00 94                   bl      #32
10004: 08 00 00 94                   bl      #32

// llvm-objdump -d output (after)
10000: 08 00 00 94                   bl      0x10020
10004: 08 00 00 94                   bl      0x10024

// GNU objdump -d. The lack of 0x is not ideal due to ambiguity.
10000:       94000008        bl      10020 <bar+0x18>
10004:       94000008        bl      10024 <bar+0x1c>
```

The new output makes it easier to find the jump target.

Differential Revision: https://reviews.llvm.org/D77853
2020-04-10 09:21:09 -07:00
Fangrui Song f0374e7db2 [test] lld/test/: change llvm-objdump single-dash long options to double-dash options 2020-03-15 17:48:36 -07:00
Fangrui Song 71e2ca6e32 [llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:`
The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier.

`.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive.
Without `-LABEL`, the CHECK line can match the `Disassembly of section`
line and causes the next `CHECK-NEXT:` to fail.

```
Disassembly of section .foo:

0000000000001634 .foo:
```

Bdragon: <> has metalinguistic connotation. it just "feels right"

Reviewed By: rupprecht

Differential Revision: https://reviews.llvm.org/D75713
2020-03-05 18:05:28 -08:00
Tom Tan 7c81649219 [COFF] Align ARM64 range extension thunks at instruction boundary
RangeExtensionThunkARM64 is created for out-of-range branches on Windows ARM64
because branch instructions has limited bits to encode target address.
Currently, RangeExtensionThunkARM64 is appended to its referencing COFF section
from object file at link time without any alignment requirement, so if size of
the preceding COFF section is not aligned to instruction boundary (4 bytes),
RangeExtensionThunkARM64 will emit thunk instructions at unaligned address
which is never a valid branch target on ARM64, and usually triggers invalid
instruction exception when branching to it.

This PR fixes it by requiring such thunks to align at 4 bytes.

Differential revision: https://reviews.llvm.org/D72473
2020-01-10 19:03:17 -08:00
Martin Storsjo c9f4d25f26 [COFF] Create range extension thunks for ARM64
On ARM64, this is normally necessary only after a module exceeds
128 MB in size (while the limit for thumb is 16 MB). For conditional
branches, the range limit is only 1 MB though (the same as for thumb),
and for the tbz instruction, the range is only 32 KB, which allows for
a test much smaller than the full 128 MB.

This fixes PR40467.

Differential Revision: https://reviews.llvm.org/D57575

llvm-svn: 352929
2019-02-01 22:08:09 +00:00