This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Infinite backtrace on arm
- From: Jon Ringle <jon dot ringle at comdial dot com>
- To: gdb at sources dot redhat dot com
- Date: Sun, 26 Oct 2003 00:28:13 -0400
- Subject: Infinite backtrace on arm
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