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

[Pedro Alves <pedro@codesourcery.com>]

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