Re: Handling the 'next' command on a variable-length bundles target

[Daniel Jacobowitz <drow@false.org>]

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