Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application

[Antony KING <antony dot king at st dot com>]

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