[Lldb-commits] [lldb] Add a test for evicting unreachable modules from the global module cache (PR #74894)

[via lldb-commits]

jimingham wrote:

> > Note, I thought about adding an `SBDebugger::GetSharedModules or something, but I don't actually think that's a good thing to give external access to. Some day we should make an SBTestAPI with some useful for testing but not for the SB API library so we can make this sort of testing easier, but for this test grubbing the command output is not all that bad.
> 
> I wouldn't mind exposing such an API for the global module list as a static functions (get count + get at index) on SBDebugger. One issue is that only real modules will show up here. This works fine for all modules for Darwin as executables, dSYM files and the .o files are all represented each by a lldb_private::Module. Not true for .dwo files though as they share the original module for the executable and only create a new ObjectFile, not a new Module for each. Not a big deal though.
> 
> This API would be useful for testing and also for people to know what modules are currently in the global module cache taking up memory in the LLDB process. To test this you might be able to run your first executable and then check the number of shared modules and access them if needed then run:
> 
> ```
> static void SBDebugger::MemoryPressureDetected();
> ```
> 
> As this used to get rid of orphaned modules in the past and I think it still does, then you could check this shared module count and list again after creating and running the second executable to see what you found.

If I knew how to hand out SBReadOnlyModule objects, I think this would be a fine API.  But I am wary of adding an API where one SBDebugger could inadvertently change another SBDebugger's environment behind its back.  We do do allow this by accident today, for instance have Debugger1 turn off "external symbol search" but then Debugger2 has it on, and loads the same module as Debugger1, forcing symbols on Debugger1.

But IMO that's a bug, and I'd rather not add more ways to write that bug.

Fortunately, the output of `image list -g` is super easy to parse, so I don't need the API for this investigation.

https://github.com/llvm/llvm-project/pull/74894