From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6060 invoked by alias); 26 Oct 2003 04:28:17 -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 6052 invoked from network); 26 Oct 2003 04:28:15 -0000 Received: from unknown (HELO sccrmhc12.comcast.net) (204.127.202.56) by sources.redhat.com with SMTP; 26 Oct 2003 04:28:15 -0000 Received: from home.ringle.org (pcp03186657pcs.proctr01.fl.comcast.net[68.56.245.147]) by comcast.net (sccrmhc12) with ESMTP id <2003102604281501200ahcude>; Sun, 26 Oct 2003 04:28:15 +0000 Received: by home.ringle.org (Postfix, from userid 501) id E39F0B82B5; Sun, 26 Oct 2003 00:28:13 -0400 (EDT) From: Jon Ringle To: gdb@sources.redhat.com Subject: Infinite backtrace on arm Date: Sun, 26 Oct 2003 04:28:00 -0000 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310260028.13745.jon.ringle@comdial.com> X-SW-Source: 2003-10/txt/msg00283.txt.bz2 Hi, I backported arm kgdb to run in an embedded arm target running 2.2.16 kernel. I can debug the the target for the most part with gdb-5.3 over a serial connection. However, sometimes when I ask for a backtrace, the bt gets stuck recursing at the bottom of the bt. Here is an example: Breakpoint 9, dimp_proc_bring_dsp_down (p_dsp=0x1022dc00, reason=7) at common/micro/dim/dimutl.c:247 (gdb) bt #0 dimp_proc_bring_dsp_down (p_dsp=0x1022dc00, reason=7) at common/micro/dim/dimutl.c:247 #1 0x1005dff4 in dimp_bring_dsp_down (p_dsp=0x1022dc00, reason=DIM_DSP_ERR_OK) at common/micro/dim/dimutl.c:74 #2 0x1005ae20 in dimp_check_dsp_msgs () at common/micro/dim/dimdsp.c:1831 #3 0x100557a8 in dim_process_poll () at common/micro/dim/dimcomm.c:107 #4 0x10067d78 in dsp_timer1intHandler (irq=0, dev_id=0x0, regs=0x1018a820) at dspdriver.c:169 #5 0x1000c004 in do_IRQ (irq=1, regs=0x10ffdfa8) at irq.c:247 #6 0x1000b200 in linux_VECTOR_IRQ () #7 0x1000b200 in linux_VECTOR_IRQ () #8 0x1000b200 in linux_VECTOR_IRQ () [repeated ad infinitum...] I found the following code check at blockframe.c:496 that is supposed to trap this situation: /* If ->frame and ->pc are unchanged, we are in the process of getting ourselves into an infinite backtrace. Some architectures check this in FRAME_CHAIN or thereabouts, but it seems like there is no reason this can't be an architecture-independent check. */ if (next_frame != NULL) { if (prev->frame == next_frame->frame && prev->pc == next_frame->pc) { next_frame->prev = NULL; obstack_free (&frame_cache_obstack, prev); return NULL; } } However, I found by debugging gdb that frame was changing by framesize. I think (but not confirmed) that this is happening because this is not caught by arm_frame_chain() and it is returning with: return fi->frame + fi->extra_info->framesize; I fixed my problem with the following: --- gdb/blockframe.c~ 2003-10-26 00:17:13.000000000 -0400 +++ gdb/blockframe.c 2003-10-26 00:17:53.000000000 -0400 @@ -499,8 +499,7 @@ this can't be an architecture-independent check. */ if (next_frame != NULL) { - if (prev->frame == next_frame->frame - && prev->pc == next_frame->pc) + if (prev->pc == next_frame->pc) { next_frame->prev = NULL; obstack_free (&frame_cache_obstack, prev); I don't think this is the right thing to do, and that a fix is really needed in arm_frame_chain(). But I'm not sure what that might be. Does anyone have a suggestion? Thanks, Jon