[Lldb-commits] [lldb] Allow option to ignore module load errors in ScriptedProcess (PR #127153)

Pavel Labath via lldb-commits lldb-commits at lists.llvm.org
Wed Feb 19 01:20:58 PST 2025


labath wrote:

> It's never the case on Darwin that you know nothing about a loaded shared library. You will always know at least its name, UUID, and load addresses. It doesn't matter whether the binary exists on disk or not, we will always be able to reconstruct at least a skeleton form from the loader's information.
>
> So thinking just about Darwin, I'd opine that you should never totally omit information about a loaded library. If the loader tells you about it, you should at least make its presence available even if you can't reconstruct much information from it.
>
> The ELF behavior surprises me, I would have definitely though it was a bug that the absence of the library on disk would cause the library to totally disappear from a debug session that was clearly using it. That seems to me like information we really should try to surface the user.
>
> I really haven't played around with ELF much so I'm not up on how lossy it can be. In the case where you've deleted the library on disk is there really NOTHING that lldb can tell you about that loaded library? Jim

Reading an ELF file from memory is slightly tricky, but not impossible (I think Greg is working on making that work). I agree that showing /some/ information about the module would be better than pretending it doesn't exist, but that's not the point I was trying to make. My point was that now showing information the missing module is (MUCH) better not showing information about ANY module (even those that were found successfully).

Even in the darwin case, I can reproduce the missing module by deleting the file *and* overwriting the mach header in the memory of the process. Here I am doing it on purpose, but it could happen, however unlikely, due to a bug in the debugged binary. I'm assuming that in this case, the loader information will still contain information about the library being loaded at this address, but give up on trying to load it because the magic value doesn't match. The other modules still load fine, though.

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


More information about the lldb-commits mailing list