This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Thread switching and stepping bug
- To: Jonathan Larmour <jlarmour at redhat dot com>
- Subject: Re: Thread switching and stepping bug
- From: David Smith <dsmith at redhat dot com>
- Date: Wed, 02 May 2001 08:24:55 -0500
- CC: gdb at sources dot redhat dot com
- Organization: Red Hat, Inc.
- References: <3AE541F1.C8D1976F@redhat.com> <3AE57FA9.5090009@redhat.com> <3AEF64C7.790438AB@redhat.com>
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)