This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: antony dot king at st dot com (Antony KING)
- Cc: gdb at sourceware dot org
- Date: Mon, 18 Aug 2008 20:15:23 +0200 (CEST)
- Subject: Re: Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application
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