Re: "thread", "thread apply" and "step" ?

Pedro Alves
2008-08-06T12:45:32Z

On Wednesday 06 August 2008 05:41:56, Michael Snyder wrote:
> On Tue, 2008-08-05 at 16:23 -0400, Daniel Jacobowitz wrote:
> > On Tue, Aug 05, 2008 at 04:11:14PM -0400, Rich Wagner wrote:
> > > I'm using "gdb --version":
> > >
> > > GNU gdb Red Hat Linux (6.3.0.0-1.132.EL4rh)
> >
> > Could you try 6.8, or even better a CVS snapshot, and see if it still
> > does this? That release is several years old.
> >
> > I think GDB does step the correct thread nowadays.
>
> You do?

In current GDB (and I don't know how far back it goes),
in the OP case: If,

- thread B is stopped at a breakpoint
- the user switches to thread A
- the user issues a step

GDB will switch back temporarily to thread B, do a single-step
over the breakpoint (only allowing B to run (*) ), and then
revert back to thread A and continue the user step operation
on A. This is the deferred_step_ptid handling, as I'm sure
you know.

> You mean, gdb actually changes the "runnable" state of the
> threads, and successfully tells the OS which thread to schedule?
>
> Big news to me...

I took a look at target support for this, might as well
post it.

(*) - The only allowing B to run is the part that requires
both GDB and OS cooperation. You can check if your target
supports this by looking at the target_resume implementation,
checking what it is done with the ptid that is passed down.

A quick look around for support for locking by looking
at the various target_resume implementations shows that:

- linux-nat does it
- hpux/ttrace does it
- gnu-nat does it
- remote does it ok, if the stub supports and implements
vCont correctly; otherwise, not
- win32-nat does something, but not fully implemented
- BSDs, inf-ptrace and/or bsd-uthread does not
- solaris / procfs seems to depend on having PR_ASYNC. can't tell
if it works on a quick glance
- nto-procfs doesn't seem to support it

If the target doesn't support locking threads while stepping
over a breakpoint, there's a small window where another
breakpoint may be hit, or the inferior may exit.

Still, this OP's case:

", if after B hits a breakpoint, and I then use:

thread A
step

My experiments have shown that "thread A" has no effect on the
subsequent step, i.e. both threads suspend again when *B* hits its
end-of-step boundary. "

... should not happen. It should be "both threads suspend again when **A**
hits its end-of-step boundary. ". The end-of-step boundary is maintained by
GDB, not the stub/target. I don't see that failing here.

What *does* happen, and IMO it is broken, is that:

- user steps thread B, over a function call
- a breakpoint in thread A interrupts the step
- GDB leaves behind the step resume breakpoint of thread B
- user deletes any user breakpoint set because he's no longer interested
in thread B
- user steps or continues (no longer interested in inspecting the
inferior)
- the step resume breakpoint of thread B is hit, as if the original
step was still active on thread B...

The symtom is similar to what the OP described.

--
Pedro Alves