This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
Re: threads/2395: "info stack" works, but "stack-info-depth" fails
- From: "Øyvind Harboe" <oyvind dot harboe at zylin dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 31 Dec 2007 17:08:01 -0000
- Subject: Re: threads/2395: "info stack" works, but "stack-info-depth" fails
- Reply-to: "Øyvind Harboe" <oyvind dot harboe at zylin dot com>
The following reply was made to PR threads/2395; it has been noted by GNATS.
From: "=?ISO-8859-1?Q?=D8yvind_Harboe?=" <oyvind.harboe@zylin.com>
To: "Daniel Jacobowitz" <drow@false.org>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: threads/2395: "info stack" works, but "stack-info-depth" fails
Date: Mon, 31 Dec 2007 18:03:00 +0100
On Dec 31, 2007 5:44 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Mon, Dec 31, 2007 at 05:39:30PM +0100, =D8yvind Harboe wrote:
> > > #1 0x000088d0 in Cyg_Thread::exit () at
> > > /ecos-c/cygwin/tmp/ecosboard/ecos/install/include/cyg/kernel/sched.hx=
x:397
> > > &"Cannot access memory at address 0xdeadbeeb\n"
> > > Cannot access memory at address 0xdeadbeeb
>
> > I don't see it. The above trace should be complete...
>
> GDB does not see any end-of-stack indication below Cyg_Thread::exit
> so it is trying to continue the backtrace. It hits an unavailable
> portion of the stack.
This would not be an unusual condition. Especially when debugging interrupt=
s and
such.
Is the current behaviour of GDB intentional?
I would have expected stack-info-depth to return the maximum examinable
depth + possibly a warning.
--=20
=D8yvind Harboe
http://www.zylin.com - eCos ARM & FPGA developer kit