This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]