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: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: antony dot king at st dot com (Antony KING)
- Cc: pedro at codesourcery dot com (Pedro Alves), gdb at sourceware dot org
- Date: Fri, 22 Aug 2008 16:41:47 +0200 (CEST)
- Subject: Re: Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application
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:
This fixed the previous behaviour where "step" would always implicitly
switch back to the last thread that stopped.
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE