Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application

[Ulrich Weigand]

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

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com