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

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

[Christophe LYON]

Hi all,

I am working on a port of GDB on a processor which
used variable-length bundles, that is one bundle
is composed of a set of several instructions, the
number of which is variable inside a bundle.

Breakpoints can only be set on bundles boundaries.

I am facing an issue with the 'next' command with
optimised code.

Consider a sample code which contains:
int testcall2 (void)
{
  int a, b, c, d, e, f, w, x, y, z;
  a = testcall();
  b = testcall();
  c = testcall();
  d = testcall();
  e = testcall();
  f = testcall();
  w = testcall();
  x = testcall();
  y = testcall();
  z = testcall();
  return a + b + c + d + e + f + w + x + y + z;
}

The generated code for the beginning of the
function looks like this:
testcall2:
	*bundle start*
	adjust SP
	save return address
	call testcall
	*bundle stop*

	*bundle start*
	store result into a
	call testcall
	*bundle stop*

etc...

When I set a breakpoint in testcall2 with
"break testcall2", the breakpoint is inserted
at the testcall2 label. Indeed, it is not
possible to skip the function prologue and
also set the breakpoint before calling testcall

Then, if I use the 'next' command, GDB actually
performs a 'stepi', and discovers it is now in
testcall. As a result, it decides to compute
the return address, set a breakpoint to it
and resume execution.

All of this works :-)

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?


Thanks for any input,

Christophe.

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

[Daniel Jacobowitz]

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

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

[Christophe LYON]

> > 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.
> 

Well, I am not (yet) very familiar with debugging optimized code.

What do you mean by "code analysis" ?

Currently, the recorded frame contains the unadjusted SP, but
upon return from the call SP has been modified and the current
frame is thus different from the recorded one. As you say
the frame ID should be the unadjusted SP, I don't understand
exactly how: you mean that after the call the frame ID should
also contain the unadjusted SP?

Thanks,

Christophe.

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

[Daniel Jacobowitz]

On Tue, May 24, 2005 at 10:15:23AM +0200, Christophe LYON wrote:
> 
> > > 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.
> > 
> 
> Well, I am not (yet) very familiar with debugging optimized code.
> 
> What do you mean by "code analysis" ?
> 
> Currently, the recorded frame contains the unadjusted SP, but
> upon return from the call SP has been modified and the current
> frame is thus different from the recorded one. As you say
> the frame ID should be the unadjusted SP, I don't understand
> exactly how: you mean that after the call the frame ID should
> also contain the unadjusted SP?

Yes.  You might want to look at how DWARF-2 unwind information works;
the "stack" part of the GDB frame ID should usually be equivalent to
the DWARF-2 notion of a "call frame address".

-- 
Daniel Jacobowitz
CodeSourcery, LLC