[Lldb-commits] [lldb] [lldb] Be conversative about setting highmem address masks (PR #90533)

[Jason Molenda via lldb-commits]

jasonmolenda 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, sees that it's unset, and falls back to the low mask.

I'm not thrilled about where I'm ending up. 

For the vast majority of our users, the separate address masks for high and low memory will never occur, it's an unusual environment that sets up the MMU this way, and operates in both halves of memory.  The goal of this patch is to keep the high memory masks unset (set to LLDB_INVALID_MASK) unless someone sets them to a value distinct from the "low memory" masks.

I almost think about changing these masks in Process to be a class which holds either {code, data} or {low code, low data, high code, high data} internally, with methods to get/set the masks and the requirement that high and low be set simultaneously when they're both going to be specified so we can detect if it's genuinely a split-address space situation.  

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