Question

I’m trying to do something a little fancy here, but the docs suggest it should be possible. Maybe LLDB is still too new, but I’m getting a lot of debugger crashes / deadlocks and even when that doesn’t happen it does’t seem to work like I expected.

I’m trying to put together a debug wrapper around all selector calls, to extract the message call graph inside a certain chunk of code. (I could explain why if you really want to know, but it isn’t really relevant to the debugger issue.)

I start out with an Xcode breakpoint on the line where I want to start tracking things (for bonus points, this is happening on a secondary thread, but before you ask, no, nothing on any other thread is doing any accesses to this object or anything in its property subgraph):

[myObject startProcessing];

The breakpoint triggers, and I run “bt”, just to extract:

* thread #5: tid = 0x2203, 0x000277d2 .........

I then do something mildly evil: I put a breakpoint in objc_msgSend, right at the instruction where it calls out to the real object selector. objc_msgSend looks like:

libobjc.A.dylib`objc_msgSend:
...(instructions)...
0x37babfa4:  bx     r12
...(more instructions)...

(Actually there are two bx calls but let’s keep things simple.) I run:

breakpoint set -a 0x37babfa4 -t 0x2203

(TID included because I’m having enough trouble tracking this one thread and I don’t need irrelevant stuff interfering.)

Here’s where the scripting comes in. The setup described above works exactly as I’d like it to. If I resume execution until the breakpoint triggers, I can run:

frame select 0
thread step-inst -m this-thread 5
frame info
continue

and the effect will be that the debugger:

• moves to the objc_msgSend frame
• steps by one instruction, advancing it into the object selector frame it was pointing at
• displays relevant details (object type, selector called)
• resumes execution

at which point I can keep pasting in those four commands over and over and copying the output until I hate myself.

If, on the other hand, I run:

breakpoint command add -s command

and paste in those exact same commands, everything breaks. It does not advance to the object selector frame. It doesn’t show the frame details, or at least not the correct ones — depending on various tweaks (see below), it may or may not show “objc_msgSend” as being the current function. It doesn’t resume execution.

In this case, if I could get that example working, I’d be mostly happy. But for even more bonus points, I’ve also tried this with python, which I would prefer because it would allow for much more sophisticated logging:

breakpoint command add -s python
> thread = frame.GetThread()
> thread.StepInstruction(1)
> newFrame = thread.GetFrameAtIndex(0)
> print " " * thread.GetNumFrames() + newFrame.GetFunctionName()
> process = thread.GetProcess()
> process.Continue()
> DONE

Again no good. Again depending on tiny details, this may or may not print something (usually objc_msgSend), but it never prints the correct thing. It never steps the instruction forward. It never resumes execution afterwards.

And again, the python version works fine if I do it by hand: if I wait till the breakpoint fires, then run “script” and enter those exact same lines, it works as expected. Some parts will even work in isolation, e.g. if I remove everything except the parts that get the process and call process.Continue() and trigger those automatically, that “works” (meaning I see the lldb prompt flashing rapidly as it suspends and resumes execution. Usually I regret this because it becomes unresponsive and crashes shortly after.)

So: Any ideas? Is the technology Not Ready Yet, or am I just missing some clever piece of the puzzle that will fix everything? Or should I give up entirely and just live with the fact that there are some parts of object internals that I will never understand?…

Answer 1

Breakpoint commands cannot resume execution and then get control back again, at least today. There are a lot of unresolved questions about what would happen if breakpoint 1 is running the process and then breakpoint 2 is hit. Besides the whole question of whether the code base can really handle nested breakpoints correctly (it was designed to…), what does it mean if breakpoint 2 decides execution should stop? Is breakpoint 1’s state thrown away?

It seems a little esoteric to worry about a breakpoint hitting another breakpoint while stepping the inferior process but unless all the details have been worked out, it’s easy for the user to shoot themselves in the foot. So for today, breakpoint commands can either stop when the breakpoint is hit or continue to run – but there isn’t any ability to run a little bit and do more processing. I know this would be a really useful capability for certain tasks but there are a lot of gotchas that need to be thought out before it could be done.

For some cases, it is possible to handle it the other way around … if you want to stop in function parser() only when it has been called by function lexer(), it is easy to put a breakpoint on lexer() with some a few python commands to go one stack frame up the stack and see what the calling function is. If it’s not lexer(), continue. I don’t think this will apply to what you’re trying to do, though.