This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application

Thanks for the additional information on the execution logic of GDB and
the patch reference. This extra information will ensure I do not do the
"wrong thing" in my implementation of target_resume when I add the
checks that are currently missing :-).



Ulrich Weigand wrote:
> Anthony King wrote:
>> Also, while I was trying to absorb the mechanics of GDB in this area,
>> there seemed (to my untutored eye) an inconsistency between my target
>> definition setting "to_has_thread_control" to "tc_none" and the
>> execution model of infrun.c (esp. when it comes to stepping), or have I
>> missed something :-) ?
> Hmmm.  The meaning of to_has_thread_control doesn't seem to be completely
> well defined.  I had thought it refered to whether the target allows to
> selectively resume just one thread versus resuming all threads.
> Under this interpretation, if to_has_thread_control is tc_none, the
> target's resume method should always be called with ptid == minus_one_ptid.
> However, in actual fact infrun.c attempts to resume a single thread
> unconditionally in the following situations:
> - when single-stepping past a software single-step breakpoint
> - when single-stepping past a breakpoint
> - when stepping past a syscall-return event
> - when stepping over a steppable/nonsteppable watchpoint
> - when in non-stop mode
> Some of these can be avoided by choices the target can make (e.g.
> to support hardware single-stepping, and to not support non-stop
> mode).  For others, there doesn't seem to be a way to avoid them.
> This looks like long-standing behaviour, however ...
> In addition, even when calling the target's resume function with
> ptid == minus_one_ptid, GDB will still expect to be able to choose
> which of the resumed threads goes into single-step mode.
>> FYI I have attached the output of my test case when I use GDB 6.7.1
>> (with "set debug infrun 1"). As you can see there is no indication that
>> a context switch has occurred by the step; it seems that in GDB 6.7.1
>> changing threads did not alter the thread to be stepped (i.e. the last
>> stopped thread).
> The change in behaviour is caused by my patch:
> This fixed the previous behaviour where "step" would always implicitly
> switch back to the last thread that stopped.
> Bye,
> Ulrich

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]