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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

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:
http://sourceware.org/ml/gdb-patches/2007-07/msg00278.html
This fixed the previous behaviour where "step" would always implicitly
switch back to the last thread that stopped.

Bye,
Ulrich

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