"thread", "thread apply" and "step" ?

"thread", "thread apply" and "step" ?

[Rich Wagner]

I haven't been able to find an "official" GDB spec which answers a
question I have, relating to threads and stepping, so...


Say your program has two threads, A and B, and that B most recently hit
a breakpoint.

It's pretty clear (and my experiments have shown) that if you then
simply execute "step", then the step occurs in B.  That is, both threads
resume execution, with both threads suspending again when B reaches the
"end-of-step" boundary.  So far, so good...

However, things become less clear, and non-intuitive, 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.  This seems to me to be a "gdb" bug: if "thread A"
followed by "bt" shows me A's backtrace, then why is "step" different?

Furthermote, if - after B hits a breakpoint - I type:

            thread apply A step

then it's *still* B that actually does the stepping.


I'm using "gdb --version":

            GNU gdb Red Hat Linux (6.3.0.0-1.132.EL4rh)

Am I seeing a GDB bug, or am I seeing the correct GDB behavior?  If the
latter, is it possible at all to get what I want, i.e. after B hits a
breakpoint, arrange for A to step?

Thanks in advance,
Rich


P.S.  Where I work, we also use a customized version of gdb where we
provide our own RSP interpreter, because the customized version is used
for remote debugging.  Would the introduction of RSP change things as
they relate to threads and stepping?  I'm assuming the "official"
GDB-spec-based answers would necessarily apply to an RSP-based debug
session, but I mention RSP in case it affects things.

 

----------------------------

Rich Wagner, Senior Engineer
Tilera Corporation

----------------------------

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

[Daniel Jacobowitz]

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.

> P.S.  Where I work, we also use a customized version of gdb where we
> provide our own RSP interpreter, because the customized version is used
> for remote debugging.  Would the introduction of RSP change things as
> they relate to threads and stepping?  I'm assuming the "official"
> GDB-spec-based answers would necessarily apply to an RSP-based debug
> session, but I mention RSP in case it affects things.

If you implement vCont, the serial protocol should work just as well.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Michael Snyder]

On Tue, 2008-08-05 at 16:11 -0400, Rich Wagner wrote:
> I haven't been able to find an "official" GDB spec which answers a
> question I have, relating to threads and stepping, so...
> 
> 
> Say your program has two threads, A and B, and that B most recently hit
> a breakpoint.
> 
> It's pretty clear (and my experiments have shown) that if you then
> simply execute "step", then the step occurs in B.  That is, both threads
> resume execution, with both threads suspending again when B reaches the
> "end-of-step" boundary.  So far, so good...
> 
> However, things become less clear, and non-intuitive, if after B hits a
> breakpoint, and I then use:
> 
>             thread A
>             step

The short answer is "don't do that".

What I *wanted* to say is "you can't do that".
The problem is, as you have discovered, you can --
it just doesn't have the effect that you think it should.

GDB's "thread" command will specify a thread to which 
subsequent state queries will apply (eg. "info register").

But GDB does not exercise any control over the operating
system's thread scheduling, therefore GDB has no control
over which thread will actually run when you say "step"
or "continue".  You might think it should be the thread
that you last selected -- but it won't.  It will be the
thread that the operating system chooses (generally the
one that was most recently running).

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

[Michael Snyder]

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?

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

Big news to me...

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

[Vladimir Prus]

Michael Snyder wrote:

> On Tue, 2008-08-05 at 16:11 -0400, Rich Wagner wrote:
>> I haven't been able to find an "official" GDB spec which answers a
>> question I have, relating to threads and stepping, so...
>> 
>> 
>> Say your program has two threads, A and B, and that B most recently hit
>> a breakpoint.
>> 
>> It's pretty clear (and my experiments have shown) that if you then
>> simply execute "step", then the step occurs in B.  That is, both threads
>> resume execution, with both threads suspending again when B reaches the
>> "end-of-step" boundary.  So far, so good...
>> 
>> However, things become less clear, and non-intuitive, if after B hits a
>> breakpoint, and I then use:
>> 
>>             thread A
>>             step
> 
> The short answer is "don't do that".
> 
> What I *wanted* to say is "you can't do that".
> The problem is, as you have discovered, you can --
> it just doesn't have the effect that you think it should.
> 
> GDB's "thread" command will specify a thread to which
> subsequent state queries will apply (eg. "info register").
> 
> But GDB does not exercise any control over the operating
> system's thread scheduling, therefore GDB has no control
> over which thread will actually run when you say "step"
> or "continue".  You might think it should be the thread
> that you last selected -- but it won't.  It will be the
> thread that the operating system chooses (generally the
> one that was most recently running).

Well, with scheduler locking on, it should be the thread that
is selected. More specifically, the call to target_resume should
be passed the ptid of the selected thread. For native linux, this
indeed has the effect of resuming the right thread. Further, in
non-stop mode scheduler locking is implicitly on, so:

        -exec-continue --thread N

will always resume just thread N, without changing the state of any
other thread.

A target that is neither linux nor remote can, in theory, ignore the ptid
passed to target_resume. I don't know if such targets exist or not.

- Volodya

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

[Daniel Jacobowitz]

On Tue, Aug 05, 2008 at 09:41:56PM -0700, Michael Snyder wrote:
> You do?
> 
> You mean, gdb actually changes the "runnable" state of the 
> threads, and successfully tells the OS which thread to schedule?
> 
> Big news to me...

Whether it works depends on what target you're connected to, of
course, but we added remote protocol support for this... oh, five
years ago or so.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Pedro Alves]

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

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

[Rich Wagner]

Thanks Daniel:  I tried my experiments using GDB 6.8 and it does handle
the thread/step combinations sensibly.  To be specific, both:

    thread X
    step

and:

    thread apply X step

stepped thread X, even though the previous breakpoint-hit was in a
different thread than X.

-- Rich



-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@false.org] 
Sent: Tuesday, August 05, 2008 4:24 PM
To: Rich Wagner
Cc: gdb@sourceware.org
Subject: Re: "thread", "thread apply" and "step" ?

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.

> P.S.  Where I work, we also use a customized version of gdb where we 
> provide our own RSP interpreter, because the customized version is 
> used for remote debugging.  Would the introduction of RSP change 
> things as they relate to threads and stepping?  I'm assuming the
"official"
> GDB-spec-based answers would necessarily apply to an RSP-based debug 
> session, but I mention RSP in case it affects things.

If you implement vCont, the serial protocol should work just as well.

--
Daniel Jacobowitz
CodeSourcery