* Thread switching and stepping bug
@ 2001-04-24 2:06 Jonathan Larmour
2001-04-24 6:33 ` David Smith
0 siblings, 1 reply; 8+ messages in thread
From: Jonathan Larmour @ 2001-04-24 2:06 UTC (permalink / raw)
To: gdb
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
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Thread switching and stepping bug
2001-04-24 2:06 Thread switching and stepping bug Jonathan Larmour
@ 2001-04-24 6:33 ` David Smith
2001-04-24 8:14 ` Jonathan Larmour
2001-05-01 18:37 ` Jonathan Larmour
0 siblings, 2 replies; 8+ messages in thread
From: David Smith @ 2001-04-24 6:33 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: gdb
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)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Thread switching and stepping bug
2001-04-24 6:33 ` David Smith
@ 2001-04-24 8:14 ` Jonathan Larmour
2001-05-01 18:37 ` Jonathan Larmour
1 sibling, 0 replies; 8+ messages in thread
From: Jonathan Larmour @ 2001-04-24 8:14 UTC (permalink / raw)
To: David Smith; +Cc: gdb
David Smith wrote:
>
> Jonathan,
>
> If I understand you correctly, you may have hit a problem I'm familiar with.
> Basically your target (which you didn't mention)
I tried it on v850 and ARM and both failed in the same way so I thought it
was a generic failing.
> 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 >
Since it's checked in I'll try using the latest CVS to see what happens. My
current GDB's predate your patch.
Jifl
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Thread switching and stepping bug
2001-04-24 6:33 ` David Smith
2001-04-24 8:14 ` Jonathan Larmour
@ 2001-05-01 18:37 ` Jonathan Larmour
2001-05-02 6:30 ` David Smith
1 sibling, 1 reply; 8+ messages in thread
From: Jonathan Larmour @ 2001-05-01 18:37 UTC (permalink / raw)
To: David Smith; +Cc: gdb
David Smith wrote:
>
> 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've gone through it again with current CVS GDB, and I'm afraid there's no
change in behaviour. I was slightly wrong in my description below actually.
All that's needed is actually:
b breakme
c
[ hits breakpoint in thread 3 ]
thread 5
step
I've already tried to debug it but got lost in wait_for_inferior(). Perhaps
someone could give me an idea what should be the correct course of events
in wait_for_inferior() in the above situation after the final step, and I
can compare with what happens?
Thanks,
Jifl
> 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)
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Thread switching and stepping bug
2001-05-01 18:37 ` Jonathan Larmour
@ 2001-05-02 6:30 ` David Smith
2001-05-03 17:32 ` Andrew Cagney
0 siblings, 1 reply; 8+ messages in thread
From: David Smith @ 2001-05-02 6:30 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: gdb
Jonathan,
Note that my patch provides the generic PREPARE_TO_PROCEED functionality.
You'll have to change your tdep file to use generic_prepare_to_proceed(). If
your target is already multi-arched, it is a one line change in your
{target}_gdbarch_init() function. It would look like this:
set_gdbarch_prepare_to_proceed (gdbarch, generic_prepare_to_proceed);
Give that a shot.
Jonathan Larmour wrote:
> David Smith wrote:
>
>> 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've gone through it again with current CVS GDB, and I'm afraid there's no
> change in behaviour. I was slightly wrong in my description below actually.
> All that's needed is actually:
>
> b breakme
> c
> [ hits breakpoint in thread 3 ]
> thread 5
> step
>
> I've already tried to debug it but got lost in wait_for_inferior(). Perhaps
> someone could give me an idea what should be the correct course of events
> in wait_for_inferior() in the above situation after the final step, and I
> can compare with what happens?
>
> Thanks,
>
> Jifl
>
>
>
>> 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)
--
David Smith
dsmith@redhat.com
Red Hat, Inc.
http://www.redhat.com
256.704.9222 (direct)
256.837.3839 (fax)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Thread switching and stepping bug
2001-05-02 6:30 ` David Smith
@ 2001-05-03 17:32 ` Andrew Cagney
2001-05-04 8:28 ` David Smith
0 siblings, 1 reply; 8+ messages in thread
From: Andrew Cagney @ 2001-05-03 17:32 UTC (permalink / raw)
To: David Smith; +Cc: Jonathan Larmour, gdb
> Jonathan,
>
> Note that my patch provides the generic PREPARE_TO_PROCEED functionality. You'll have to change your tdep file to use generic_prepare_to_proceed(). If your target is already multi-arched, it is a one line change in your {target}_gdbarch_init() function. It would look like this:
>
> set_gdbarch_prepare_to_proceed (gdbarch, generic_prepare_to_proceed);
>
> Give that a shot.
Perhaphs the generic version should be enabled by default?
While this is definitly a departure from the norm - retain default
behavour even when broken - I suspect it may still be better since
enabling this fixes a bug.
Andrew
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Thread switching and stepping bug
2001-05-03 17:32 ` Andrew Cagney
@ 2001-05-04 8:28 ` David Smith
2001-05-10 8:33 ` Andrew Cagney
0 siblings, 1 reply; 8+ messages in thread
From: David Smith @ 2001-05-04 8:28 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Jonathan Larmour, gdb
Andrew,
I'm a bit nervous about making it the default. Although I believe that it
would certainly help 99% of targets, I worry about the last 1%.
Would there be some way of just turning this on for targets that support threads?
Andrew Cagney wrote:
>> Jonathan,
>>
>> Note that my patch provides the generic PREPARE_TO_PROCEED
>> functionality. You'll have to change your tdep file to use
>> generic_prepare_to_proceed(). If your target is already multi-arched,
>> it is a one line change in your {target}_gdbarch_init() function. It
>> would look like this:
>>
>> set_gdbarch_prepare_to_proceed (gdbarch, generic_prepare_to_proceed);
>>
>> Give that a shot.
>
>
> Perhaphs the generic version should be enabled by default?
>
> While this is definitly a departure from the norm - retain default
> behavour even when broken - I suspect it may still be better since
> enabling this fixes a bug.
>
> Andrew
--
David Smith
dsmith@redhat.com
Red Hat, Inc.
http://www.redhat.com
256.704.9222 (direct)
256.837.3839 (fax)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Thread switching and stepping bug
2001-05-04 8:28 ` David Smith
@ 2001-05-10 8:33 ` Andrew Cagney
0 siblings, 0 replies; 8+ messages in thread
From: Andrew Cagney @ 2001-05-10 8:33 UTC (permalink / raw)
To: David Smith; +Cc: Jonathan Larmour, gdb
> Andrew,
>
> I'm a bit nervous about making it the default. Although I believe that it would certainly help 99% of targets, I worry about the last 1%.
>
> Would there be some way of just turning this on for targets that support threads?
Hmm, that is a good point. No that isn't currently possible. Lets
leave it be.
Andrew
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2001-05-10 8:33 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-04-24 2:06 Thread switching and stepping bug Jonathan Larmour
2001-04-24 6:33 ` David Smith
2001-04-24 8:14 ` Jonathan Larmour
2001-05-01 18:37 ` Jonathan Larmour
2001-05-02 6:30 ` David Smith
2001-05-03 17:32 ` Andrew Cagney
2001-05-04 8:28 ` David Smith
2001-05-10 8:33 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).