[Lldb-commits] [PATCH] D98529: [lldb] Strip pointer authentication codes from aarch64 pc.

Tue Mar 16 13:24:43 PDT 2021

jasonmolenda added a comment.

Sorry for not replying to this earlier.  Yeah, correct number of bits to mask off must be determined dynamically at runtime, by looking at the CPU's TCR_EL0.T0SZ value (or TCR_EL1.T0SZ for EL1 code like a kernel), which is the inverse of the number of bits used for addressing (T0Sz value of 25, 39 bits used for addressing).  When I added this support to the apple version of lldb, I hardcoded the number of bits used on our main processors and added a setting of target.process.virtual-addressable-bits for different cores -- because we didn't have any way of fetching these values at runtime.  Since then we've added a k-v pair to the qHostInfo,

send packet: $qHostInfo#9b
read packet: $cputype:16777228;cpusubtype:2;addressing_bits:47;ostype:macosx;watchpoint_exceptions_received:before;vendor:apple;os_version:11.3.0;maccatalyst_version:14.5;endian:little;ptrsize:8;#00

I need to finish this work and change this from a setting to an ivar in Process, and get all of this upstreamed. I also need to find a better name than ABI::FixCodeAddress, because we can have data addresses just as well (vtable pointer is a popular one), and an issue I didn't try to solve is that the question of *what* to strip is ABI dependent  - a Linux ptrauth ABI might not add auth bits to the vtable pointer where the Darwin one does.  But as long as you know a uint64_t is a pointer to a valid memory address, it is safe to strip the unaddressable bits off the top of that before dereferencing it - so I imagine we'll end up with calls into ABI::FixAddress (whatever it should be called) that are a superset of what every ptrauth-style ABI is authenticating.

I'm hoping to get moving on this upstreaming work early this summer, it's long overdue.

If this isn't soon enough--and I suspect from this patch that it is not--I can push up my patch for this not-great target.process.virtual-addressable-bits setting I came up with.  It was definitely a stopgap during bringup, though, and I'd hoped not to.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98529