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