This is the mail archive of the
mailing list for the GDB project.
Re: Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application
- From: Antony KING <antony dot king at st dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Pedro Alves <pedro at codesourcery dot com>, gdb at sourceware dot org
- Date: Tue, 26 Aug 2008 20:11:18 +0100
- Subject: Re: Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application
- References: <200808221441.m7MEflLR027889@d12av02.megacenter.de.ibm.com>
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.