问题
I set a lot of breakpoints in lldb for a C language based application I installed on my MacOS. The breakpoints were mostly set in the same function in the application. However, the next day that I went back to the application to continue working on it, and I started setting breakpoints again in the same function, a problem arose in that the break didn't occur inside the application function, but rather in one of the underlying libraries of the application and it keeps doing this over and over again everytime I try to break in the function (i.e. it's stopping in the underlying library) and I'm not able to reach the desired function by stepping (every time I step, it just steps forward in the underlying library).
Update:
The function I am setting the breakpoint in is called from within a signal handler. For example when I send a SIGINT signal, the signal handler calls some functions to cleanup in the application, and I am setting the breakpoint on one of those functions that cleanup. Sometimes, LLDB stops in the function that I set the breakpoint in (with stop reason = breakpoint 1.1
) , sometimes it stops in the underlying/included event handling library with stop reason = signal SIGSTOP
and, if the latter, if I press "c" (to continue onto the breakpoint in the application hopefully and out of the event handling library), only sometimes does it let me continue onto the desired breakpoint, othertimes it just says "Process 41524 resuming" and I can never get to the desired breakpoint.
回答1:
Ah, then I don't think the problem was with breakpoints, but with whether your signal handler was actually getting called.
Most debuggers have some way to control what happens when a signal is received. In lldb this is done through the process handle
command. For instance:
(lldb) process handle SIGSTOP
NAME PASS STOP NOTIFY
=========== ===== ===== ======
SIGSTOP false true true
That means lldb will stop when your process is given a SIGSTOP, and will notify you about the SIGSTOP, but will NOT pass the SIGSTOP on to the program you are debugging (and thus your handler will not get called for SIGSTOP.) process handle
with no arguments will give you the list of behaviors for all signals.
We don't pass SIGSTOP by default because it is used by the debugger for its own purposes, and so you might get calls to your handler that didn't come from "real" SIGSTOP's. The same is true, for the same reason, of SIGINT:
(lldb) process handle SIGINT
NAME PASS STOP NOTIFY
=========== ===== ===== ======
SIGINT false true true
You can easily change this behavior, for instance for SIGINT:
(lldb) process handle SIGINT -p true
NAME PASS STOP NOTIFY
=========== ===== ===== ======
SIGINT true true true
Then the debugger will pass the SIGINT on to the process, and it will stop in your handler.
回答2:
As mentioned in the troubleshooting guide, adding a target.inline-breakpoint-strategy
setting to the .lldbinit file seemed to fix the problem
"settings set target.inline-breakpoint-strategy always" >> ~/.lldbinit
Update: problem not fixed, see OP, so this is not a good solution (AFAIK)
来源:https://stackoverflow.com/questions/42522683/how-to-tell-lldb-to-pass-signal-onto-program