justincohen added a comment.
> Clearing PAC bits is a little more complicated than just clearing the bits, > though. Bit 55 tells us whether the high bits are all 0's or all 1's (on > Darwin, in EL0 processes they're all 0's, in EL1, all 1's). If we had a > setting to provide a mask instead of the number of bits that are valid in > addressing, that might lead someone to try to use it for a different purpose. > Trying to imagine a scenario like this, maybe someone could know that a > certain range of the address space isn't used for a certain type of pointer, > and that they could reuse those bits as a Top Byte Ignore kind of thing, but > the generated code would need to clear/set those bits before dereferencing, > or we'd need a CPU with that kind of capability. Maybe there could be > examples of this today like the thumb bit on armv7, where the 0th bit on > something with alignment restrictions can be used to carry metadata, although > I can't think of anything like that on AArch/x86_64 (the only two targets I > can really remember well these days). Copying over a comment from pcc@ on the minidump change here: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2773358/5//COMMIT_MSG#15 : > On Linux, the mask that you get from NT_ARM_PAC_MASK specifies which bits > need to be cleared from the pointer. So to use the mask, you AND with the > inverse. > This also has the advantage that 0 is not a special case, since you can AND > with its inverse and get the same pointer back. What if we invert the mask, and do something like instead? `(ptr & (1ULL << 55)) ? (ptr | mask) : (ptr & ~mask);` This should be very similar to the pseudocode here: https://webcache.googleusercontent.com/search?q=cache:3fCUm601caMJ:https://developer.arm.com/ja/docs/ddi0596/latest/shared-pseudocode-functions/aarch64-functionspac-pseudocode+&cd=2&hl=en&ct=clnk&gl=us Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98529/new/ https://reviews.llvm.org/D98529 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
