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

[Antony KING <antony dot king at st dot com>]

Thanks for the definition. I had not fully grasped this aspect of the
target_resume interface. For my target interface only mode (1) can be
properly supported. Modes (2) and (4) cannot be supported at all and
mode (3) can only be supported by ensuring that inferior_ptid is set to
the last stopped thread before commencing stepping.

[Actually mode (4) can be supported but only if ptid == last stopped
thread, but this is the similar to supporting mode (3).]

Cheers,

Antony.

Ulrich Weigand wrote:
> Anthony King wrote:
> 
>> I have checked the implementation and GDB is calling my target_resume
>> with a ptid of -1 (resume all threads), which I believe is the expected
>> argument (since scheduler locking is not supported). However I think I
>> will add an error check in my target_resume just in case GDB requests a
>> single thread to be resumed.
> 
> Note that even if target_resume is called with a ptid of -1 to resume
> all threads, if the "step" flag is on, GDB will still expect that just
> one thread receives the single-step flag.  This thread is implictly
> identified by the current value of the inferior_ptid global variable.
> 
> So basically target_resume is supposed to provide these modes:
> 
> (1) ptid == -1  --  step == 0
>     resume all threads, no hardware single-step
> (2) ptid != -1  --  step == 0
>     resume only selected thread, no hardware single-step
> (3) ptid == -1  --  step == 1
>     resume all threads, hardware single-step inferior_ptid thread
> (4) ptid != -1  --  step == 1
>     resume only selected thread, hardware single-step that thread
> 
> Bye,
> Ulrich