This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Handling the 'next' command on a variable-length bundles target
- From: Daniel Jacobowitz <drow at false dot org>
- To: Christophe LYON <christophe dot lyon at st dot com>
- Cc: gdb at sourceware dot org
- Date: Mon, 23 May 2005 11:45:46 -0400
- Subject: Re: Handling the 'next' command on a variable-length bundles target
- References: <4291F882.BC2F3699@st.com>
On Mon, May 23, 2005 at 05:36:34PM +0200, Christophe LYON wrote:
> The generated code for the beginning of the
> function looks like this:
> testcall2:
> *bundle start*
> adjust SP
> save return address
> call testcall
> *bundle stop*
> When the breakpoint on the return address fires,
> GDB compares the frame address in order to
> handle the case of a recursive function call.
>
> In my case, as SP has been modified during
> the 'next' command, GDB thinks it has entered
> a recursive function and decides to continue....
> until the end of the program.
>
>
> I would like to have your inputs on possible
> clean ways of handling this.
> I am considering modyfing the way 'next' and
> 'stepi' memorize the frame in this specific
> case, but this is far from being generic.
> Maybe it is too specific to think of a generic
> fix, but maybe some of you have similar
> features?
This is not a missing feature in GDB, it's a bug in your target. The
ID for a frame should be constant throughout the function. You need to
use either code analysis or DWARF-2 style unwind information to have a
constant ID for the frame; in this case, probably the unadjusted SP.
--
Daniel Jacobowitz
CodeSourcery, LLC