From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Smith To: Jonathan Larmour Cc: gdb@sources.redhat.com Subject: Re: Thread switching and stepping bug Date: Wed, 02 May 2001 06:30:00 -0000 Message-id: <3AF00AA7.6020002@redhat.com> References: <3AE541F1.C8D1976F@redhat.com> <3AE57FA9.5090009@redhat.com> <3AEF64C7.790438AB@redhat.com> X-SW-Source: 2001-05/msg00036.html 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)