================ @@ -0,0 +1,42 @@ +//===-- MemoryRegionInfoCache.h ---------------------------------*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// + +#ifndef LLDB_TARGET_MEMORYREGIONINFOCACHE_H +#define LLDB_TARGET_MEMORYREGIONINFOCACHE_H + +#include "lldb/Target/MemoryRegionInfo.h" +#include "lldb/Utility/RangeMap.h" + +namespace lldb_private { +class MemoryRegionInfoCache { +public: + MemoryRegionInfoCache(Process &process) + : m_region_infos(), m_process(process) {} + + /// Remove all cached entries. + void Clear(); + + /// Remove cached information about region containing \a addr, if any. + void Flush(lldb::addr_t addr, lldb::addr_t size); + + /// Locate the memory region that contains load_addr. + Status GetMemoryRegionInfo(lldb::addr_t load_addr, ---------------- felipepiovezan wrote:
>having it in a separate class akin to how MemoryCache (a much larger amount of >code) seemed natural to me. I agree a separate class is good and we shouldn't change this bit. My point is about this: > Process has a Process::GetMemoryRegionInfo API, and subclasses have a > Process::DoGetMemoryRegionInfo, I think `Process::GetMemoryRegionInfo` should query the cache, if it's there just return. If it's not there, call the virtual `DoGetMemoryRegion`, then call `MemoryRegionInfoCache::AddRegion`. The implications of the suggested design are: 1. No more circular dependency between process and the cache 2. No more failure state in `GetMemoryRegionInfo`. It's either in the cache or it is not, no error possible. https://github.com/llvm/llvm-project/pull/202509 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
