[PATCH] D130215: [DebugInfo] Teach dwarfdump and lldb about ptrauth DWARF tags and attributes

Thu Jul 21 09:01:47 PDT 2022

JDevlieghere marked an inline comment as done.
JDevlieghere added inline comments.

================
Comment at: llvm/include/llvm/BinaryFormat/Dwarf.def:228
 HANDLE_DW_TAG(0x4200, APPLE_property, 0, APPLE, DW_KIND_NONE)
+HANDLE_DW_TAG(0x4300, LLVM_ptrauth_type, 0, APPLE, DW_KIND_NONE)

----------------
jhenderson wrote:
> This section of the file seems to be in numerical value order, so this tag needs to be after the SUN* tags.
> 
> Has the value been finalised, and is the `APPLE` bit of this line correct (it might be, I'm not all that familiar with the tags)? It seems odd putting it here when we already have another block of LLVM tags (well one tag) further down which surely should be extended, rather than adding a second block?
Yes, the values are finalized in the sense that this is what we've been generating for several years and the goal of this change is to make dwarfdump and friends understand existing binaries. I can move it into the LLVM block, but that doesn't fix the ordering problem. Do you want me to create another LLVM block between SUN and ALTIUM?

================
Comment at: llvm/include/llvm/BinaryFormat/Dwarf.def:601-606
+HANDLE_DW_AT(0x3e04, LLVM_ptrauth_key, 0, APPLE)
+HANDLE_DW_AT(0x3e05, LLVM_ptrauth_address_discriminated, 0, APPLE)
+HANDLE_DW_AT(0x3e06, LLVM_ptrauth_extra_discriminator, 0, APPLE)
 HANDLE_DW_AT(0x3e07, LLVM_apinotes, 0, APPLE)
+HANDLE_DW_AT(0x3e08, LLVM_ptrauth_isa_pointer, 0, APPLE)
+HANDLE_DW_AT(0x3e09, LLVM_ptrauth_authenticates_null_values, 0, APPLE)
----------------
jhenderson wrote:
> Is `APPLE` actually correct here? These are LLVM attributes after all. Labelling them as coming from APPLE vendors seems wrong?
I'm fine either way. I went with Apple as the vendor to match the `LLVM_apinotes` which is another thing that's specific to our platform.

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

https://reviews.llvm.org/D130215