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