[Lldb-commits] [lldb] [lldb] Add isConstant mode for FA locations (PR #110726)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda approved this pull request.

LGTM.  Yes, the question of "when do we need to run an address through a Fix method" is largely driven by the different ABIs we encounter on different platforms.  If we know it is a virtual address value (no metadata in high bits/unaddressable bits that we may need to inspect), it is safe to run it through a Fix method.  The question of FixCode or FixData doesn't really matter here with aligned stack addresses, but a typical difference is that FixCode may clear the low 1 or 2 bits on targets with fixed length instructions, whereas FixData can point to a byte boundary so all of the low bits are typically preserved.

This does mean that we see Fix calls in generic code that are specific to how, e.g. Darwin's ABI signs a vtable pointer which might not be the case on all target using AArch64 ptrauth signing.  An example of where over-Fixing is a problem comes from Objective-C which has an "isa" pointer at the start of the object, identifying the object's metadata, and in some cases there may be a "non-pointer isa" (aka tagged pointer) which has the value of the object in the isa itself, e.g. a small NSNumber might be representable entirely within the isa word.  And so treating this non-pointer isa as a virtual address will clear significant bits and make it meaningless.

Practically speaking, we've moved to a model where we Fix addresses before we Read or Write from them in the Process, so even if we miss a Fix that was needed for a signed address, by the time we actually try to read from that address it will work.  This behavior is needed in the face of AArch64 MTE where we can have tags in the top nibble, or an AArch64 processor running in Top Byte Ignore mode where the inferior may store metadata in the type byte (Darwin's application processors run in TBI mode enabled).

https://github.com/llvm/llvm-project/pull/110726