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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to