From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25616 invoked by alias); 28 Jul 2005 23:29:46 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 25605 invoked by uid 22791); 28 Jul 2005 23:29:42 -0000 Received: from mail.lancom.de (HELO mail.lancom.de) (213.217.69.66) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 28 Jul 2005 23:29:42 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.lancom.de (Postfix) with ESMTP id A2A63498111 for ; Fri, 29 Jul 2005 01:29:40 +0200 (CEST) Received: from mail.lancom.de ([127.0.0.1]) by localhost (mail.lancom.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30594-01 for ; Fri, 29 Jul 2005 01:29:40 +0200 (CEST) Received: from lcs-mail.lancom.de (lcs-mail.lancom.de [10.1.80.23]) by mail.lancom.de (Postfix) with ESMTP id 08ADC498110 for ; Fri, 29 Jul 2005 01:29:40 +0200 (CEST) To: gdb@sources.redhat.com Subject: Problem stepping an embedded target with a proprietary thread implementation MIME-Version: 1.0 Message-ID: From: frank.theinen@lancom.de Date: Thu, 28 Jul 2005 23:29:00 -0000 Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2005-07/txt/msg00269.txt.bz2 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