DavidSpickett wrote: On the face of it
> When we have an unset high memory address mask, and we are told to set low- > and high-memory to the same new address mask, maintain the high memory mask > as unset in Process. The same thing is done with the > SBProcess::SetAddressMask API when the user specifies > lldb.eAddressMaskRangeAll. Seems to itself be confusing and if you're doing this to address > When high memory has a different set of masks, those become active in Process > and the user can use highmem-virtual-addressable-bits to override only the > highmem value, if it is wrong. You're adding one gotcha to avoid another. However, I think the result of the highmem mask being unset is the same as setting both masks to the same value. Except that `virtual-addressable-bits` will now effectively apply to both masks, until the user sets *only* the high mask to some value. At that point, `highmem-virtual-addressable-bits` must be used to modify the high mem value. Correct? So this doesn't actually change anything for an API user that was setting address masks for high and low all at once. They'll still think both are the same value, but *internally*, lldb tries high, see's that it's unset, and falls back to the low mask. https://github.com/llvm/llvm-project/pull/90533 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
