What is ThreadPlan used for?

Hi, all, My ported lldb does not work as expected when I want to continue current thread.
Following is how I operate:

  1. debug session construction is alright.
  2. set a breakpoint at main().
  3. run target program and it stops at main for the breakpoint.

Then the problem occurs, no matter I execute “step” or “continue”, lldb always sends “vCont;s:xxxx”

I debugged a little and found that plan stack holds at most top a ThreadPlanStepOverBreakpoint object ever since I resumed from “main” where a breakpoint is set. And worse, this ThreadPlanStepOverBreakpoint object is never poped out even it is performed.

I am quite confused about how thread plan works, can someone make an explanation?
Thanks in advance!

Hi,
I am not a lldb hacker, but I'd like to give some cents from a general
debugger's point of view.

Then the problem occurs, no matter I execute "step" or "continue", lldb
always sends "vCont;s:xxxx"

I debugged a little and found that plan stack holds at most top a
ThreadPlanStepOverBreakpoint object ever since I resumed from "main"
where a breakpoint is set. And worse, this ThreadPlanStepOverBreakpoint
object is never poped out even it is performed.

Program stops at main because the process hits the breakpoint. The
original instruction replaced by breakpoint hasn't been executed.
When "step" or "continue" is typed, debugger has to remove breakpoint
temporarily, execute the instruction, and place breakpoint back again.
This process is called breakpoint step over. After that, debugger
can resume the process and wait for the new event.

Looks like lldb thinks step over is not finished. Probably you should
check the stop reply to "vCont;s", to see where process stopped. On
some targets, PC is the address of the breakpoint, while on other
targets, PC is the address of the instruction after breakpoint. Your
debugger and remote stub should have a consensus.

Hope it is helpful.

So you mean debugger did not see “breakpoint step over” is already completed, and thus performed it over and over again.

Thank you, Yao. I will follow this clue.

I guess so, but again, I know few on lldb, so I could be wrong.

Hi,

Hi, all, My ported lldb does not work as expected when I want to continue current thread.
Following is how I operate:

Can you give a bit more detail of your environment. What is the target that you connecting to?
Please note that if you are connecting to gdbserver, then you may need to provide the target
description using the “plugin.process.gdb-remote. target-definition-file” setting. Without it,
lldb may not work correctly.

Regards,
Abid

Thank you, Abid.

My environment is gcc-4.8.2/RHEL 6.3, and the target is a VLIW DSP which is connected to gdb server.Since my gdb server supports “qRegisterInfo” packet, the “plugin.process.gdb-remote. target-definition-file” setting won’t be necessary.

So what may cause the problem mentioned above?

Yao, it seems you are right about this problem.

lldb extends GDB RSP and uses packet “qThreadStopInfoxx” to query which threads have stopped and why.
A stop reply packet with extra info is sended to answer this packet. For Example, “T05thead:001” means thread 1 is stopped for reason 5. However my gdb server just sended “T05” at the very beginning which was not a full stop reply packet for lldb.

Thank you very much!

And furthermore, my lldb and gdb server work now.