- User Since
- Mar 12 2021, 9:39 AM (27 w, 3 d)
Apr 16 2021
Out of curiosity: Typically should one be able to set target.process.virtual-addressable-bits after the target has been created? Or is it expected that users will need to run in the following order only:
settings set target.process.virtual-addressable-bits ... target create -c ....
Apr 15 2021
On Darwin, we use the same number of bits for both code and data, but given the way ptrace() behaves on Linux, I'm guessing this may not be the case everywhere. Should we store both masks, and add FixCodeAddress + FixDataAddress methods in the ABI's, Justin? What do you think?
Apr 12 2021
Apr 8 2021
Mar 30 2021
Mar 29 2021
Can we move comments over to --> https://reviews.llvm.org/D98886, which has these changes implemented?
Mar 26 2021
Check CrashpadInfo version.
Mar 25 2021
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).
OK we may need to retain the manual setting when I upstream this, instead of going with the pure Process-maintained value determined dynamically by gdb packet or corefile metadata. If this is something you need for your own FixCodeAddress prelim patch, I can upstream the target.process.virtual-addressable-bits setting (I think the name is fine, even once Process can determine this dynamically). We'll need to decide at some point what the correct behavior is when they conflict, but if only one is set the choice is straightforward.
Mar 22 2021
Fix length of crashpad structure / use ulittleXX
Mar 18 2021
Mar 17 2021
uint32_t addressing_bits; size_t len = sizeof (uint32_t); ret = sysctlbyname("machdep.virtual_address_size", &addressing_bits, &len, NULL, 0);
In the meantime, I'll look into adding something to the Crashpad minidump format to store an addrable bits mask, although I'm not clear how to grab this in userspace. Should sysctl machdep.virtual_address_size work on iOS? Can I grab TCR_ELx.T0SZ directly?
Mar 16 2021
Breakpad/Crashpad are not transporting mach-o core files, they are using minidumps. minidumps don't contain any indication of the number of bits in the address. Apple Xcode lldb is still able to work with these minidumps correctly, while trunk lldb is not. How is it able to do this even when the dump file doesn't contain “addrable bits” or equivalent?
How does this work for a core dump?
Mar 15 2021
Move logic to ABIMacOSX_arm64.h
Mar 12 2021