[Lldb-commits] [lldb] [lldb] Memory cache: no overlap and read across cache entries (PR #222688)
Yao Qi via lldb-commits
lldb-commits at lists.llvm.org
Mon Sep 14 03:39:37 PDT 2026
qiyao wrote:
> The only high level piece of feedback I have left is that I, personally, would not have tried to handle the cases where address + length overflow, as it makes some parts of the code harder to reason about. This is for two reasons:
>
> 1. if this overflows in the LLDB code, it would likely also overflow in the process itself, so realistically this code should never trigger.
> 2. To provide some safety, I would simply have had an early return at the entry point of the caches: if a addr+length cache request overflows, just don't cache it.
That is a fair point on the insert path, and I will have a followup PR for it. On the flush path I would rather keep the clamp. The reason is below,
first of all, the overflow handling is not new in this PR. `MemoryCache::Flush` has carried an explicit guard since 2012, de0e9d04ad17 and `MemoryCache::Read` has avoided overflow in cee6c47a62c4 (2019) too. `main` handles overflow in the L2 walk and gets it wrong in the L1 walk, that is the FIXME on `TestFlushAtTheTopOfTheAddressSpace`, and this PR fixes/removes it.
The early return works for the insert path, but not for the flush path. `Flush` is invalidation, and its only caller is `Process::WriteMemory`, which flushes before it writes. Not flushing an overflowing range leaves the pre-write bytes cached and the next read hands them back as valid, and it may cause a wrong read value.
https://github.com/llvm/llvm-project/pull/222688
More information about the lldb-commits
mailing list