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

[Christophe LYON <christophe.lyon@st.com>]

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.