================
@@ -288,8 +288,15 @@ Status ScriptedProcess::DoGetMemoryRegionInfo(lldb::addr_t
load_addr,
MemoryRegionInfo ®ion) {
Status error;
if (auto region_or_err =
- GetInterface().GetMemoryRegionContainingAddress(load_addr, error))
+ GetInterface().GetMemoryRegionContainingAddress(load_addr, error)) {
region = *region_or_err;
+ if (region.GetRange().GetRangeBase() == 0 &&
+ (region.GetRange().GetByteSize() == 0 ||
+ region.GetRange().GetByteSize() == LLDB_INVALID_ADDRESS)) {
----------------
jasonmolenda wrote:
I see what you mean for checking the address is contained within the range, and
rejecting it if not, this works too.
Right now if a stub returns {0, UINT64_MAX} and we don't have a memory
allocation packet, IRMemory::FindSpace will find no available virtual address
space and all expressions will fail.
My opposition to {0, UINT64_MAX} being accepted is that it's meaningless. No
processor actually has 64-bits of addressing, so telling me that all memory is
addressable is obviously wrong. It will break IRMemoryMap::FindSpace's
algorithm, and this response tells us nothing more than if qMemoryRegionInfo
was an unsupported packet.
https://github.com/llvm/llvm-project/pull/115963
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
