DavidSpickett added a reviewer: DavidSpickett. DavidSpickett added a comment.
Seems like a valid thing to do. Is it a problem that maybe you read from address N to N+100 and the problem address is actually at N+50, not N? I think you might be handling that already but I didn't read all the logic just your additions. Maybe not an issue because a lot of this is done in pages of memory, unlikely to be a <10 byte gap where something fails (and you can manually flush the cache if that somehow happens). > In this case, the elements often have the value 0, so lldb is trying to read > memory at address 0, which fails, and the number of reads is quite large. In this environment I guess they don't have a dynamic loader to have set the ranges? So in Mac OS userspace, this wouldn't be a problem because the zero page would be marked as always invalid, but they don't have that luxury. And there's nothing stopping a bare metal program from mapping memory at 0, so one can't just say 0 means invalid 100% of the time. > doesn't address the fact that m_invalid_ranges is intended to track > inaccessible memory that is invariant during the process lifetime. Please add this as a comment, will be good to know if/when there are two lists involved. ================ Comment at: lldb/source/Target/Memory.cpp:157 + if (IsAddressUnreadable(addr)) { + error.SetErrorStringWithFormat("memory read failed for 0x%" PRIx64, addr); + return 0; ---------------- Should this be more specific like "failed because we know this is unreadable" or "has previously failed to read"? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134906/new/ https://reviews.llvm.org/D134906 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits