Thread switching and stepping bug

[David Smith]

Jonathan,

If I understand you correctly, you may have hit a problem I'm familiar with. 
  Basically your target (which you didn't mention) hasn't implemented 
PREPARE_TO_PROCEED which gets called in infrun.c.  I submitted a patch back 
at the end of March to implement a generic PREPARE_TO_PROCEED which should 
work for most targets.

For more details, here's the start of the thread where we discussed this:

< http://sources.redhat.com/ml/gdb-patches/2001-03/msg00541.html >

I hope this helps.

Jonathan Larmour wrote:

> It seems GDB (a fairly recent CVS) doesn't do the right thing when a thread
> view has been switched and then the system stepped.
> 
> I've got a program with a bunch of threads. The default one is thread 3 and
> has a function breakme which I set a breakpoint. The other threads run
> other stuff.
> 
> If I set a breakpoint on breakme, thread 3 hits it. If I manually step off
> that breakpoint, switch to e.g. thread 5 then do another step, GDB can't
> recognise that it hit a sensible breakpoint, and instead reports a SIGTRAP.
> 
> So the commands I'm doing are:
> 
> b breakme
> c
> [ hits breakpoint in thread 3]
> step
> thread 5
> step
> 
> I'm surprised no-one has noticed this before, so is my understanding wrong?
> 
> I've tried looking in wait_for_inferior() but got lost quickly :-). I think
> the problem may be that step_resume_breakpoint is changed when GDB notices
> the thread has changed. But I'm no expert.
> 
> Jifl



-- 
David Smith
dsmith@redhat.com
Red Hat, Inc.
http://www.redhat.com
256.704.9222 (direct)
256.837.3839 (fax)