* Problem stepping an embedded target with a proprietary thread implementation
@ 2005-07-28 23:29 frank.theinen
0 siblings, 0 replies; only message in thread
From: frank.theinen @ 2005-07-28 23:29 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2005-07-28 23:29 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-07-28 23:29 Problem stepping an embedded target with a proprietary thread implementation frank.theinen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).