I’m working on a very large C++ project with many debug symbols. Sometimes when I run a command (i.e. setting a breakpoint, running expr, etc.) these symbols need to be searched, and it seems that they persist in memory after being checked, which is a problem because it consumes all of my RAM forcing my PC to start working with swap memory which is very slow. Is it possible to cancel the evaluation of a command once started to avoid having to restart the whole session to avoid this? Ctrl+c does not seem to work.
Though lldb does have an interruption mechanism bound to ^C, there aren’t many operations lldb knows how to interrupt yet. lldb does a lot of work it doesn’t really know how to back out of, or resume later, and that’s really required for interruption to be useful. We didn’t design lldb to temporarily read in symbol & debug info from binaries and throw it away again immediately. In the debugger we generally trade space for speed and figuring out how to throw away parsed debug info would add a lot of complexity and would in most circumstances lead to bad performance overall.
For large programs you really need ways to limit the work the debugger does to perform your task. For instance, if you are setting breakpoints, you can specify the shared library target and lldb won’t look in any other shared libraries. You’ll also have more luck viewing variables of interest with the frame variable command rather than expr, since frame variable relies on local debug information.
expr is harder because lldb doesn’t in general know what kind of thing clang is asking it for, we generally get told “find anything called ‘myVar’” but that identifier could be a type or a variable, so we have to look for both. That can easily lead to whole process wide searches. lldb can improve in this area I think, being more judicious about when it does “look everywhere for X”. Maybe expr should also take some search specifications like only look for identifiers in foo.dylib to help
When you are debugging big programs, you really want a way to scope the work done appropriately, not just keep interrupting it when it starts looking further afield than your machine can support.
Thanks for the quick response, sounds like I will need to be more diligent about how I specify my breakpoints in the meantime. Or maybe use it as an excuse to upgrade my hardware…
If your project is a bunch of shared libraries then specifying -s can really speed up setting breakpoints, and avoids accidental hits in other frameworks. But if your project builds into one monolithic binary we don’t really have any good strategies for limiting lookup.
If you are setting file & line breakpoints and don’t have the habit of #including source files, you can get some speedups by changing the “target.inline-breakpoint-strategy” to “headers”. Might also help some.
Jim
On May 24, 2023, at 2:48 PM, cplusplus via LLVM Discussion Forums notifications@llvm.discoursemail.com wrote:
cplusplus
May 24Thanks for the quick response, sounds like I will need to be more diligent about how I specify my breakpoints in the meantime. Or maybe use it as an excuse to upgrade my hardware…
Visit Topic or reply to this email to respond.
To unsubscribe from these emails, click here.
