Problem stepping an embedded target with a proprietary threadimplementation

[frank dot theinen at lancom dot de]

Hi all,

I'm trying to create a remote debugging environment for a hardware router. 
The router has its own operating system and is connected via a BDI2000 
JTAG interface to a linux PC, on which I run a GDB built for the target 
processor (IXP425) using the GDB Remote protocol over IP. Simply said this 
is a standard remote debugging environment for embedded targets as seen 
from the GDB.

The (proprietary) operating system of the router switches its job contexts 
(threads) usually at the end of its hardware-interrupt handler, by 
changing the LR (link register) and returning to another thread. Since the 
BDI2000 interface is configured not to stop in this interrupt handler, the 
whole threading system is therefor unnoticed by the GDB at the moment.

When the GDB executes a step/nexti/next command which executes a 
subroutine call, it usually single steps into the subroutine, notices that 
the PC has changed, and uses the LR to set a breakpoint to "step over" the 
subroutine by continuing (as I remember from looking into the GDB 6.1 
sources some months ago). The problem arises, when the subroutine call 
gets interrupted by a hardware interrupt. The operating system then 
switches the threads, and the GDB assumes seeing a normal subroutine call. 
The GDB sets the breakpoint to the LR (which does not point into the 
function the GDB wants to return to) continues to the breakpoint and is 
lost ...

Any suggestions how I can solve the problem by configuring or modifying 
the GDB (6.3)?

Regards, Frank