[PATCH] D62598: [AArch64][ELF][llvm-objdump] Add support for PLT decoding with BTI instructions present

[Peter Smith via Phabricator via llvm-commits]

peter.smith marked 2 inline comments as done.
peter.smith added inline comments.


================
Comment at: lib/Target/AArch64/MCTargetDesc/AArch64MCTargetDesc.cpp:171
+      // Check for optional bti c that prefixes adrp in BTI enabled entries
+      if ((Insn & 0xd503245f) == 0xd503245f) {
+         Off = 4;
----------------
MaskRay wrote:
> I'm not familiar with the encoding.. but does this mean other bit patterns (e.g. 0xffffffff) should also be accepted?
Apologies I'm not sure I understand. I've put what I know in this comment. Please let me know if I've missed something?

At the moment I don't think any other bit-patterns are necessary. As I understand it the function will look for either:

```
bti c
adrp 
```
or
```
adrp
```
To denote the start of a PLT entry. If neither of those is found then we'll skip all instructions till we find one. All but one type of AArch64 PLT entry follows this form. There is one other "pseudo" PLT entry type that can be generated by ld.bfd (but not LLD) for the lazy resolver of TLSDESC variables. If it is present there is always only one entry at the end of the PLT. It can be generated by the following:

```
extern __thread int val __attribute__((tls_model("global-dynamic")));

int func() {
    return val;
}
aarch64-linux-gnu-gcc  tls.c -O2 -fpic --shared -o tls.so

```
It is of the form.
```
_dl_tlsdesc_lazy_trampoline
  stp   x2, x3, [sp, #-16]!
  adrp  x2, DT_TLSDESC_GOT
  adrp  x3,  PLTGOT
  ldr   x2, [x2, :lo12:DT_TLSDESC_GOT]
  add   x3, x3, :lo12:PLTGOT
  br    x2
``` 
Note that gnu objdump doesn't seem to disassemble it as part of the PLT, so I've not added any support for it. I guess that could come as a separate patch if we wanted to.

I'm looking to match exactly one instruction BTI with exactly one type of operand "c" so the encoding can be precise.

The encoding for BTI c (quoting from  DDI_0596_ARM_a64_instruction_set_architecture.pdf link in the description)
| 1 1 0 1 | 0 1 0 1 | 0 0 0 0 | 0 0 1 1 | 0 0 1 0 | 0 1 0 0 | x x 0 1 | 1 1 1 1 |
|     d       |      5      |      0     |      3      |       2     |       4     | x x 0 1 |      f       |
where xx is:
| 00 | (omitted) |
| 01 | c |
| 10 | j |
| 11 | jc |
For BTI c we'd want 0 1 0 1, which is 5.

Hope that answers the question?


================
Comment at: test/tools/llvm-objdump/AArch64/plt.test:1
-// RUN: llvm-objdump -d %p/Inputs/cfi.elf-aarch64 | FileCheck %s
+# RUN: llvm-objdump -d %p/Inputs/cfi.elf-aarch64 | FileCheck %s
 
----------------
MaskRay wrote:
> `--no-show-raw-insn` to avoid `bl {{.*}} <f1 at plt>` below.
The regex here will be for the offset in the branch which --no-show-raw-insn doesn't affect. It comes out as something like bl 48 <f1 at plt>. I've kept the regex for now as I'm not sure how stable the yaml2obj output will be.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62598/new/

https://reviews.llvm.org/D62598