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

[Antony KING <antony.king@st.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 :-).

Cheers,

Antony.

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:
> http://sourceware.org/ml/gdb-patches/2007-07/msg00278.html
> This fixed the previous behaviour where "step" would always implicitly
> switch back to the last thread that stopped.
> 
> Bye,
> Ulrich