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: Pedro Alves <pedro at codesourcery dot com>
- To: gdb at sourceware dot org
- Cc: Antony KING <antony dot king at st dot com>, Ulrich Weigand <uweigand at de dot ibm dot com>
- Date: Mon, 18 Aug 2008 19:47:45 +0100
- Subject: Re: Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application
- References: <200808181815.m7IIFNSo006641@d12av02.megacenter.de.ibm.com> <48A9C07E.firstname.lastname@example.org>
On Monday 18 August 2008 19:33:34, Antony KING wrote:
> 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).]
In your original example, would it work to put a special
"switch-thread breakpoint" at the PC of thread 7, so it forces
a thread switch on your target, and then continue hardware
single-stepping from there when it is hit? With care,
it seems this could be hidden entirelly on the stub/target side.
(I'm still curious on how this worked on 6.7.1 though)