Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application

Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application

[Antony KING]

Hi,

I have just upgraded our variant of GDB to version 6.8 (from 6.7.1) and
have noticed a new behaviour which I would like to "fix". Using the
following debug session snapshot:

> (gdb) tbreak mytaskfunc
> Breakpoint 1 at <location>
> (gdb) continue
> Hello from root; before task_create
> Hello from root; after task_create
> [New Thread 3]
> [Switching to Thread 3]
> mytaskfunc (p=0x0) at test.c:40
> 40              int i = (int)p;
> (gdb) info thread
> [New Thread 1]
> [New Thread 2]
> [New Thread 4]
> [New Thread 5]
> [New Thread 6]
> [New Thread 7]
>   7 Thread 7 ("My Task")  <location>
>   6 Thread 6 ("My Task")  <location>
>   5 Thread 5 ("My Task")  <location>
>   4 Thread 4 ("My Task")  <location>
>   3 Thread 2 ("Idle Task")  <location>
>   2 Thread 1 ("Root Task")  <location>
> * 1 Thread 3 ("My Task")  <location>
> (gdb) thread 7
> [Switching to thread 7 (Thread 7)]#0  <location>
> 1690    {
> (gdb) step
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> [Switching to Thread 3]
> 0x880017a4 in mytaskfunc (p=0x0) at /vob/shbri-src-testsuites/regression-tests/gdb/INSbl23029.c:40
> 40              int i = (int)p;

you can see that GDB is reporting a "SIGTRAP" message after switching
threads from "Thread 3" (the active thread) to "Thread 7" and then
performing the step. GDB is expecting that on completion of the step the
stopped thread reported by the target will be same as was selected by
GDB before the step (e.g. "Thread 7"). This will not generally happen
with our RTOS since it is not possible to change the currently running
thread (as exhibited above).

This report of "SIGTRAP" by GDB (and also the premature termination of
the step) is not desirable as this tends to agitate our users :-). Is
there a way I can modify our implementation of the target interface in
GDB that will prevent this from occurring ?

After examining the sources it looks like this situation is caused by
the call to context_switch() (in infrun.c), which is resetting the
global flag step_range_end (among others) and this is consequentially
preventing handle_inferior_event() from recognising that a step is in
progress. Is there a way avoiding this ? Alternative is it possible to
undo the effect of the "thread 7" command so that GDB has the correct
"current thread" context when resuming the target ?

Cheers,

Antony.

[Note that our version of GDB is used to support the debugging of
embedded SH-4 applications using our own RTOS with our own host/target
interface hardware.]

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

[Ulrich Weigand]

Antony KING wrote:

> you can see that GDB is reporting a "SIGTRAP" message after switching
> threads from "Thread 3" (the active thread) to "Thread 7" and then
> performing the step. GDB is expecting that on completion of the step the
> stopped thread reported by the target will be same as was selected by
> GDB before the step (e.g. "Thread 7"). This will not generally happen
> with our RTOS since it is not possible to change the currently running
> thread (as exhibited above).

Here's my understanding of this issue:  GDB does not actually care about
the "currently running" thread -- this is up the OS scheduler which GDB
cannot and does not attempt to influence.

GDB does cares about the following two properties of threads:

- Which threads are *runnable* (i.e. not stopped)

  GDB may -depending on the situation- want to tell the target to mark
  all threads runnable, no thread runnable, or just a single thread
  runnable.  (If it marks all threads runnable, it is of course up to
  the OS which threads it schedules in which order to actually *run*
  on any of the physical processors.)

- Which thread to run in hardware single-step mode

  On targets that support hardware single-step, GDB will want to decide
  *which* of the threads the single-step mode should be applied to.
  (GDB will only ever mark one thread for single-stepping.)


It seems that you're running into problems with the second point:
GDB has asked the target to hardware single-step thread 7, but your OS
actually enabled hardware single-stepping for thread 3.

If possible, you should fix this in your target implementation.  If
this is not possible for your RTOS, one simple way to solve the issue
might be to tell the GDB core that your target does not support hardware
single-stepping.  Then, GDB will fall back to software single-stepping,
where it cares for stepping the correct thread by itself.

Bye,
Ulrich

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

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

[Antony KING]

Thanks for the explanation. Unfortunately GDB has no influence over the
RTOS, it is merely an observer. This means that it cannot change the
status of threads or decide which thread is to execute; this is solely
under the control of the RTOS.

Your suggestion of disabling H/W single stepping is interesting but
unfortunately will not be suitable as we need the efficiency of the H/W
single step to ensure a responsive debug experience (especially under
Eclipse).

I think I might investigate the strategy of modifying GDB so that it
restores the currently selected thread back to the current running
thread when performing a step (or maybe generating an error).

Cheers,

Antony.

Ulrich Weigand wrote:
> Antony KING wrote:
> 
>> you can see that GDB is reporting a "SIGTRAP" message after switching
>> threads from "Thread 3" (the active thread) to "Thread 7" and then
>> performing the step. GDB is expecting that on completion of the step the
>> stopped thread reported by the target will be same as was selected by
>> GDB before the step (e.g. "Thread 7"). This will not generally happen
>> with our RTOS since it is not possible to change the currently running
>> thread (as exhibited above).
> 
> Here's my understanding of this issue:  GDB does not actually care about
> the "currently running" thread -- this is up the OS scheduler which GDB
> cannot and does not attempt to influence.
> 
> GDB does cares about the following two properties of threads:
> 
> - Which threads are *runnable* (i.e. not stopped)
> 
>   GDB may -depending on the situation- want to tell the target to mark
>   all threads runnable, no thread runnable, or just a single thread
>   runnable.  (If it marks all threads runnable, it is of course up to
>   the OS which threads it schedules in which order to actually *run*
>   on any of the physical processors.)
> 
> - Which thread to run in hardware single-step mode
> 
>   On targets that support hardware single-step, GDB will want to decide
>   *which* of the threads the single-step mode should be applied to.
>   (GDB will only ever mark one thread for single-stepping.)
> 
> 
> It seems that you're running into problems with the second point:
> GDB has asked the target to hardware single-step thread 7, but your OS
> actually enabled hardware single-stepping for thread 3.
> 
> If possible, you should fix this in your target implementation.  If
> this is not possible for your RTOS, one simple way to solve the issue
> might be to tell the GDB core that your target does not support hardware
> single-stepping.  Then, GDB will fall back to software single-stepping,
> where it cares for stepping the correct thread by itself.
> 
> Bye,
> Ulrich

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

[Daniel Jacobowitz]

On Mon, Aug 18, 2008 at 11:20:23AM +0100, Antony KING wrote:
> Thanks for the explanation. Unfortunately GDB has no influence over the
> RTOS, it is merely an observer. This means that it cannot change the
> status of threads or decide which thread is to execute; this is solely
> under the control of the RTOS.

If GDB has requested a step for a particular thread, and you're
enabling hardware single step in your stub while another thread is
current, I think this must be a bug in the stub.  It should, at the
least, report an error instead of continuing.

That said, GDB hasn't been used in this way in a while, though it used
to support it.  I think you'll need to communicate to GDB somehow that
it can not change the executing thread.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Pedro Alves]

On Monday 18 August 2008 13:42:05, Daniel Jacobowitz wrote:
> On Mon, Aug 18, 2008 at 11:20:23AM +0100, Antony KING wrote:
> > Thanks for the explanation. Unfortunately GDB has no influence over the
> > RTOS, it is merely an observer. This means that it cannot change the
> > status of threads or decide which thread is to execute; this is solely
> > under the control of the RTOS.
>

What is confusing me a bit, is that you claim that this is a new
behaviour in 6.8, coming from 6.7.1.  What was it that changed between
6.7.1 and 6.8?  That is, why did it work in 6.7.1 ?

Note that if the user switches threads when stopped at a breakpoint, and
the user issues "next", gdb will first revert back to the thread that
hit the breakpoint originally, do a single-step to get over the breakpoint,
and then when that finishes, reverts back to the new thread the user had
selected, to proceed with the "next" command.

-- 
Pedro Alves

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

[Antony KING]

[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]

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.

As you state, I think the best course of action for me is to modify GDB.
In order to preserve existing behaviour, I think the best solution is to
modify GDB so that it switches back to the original thread it stopped at
when performing a step operation (i.e. calling proceed() with step = 1).
I have attached my initial solution, which is to modify infcmd.c. This
is not entirely satisfactory as there needs to be some dynamic control
over this logic (so that it can be overridden) plus some input from the
target ops object.

Cheers,

Antony.

Daniel Jacobowitz wrote:
> On Mon, Aug 18, 2008 at 11:20:23AM +0100, Antony KING wrote:
>> Thanks for the explanation. Unfortunately GDB has no influence over the
>> RTOS, it is merely an observer. This means that it cannot change the
>> status of threads or decide which thread is to execute; this is solely
>> under the control of the RTOS.
> 
> If GDB has requested a step for a particular thread, and you're
> enabling hardware single step in your stub while another thread is
> current, I think this must be a bug in the stub.  It should, at the
> least, report an error instead of continuing.
> 
> That said, GDB hasn't been used in this way in a while, though it used
> to support it.  I think you'll need to communicate to GDB somehow that
> it can not change the executing thread.


[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 1341 bytes --]

--- gdb/infcmd.c@@/INSIGHT-6.8-ST-1.0	2008-08-12 12:00:00.000000000 +0100
+++ gdb/infcmd.c	2008-08-18 18:18:04.000000000 +0100
@@ -29,6 +29,7 @@
 #include "environ.h"
 #include "value.h"
 #include "gdbcmd.h"
+#include "gdbthread.h"
 #include "symfile.h"
 #include "gdbcore.h"
 #include "target.h"
@@ -653,6 +654,27 @@
   proceed ((CORE_ADDR) -1, TARGET_SIGNAL_DEFAULT, 0);
 }
 \f
+/* Reset to waiting PID.  */
+static void
+prepare_to_step (void)
+{
+  ptid_t wait_ptid;
+  struct target_waitstatus wait_status;
+
+  /* Get the last target status returned by target_wait().  */
+  get_last_target_status (&wait_ptid, &wait_status);
+
+  /* Switched over from WAIT_PID.  */
+  if (!ptid_equal (wait_ptid, minus_one_ptid)
+      && !ptid_equal (wait_ptid, inferior_ptid))
+    {
+      /* Switch back to WAIT_PID thread.  */
+      switch_to_thread (wait_ptid);
+      printf_filtered (_("[Switching to %s]\n"),
+		       target_pid_to_str (inferior_ptid));
+    }
+}
+
 /* Step until outside of current statement.  */
 
 static void
@@ -699,6 +721,8 @@
 
   ERROR_NO_INFERIOR;
 
+  prepare_to_step ();
+
   if (count_string)
     async_exec = strip_bg_char (&count_string);
 
@@ -1057,6 +1081,8 @@
   struct symbol *func;
   struct symtab_and_line sal;
 
+  prepare_to_step ();
+
   clear_proceed_status ();
 
   frame = get_current_frame ();

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

[Ulrich Weigand]

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

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

[Antony KING]

This change in behaviour looks like it has occurred as a result of some
structural changes in infrun.c. After a quick scan I can see numerous
(related I think) changes which are possible candidates for this
behavioural change, and all in the area of single stepping :-).

It looks like that these changes have been made in order to improve the
expected behaviour of GDB when debugging multi-threaded applications;
unfortunately while this is OK for debugging user processes on OS's such
as Linux it does not fit nicely onto my RTOS :-(.

I suspect that your explanation about the behaviour of "next" when the
target stopped due to a breakpoint may be implicated in this change :-).

I do not know what the "right" solution in general is, but for my RTOS I
think the only recourse is to ensure that the last stopped thread is
selected before performing a step operation.

Cheers,

Antony.

Pedro Alves wrote:
> On Monday 18 August 2008 13:42:05, Daniel Jacobowitz wrote:
>> On Mon, Aug 18, 2008 at 11:20:23AM +0100, Antony KING wrote:
>>> Thanks for the explanation. Unfortunately GDB has no influence over the
>>> RTOS, it is merely an observer. This means that it cannot change the
>>> status of threads or decide which thread is to execute; this is solely
>>> under the control of the RTOS.
> 
> What is confusing me a bit, is that you claim that this is a new
> behaviour in 6.8, coming from 6.7.1.  What was it that changed between
> 6.7.1 and 6.8?  That is, why did it work in 6.7.1 ?
> 
> Note that if the user switches threads when stopped at a breakpoint, and
> the user issues "next", gdb will first revert back to the thread that
> hit the breakpoint originally, do a single-step to get over the breakpoint,
> and then when that finishes, reverts back to the new thread the user had
> selected, to proceed with the "next" command.

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

[Antony KING]

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).]

Cheers,

Antony.

Ulrich Weigand wrote:
> 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

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

[Pedro Alves]

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)

-- 
Pedro Alves

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

[Antony KING]

[-- Attachment #1: Type: text/plain, Size: 2533 bytes --]

The answer to your question is yes, this could be a strategy to
implement what the user "expects".

However I am not certain doing this in the stub/target side is the
"right thing to do" since I do not think this problem is peculiar to my
environment (plus it need to replicate some of the event handling that
is already being performed by the main event handler of GDB). Looking at
the implementation in infrun.c/infcmd.c, it seems, and I say this with
caution :-), that with a certain amount of fettling the existing code to
implement software stepping could be modified to support this scenario.

I have yet to look into this as a possible solution since it looks like
it could take a while to implement as I am not very familiar with this
part of GDB. For the time being I think I will just report an error if
the user attempts to step a thread which is not the last stopped thread
(or automatically switch to the stopped thread before stepping) and put
this on my to do list.

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 :-) ?

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).

Cheers,

Antony.

Pedro Alves wrote:
> 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)


[-- Attachment #2: gdb671.log --]
[-- Type: text/plain, Size: 2541 bytes --]

(gdb) set debug infrun 1
(gdb) tbreak mytaskfunc
Breakpoint 1 at <location>
infrun: proceed (addr=0xffffffff, signal=144, step=0)
(gdb) continue
infrun: resume (step=0, signal=0)
infrun: wait_for_inferior
Hello from OS21 root; before task_create
Hello from OS21 root; after task_create
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x880017a2
infrun: context switch
infrun: Switching context from Thread 42000000 to Thread 3
infrun: BPSTAT_WHAT_STOP_NOISY
infrun: stop_stepping
[Switching to Thread 3]
mytaskfunc (p=0x0) at <location>
40		int i = (int)p;
(gdb) info thread
  7 Thread 7 ("My Task")  <location>
  6 Thread 6 ("My Task")  <location>
  5 Thread 5 ("My Task")  <location>
  4 Thread 4 ("My Task")  <location>
  3 Thread 2 ("Idle Task")  <location>
  2 Thread 1 ("Root Task")  <location>
* 1 Thread 3 ("My Task")  <location>
(gdb) thread 7
[Switching to thread 7 (Thread 7)]#0  <location>
1691	{
(gdb) info thread
* 7 Thread 7 ("My Task")  <location>
  6 Thread 6 ("My Task")  <location>
  5 Thread 5 ("My Task")  <location>
  4 Thread 4 ("My Task")  <location>
  3 Thread 2 ("Idle Task")  <location>
  2 Thread 1 ("Root Task")  <location>
  1 Thread 3 ("My Task")  <location>
infrun: proceed (addr=0xffffffff, signal=144, step=1)
(gdb) step
infrun: resume (step=1, signal=0)
infrun: wait_for_inferior
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x880017a4
infrun: keep going
infrun: resume (step=1, signal=0)
infrun: prepare_to_wait
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x880017a6
infrun: stepping inside range [0x880017a2-0x880017ae]
infrun: resume (step=1, signal=0)
infrun: prepare_to_wait
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x880017a8
infrun: stepping inside range [0x880017a2-0x880017ae]
infrun: resume (step=1, signal=0)
infrun: prepare_to_wait
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x880017aa
infrun: stepping inside range [0x880017a2-0x880017ae]
infrun: resume (step=1, signal=0)
infrun: prepare_to_wait
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x880017ac
infrun: stepping inside range [0x880017a2-0x880017ae]
infrun: resume (step=1, signal=0)
infrun: prepare_to_wait
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x880017ae
infrun: stepped to a different line
infrun: stop_stepping
mytaskfunc (p=0x0) at <location>
41		printf("Hello from task %d\n", i);

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

[Ulrich Weigand]

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

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

[Antony KING]

Thanks for the additional information on the execution logic of GDB and
the patch reference. This extra information will ensure I do not do the
"wrong thing" in my implementation of target_resume when I add the
checks that are currently missing :-).

Cheers,

Antony.

Ulrich Weigand wrote:
> 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