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

[Fangrui Song via Phabricator via llvm-commits]

MaskRay 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;
----------------
peter.smith wrote:
> 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?
Thanks for the explanation! Then I think this should probably be: `(Inst | 0xc0) == 0xd50324df`


`(Insn & 0xd503245f) == 0xd503245f` accepts many other irrelevant bit patterns like 0xffffffff.


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

https://reviews.llvm.org/D62598