Frame handling

Frame handling

[Jafa]

Hi all,

I am working on the ip2k port of GDB. It has been stable for some time now
but I ran out of time to get it reviewed before I went on holiday and now I
am trying to bring it up to date with the trunk again.

I merged with the trunk on March 17 - big mistake... frame handling was
cauing big problems.... looked like a partical update to a new approach.

I have just checked out the trunk today and it looks like a number of the
ports are using the new frame handling approach.

Is the trunk considered ok ATM or is the frame handling still in unstable
daily development?

What port would you recommend for reference for frame handling? The MIPS
port is using deprecated frame functions.

BTW - The stack-backtraces have a second problem as well... GDB is ment to
stop at 'main' but the symbol lookup fails. In the applications that I am
testing the symbol 'main' is a weak alias and this seams to be a general
problem in the symbol lookup.

I would appreciate your advice.

Thanks

Nick

Re: Frame handling

[Andrew Cagney]

> I have just checked out the trunk today and it looks like a number of the
> ports are using the new frame handling approach.

The d10v is, it has zero deprecated methods.  Since, at present, updates 
are being pushed into this architecture first, you'll need to keep a 
close eye on it.

Other architectures are creaping closer.

> BTW - The stack-backtraces have a second problem as well... GDB is ment to
> stop at 'main' but the symbol lookup fails. In the applications that I am
> testing the symbol 'main' is a weak alias and this seams to be a general
> problem in the symbol lookup.

Can you post the details (new thread)?

Andrew

Frame handling

[Jafa]

Hi all,

I am bringing the ip2k port back in sync with the trunk and I need to check
my (limited) understanding of the new scheme...

This email is mostly a ramble about my understanding of the new frame
handling that I would like a sanity check on.

frame_base_set_default (gdbarch, &avr_frame_base) registers a set of
function handlers:
this_base - given a frame, figure out the base address of the caller frame
(caller's FP)... usually this means doing some analysis to figure everything
out about the frame and populating the port-specific cache for this new
frame.
this_locals - given a frame, figure out the address of the local variables
of the callers frame (usually caller's FP as debug info already allows for
the offset).
this_args - given a frame, figure out the address of the args passed to the
callers frame (usually caller's FP as debug info already allows for the
offset).

Port specific implementation... The first time one of these functions is
called the port-specific cache will be a NULL pointer... the code should
allocate memory to hold the useful frame variables and figure out the frame
information. Subsequent calls will receive the cache back and can return the
values from the cache.

frame_base_set_default also sets the unwind options...
type - always NORMAL_FRAME?
this_id - Given a frame, return a unique identifier for the caller's frame
based on the caller's frame base address and the calling functions entry
point.
prev_register - Given a frame, return the value of a specified register as
it was on entry to this function (registers that are known to be saved on
the stack)

Question - what registers is gdb expecting prev_register to give reasonable
results for? Just PC? Or SP and FP as well?

Question - reading through this again I think the goal of call these
functions is to work with the current frame and the function get passed the
child frame so they can do a backtrace if it hasn't already been done... why
not call a function to do a 1 level backtrace and then eliminate the
next_frame parameter? It would recduce confusion and most ports will have an
internal unwind function anyway.

frame_unwind_append_predicate (gdbarch, d10v_frame_p) - this seams to
register the same unwind options as above?

I think this makes sense but I would appreciate a sanity check :-)

Thanks

Nick

Nick Kelsey
Senior Software Engineer
Ubicom

Re: Frame handling

[Daniel Jacobowitz]

On Mon, Jun 30, 2003 at 06:18:33PM -0700, Jafa wrote:
> Hi all,
> 
> I am bringing the ip2k port back in sync with the trunk and I need to check
> my (limited) understanding of the new scheme...
> 
> This email is mostly a ramble about my understanding of the new frame
> handling that I would like a sanity check on.
> 
> frame_base_set_default (gdbarch, &avr_frame_base) registers a set of
> function handlers:
> this_base - given a frame, figure out the base address of the caller frame
> (caller's FP)... usually this means doing some analysis to figure everything
> out about the frame and populating the port-specific cache for this new
> frame.
> this_locals - given a frame, figure out the address of the local variables
> of the callers frame (usually caller's FP as debug info already allows for
> the offset).
> this_args - given a frame, figure out the address of the args passed to the
> callers frame (usually caller's FP as debug info already allows for the
> offset).
> 
> Port specific implementation... The first time one of these functions is
> called the port-specific cache will be a NULL pointer... the code should
> allocate memory to hold the useful frame variables and figure out the frame
> information. Subsequent calls will receive the cache back and can return the
> values from the cache.

You're good so far.

> frame_base_set_default also sets the unwind options...

No, it doesn't.  That unwind member is used for comparison purposes
only.  See the "Sneaky" comment in get_frame_base_address, and all of
"frame-unwind.h".  Esp. frame_unwind_append_predicate.

> type - always NORMAL_FRAME?

For a target's unwinders, probably.

> this_id - Given a frame, return a unique identifier for the caller's frame
> based on the caller's frame base address and the calling functions entry
> point.
> prev_register - Given a frame, return the value of a specified register as
> it was on entry to this function (registers that are known to be saved on
> the stack)
> 
> Question - what registers is gdb expecting prev_register to give reasonable
> results for? Just PC? Or SP and FP as well?

As many as possible.  This _completely_ replaces all other unwinding,
for instance frame_chain and the extra_info/saved_registers data. 
Might want to take a look at the ARM conversion I just posted; I don't
promise it's right...

> Question - reading through this again I think the goal of call these
> functions is to work with the current frame and the function get passed the
> child frame so they can do a backtrace if it hasn't already been done... why
> not call a function to do a 1 level backtrace and then eliminate the
> next_frame parameter? It would recduce confusion and most ports will have an
> internal unwind function anyway.

Because it doesn't make much difference, I think.  The key is that the
info generated when doing the backtrace is target specific, and opaque.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Frame handling

[Andrew Cagney]

>> this_id - Given a frame, return a unique identifier for the caller's frame
>> based on the caller's frame base address and the calling functions entry
>> point.
>> prev_register - Given a frame, return the value of a specified register as
>> it was on entry to this function (registers that are known to be saved on
>> the stack)
>> 
>> Question - what registers is gdb expecting prev_register to give reasonable
>> results for? Just PC? Or SP and FP as well?
> 
> 
> As many as possible.  This _completely_ replaces all other unwinding,
> for instance frame_chain and the extra_info/saved_registers data. 
> Might want to take a look at the ARM conversion I just posted; I don't
> promise it's right...

Yes.  GDB now relies on the prev_register method when popping a frame so 
unless it works well, things fail pretty quick.

>> Question - reading through this again I think the goal of call these
>> functions is to work with the current frame and the function get passed the
>> child frame so they can do a backtrace if it hasn't already been done... why
>> not call a function to do a 1 level backtrace and then eliminate the
>> next_frame parameter? It would recduce confusion and most ports will have an
>> internal unwind function anyway.


> Because it doesn't make much difference, I think.  The key is that the
> info generated when doing the backtrace is target specific, and opaque.

I'm not sure I understand the question.

Andrew

Re: Frame handling

[Jafa]

Hi Andrew,

>>> Question - what registers is gdb expecting prev_register to give
reasonable
>>> results for? Just PC? Or SP and FP as well?
>>
>> As many as possible.  This _completely_ replaces all other unwinding,
>> for instance frame_chain and the extra_info/saved_registers data.
>> Might want to take a look at the ARM conversion I just posted; I don't
>> promise it's right...
>
>Yes.  GDB now relies on the prev_register method when popping a frame so
>unless it works well, things fail pretty quick.

Ok

The ABI states that everything is callee clobbered so the only things I can
recover will be the PC, SP, and FP. There is no FP register so FP and SP are
search-calculated.

I will clean up the ip3k (aka ip4k) frame_handling next so should be able to
recover the saved address registers (all data registers are callee
clobbered).

BTW - Sorry I missed the branch, management didn't pay any attention to my
recomendation 3 weeks ago... and *now* they decide we need to fix gdb and
merge up to the trunk :-)

Thanks

Nick

Re: Frame handling

[Andrew Cagney]

>>>> Question - reading through this again I think the goal of call these
>>>> functions is to work with the current frame and the function get passed the
>>>> child frame so they can do a backtrace if it hasn't already been done... why
>>>> not call a function to do a 1 level backtrace and then eliminate the
>>>> next_frame parameter? It would recduce confusion and most ports will have an
>>>> internal unwind function anyway.
> 
> 
>> 
>>> Question - reading through this again I think the goal of call these
>>> functions is to work with the current frame and the function get passed the
>>> child frame so they can do a backtrace if it hasn't already been done... why
>>> not call a function to do a 1 level backtrace and then eliminate the
>>> next_frame parameter? It would recduce confusion and most ports will have an
>>> internal unwind function anyway.
> 
>> 
>> I'm not sure I understand the question.

> I agree, and I don't think it will make much difference eitehr way, however
> I was just thinking that it would be a whole lot easier to explain these
> functions...
> 

Um, this is still dangling.  Can you please express your question using 
terminology consistent with the frame unwind code.

Andrew

Re: Frame handling

[Daniel Jacobowitz]

On Tue, Jul 01, 2003 at 08:58:46AM -0400, Andrew Cagney wrote:
> >>>>Question - reading through this again I think the goal of call these
> >>>>functions is to work with the current frame and the function get passed 
> >>>>the
> >>>>child frame so they can do a backtrace if it hasn't already been 
> >>>>done... why
> >>>>not call a function to do a 1 level backtrace and then eliminate the
> >>>>next_frame parameter? It would recduce confusion and most ports will 
> >>>>have an
> >>>>internal unwind function anyway.
> >
> >
> >>
> >>>Question - reading through this again I think the goal of call these
> >>>functions is to work with the current frame and the function get passed 
> >>>the
> >>>child frame so they can do a backtrace if it hasn't already been done... 
> >>>why
> >>>not call a function to do a 1 level backtrace and then eliminate the
> >>>next_frame parameter? It would recduce confusion and most ports will 
> >>>have an
> >>>internal unwind function anyway.
> >
> >>
> >>I'm not sure I understand the question.
> 
> >I agree, and I don't think it will make much difference eitehr way, however
> >I was just thinking that it would be a whole lot easier to explain these
> >functions...
> >
> 
> Um, this is still dangling.  Can you please express your question using 
> terminology consistent with the frame unwind code.

I think Nick's question is: why does every architecture implement the
cache lazily, instead of GDB instructing the architecture when to
create the cache.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Frame handling

[Andrew Cagney]

> Um, this is still dangling.  Can you please express your question using 
>> terminology consistent with the frame unwind code.
> 
> 
> I think Nick's question is: why does every architecture implement the
> cache lazily, instead of GDB instructing the architecture when to
> create the cache.

(I'm honestly not so sure, I think there is more).

For this question, it's a case of learning from past mistakes.  See 
legacy_get_prev_frame.

The old code tried to do do this - INIT_FRAME_SAVED_REGS but failed. 
General confusion over what was ment to happen when quickly exploded 
into INIT_FRAME_EXTRA_INFO, INIT_FRAME_SAVED_REGS, INIT_FRAME_PC, 
INIT_FRAME_PC_FIRST, FRAME_CHAIN, FRAME_SAVED_PC all trying to 
initialize the cache[s] (there ended up being three!) but many, such as 
FRAME_CHAIN and FRAME_SAVED_PC, found that they couldn't because they 
didn't even have access to the cache).

The new code takes the oposite approach.  Only specify interfaces that 
are absolutly needed and make the unwinder 100% responsible for all 
cache management, populating it based on the immediate demand.

One of Apple's hacks is to do a light weight FRAME_CHAIN (it avoid doing 
prologue analysis).  It may be possible to implement this in the new 
unwinders - id_unwind would only create/populate what was immediatly 
necessary and avoid a full prologue analysis (something that is 
considered expensive).

Andrew

Re: Frame handling

[Jafa]

Hi Andrew,

>The old code tried to do do this - INIT_FRAME_SAVED_REGS but failed.
>General confusion over what was ment to happen when quickly exploded
>into INIT_FRAME_EXTRA_INFO, INIT_FRAME_SAVED_REGS, INIT_FRAME_PC,
>INIT_FRAME_PC_FIRST, FRAME_CHAIN, FRAME_SAVED_PC all trying to
>initialize the cache[s] (there ended up being three!) but many, such as
>FRAME_CHAIN and FRAME_SAVED_PC, found that they couldn't because they
>didn't even have access to the cache).

Yeah, that was a bit of a mess :-)

>The new code takes the oposite approach.  Only specify interfaces that
>are absolutly needed and make the unwinder 100% responsible for all
>cache management, populating it based on the immediate demand.
>
>One of Apple's hacks is to do a light weight FRAME_CHAIN (it avoid doing
>prologue analysis).  It may be possible to implement this in the new
>unwinders - id_unwind would only create/populate what was immediatly
>necessary and avoid a full prologue analysis (something that is
>considered expensive).

Makes sense.... the trick is to leave this power to the port-specific code.

The proposal in my last email still allows the port-writer to implement a
light-weight frame_chain but I have to admit that it doesn't point them in
that direction.

Thanks for your time BTW - My view of the world is pretty small.

Nick

Re: Frame handling

[Jafa]

Hi Andrew

>>> I'm not sure I understand the question.

>> I agree, and I don't think it will make much difference eitehr way,
however
>> I was just thinking that it would be a whole lot easier to explain these
>> functions...
>>

>Um, this is still dangling.  Can you please express your question using
>terminology consistent with the frame unwind code.

Sorry, it was a bit of a ramble :-)

Avr and d10v ports both have function avr/d10v_frame_unwind_cache which
figure out everything about a frame but are internal functions.

The frame-base and frame-unwind APIs provides a machanism to register
functions -

struct frame_base
{
  ...
  frame_this_base_ftype *this_base;
  frame_this_locals_ftype *this_locals;
  frame_this_args_ftype *this_args;
};

struct frame_unwind
{
  ...
  frame_this_id_ftype *this_id;
  frame_prev_register_ftype *prev_register;
};

All five of these functions work on the principle of "given this frame,
figure out xxx information of the caller's frame" and are passed a pointer
to the next_frame (child frame). For example, "given this frame, figure out
where the arguments start of the caller's frame."

I would like to suggest the following:
- <port>_frame_unwind_cache functions to be registered as part of the
frame-unwind API.
- GDB to call <port>_frame_unwind_cache once each time it wants to go back
one frame.
- next_frame parameter removed from all five functions above.
- remove call to <port>_frame_unwind_cache function from the port-specific
implementations of the five functions above.

At a minimum the <port>_frame_unwind_cache function could store the
next_frame parameter and the five functions above could get next_frame from
this_base_cache parameter.

In practice many (most?) ports will do a <port>_frame_unwind_cache function
that figures out everything about the frame in one step and the five
fucntions above will simply read out of the this_base_cache.

Advantages:
- Eliminates some common code from all ports. (call to
<port>_frame_unwind_cache inside each function).
- Eliminates next_frame parameter to these functions.
- Easier to explain/understand the API because you only have to think about
one frame level.
- If a particular port wants the next_frame parameter to search within each
of the five functions then they can save the next_frame parameter themselves
(1 line of code) and it is exactly the same.

I would be happy to provide a patch to look at if that would help explain
and fuel the discussion.

Thanks

Nick

Re: Frame handling

[Andrew Cagney]

> Hi Andrew
> 
> 
>>>> I'm not sure I understand the question.
> 
> 
>>> I agree, and I don't think it will make much difference eitehr way,
> 
> however
> 
>>> I was just thinking that it would be a whole lot easier to explain these
>>> functions...
>>>
> 
> 
>>Um, this is still dangling.  Can you please express your question using
>>terminology consistent with the frame unwind code.
> 
> 
> Sorry, it was a bit of a ramble :-)
> 
> Avr and d10v ports both have function avr/d10v_frame_unwind_cache which
> figure out everything about a frame but are internal functions.
> 
> The frame-base and frame-unwind APIs provides a machanism to register
> functions -
> 
> struct frame_base
> {
>   ...
>   frame_this_base_ftype *this_base;
>   frame_this_locals_ftype *this_locals;
>   frame_this_args_ftype *this_args;
> };
> 
> struct frame_unwind
> {
>   ...
>   frame_this_id_ftype *this_id;
>   frame_prev_register_ftype *prev_register;
> };
> 
> All five of these functions work on the principle of "given this frame,
> figure out xxx information of the caller's frame" and are passed a pointer
> to the next_frame (child frame). For example, "given this frame, figure out
> where the arguments start of the caller's frame."

(To clarify something, they work on the basis of ``given the next 
frame''.  They must assume that ``this frame'' does not exist - an 
attept to call get_prev_frame (next_frame) would be wrong)
(See my e-mail to daniel)

Anyway, the old code did similar to what you suggest.

Because the cache initialize was disconnected from the specific request, 
people were never sure how much to initialize and when.  As a 
consequence, it was done randomly, using random techniques.  GDB (core, 
target and architecture) is littered with calls like:

	if (!frame->extra_info)
	  INIT_FRAME_EXTRA_INFO

and

	if (!frame->saved_regs)
	  INIT_FRAME_SAVED_REGS

So while the line:
	cache = get_frame_cache (next_frame, this_cache);
might seem a pain, its far less of a pain than the old code that had 
very complicated cache initialization rules.

At least it is clear where the buck stops - the entire problem falls 
squarely on the sholders of the unwinder.

> I would like to suggest the following:
> - <port>_frame_unwind_cache functions to be registered as part of the
> frame-unwind API.

BTW, two, and not one initialize methods would need to be added: one for 
frame-unwind, and one for frame-base.  A problem from the old code was 
the plithera of unwind methods, hmm.

> - GDB to call <port>_frame_unwind_cache once each time it wants to go back
> one frame.

> - next_frame parameter removed from all five functions above.

Zero benefit.

Every init frame cache method will have (not could) to store next_frame 
in the cache.  Without it, the frame code couldn't access memory or 
registers.

Burrying the frame (hiding it in a cache) would make debugging gdb a 
royal pain.  At present the applicable frame is made explicit as it is a 
parameter.

Andrew

Re: Frame handling

[Jafa]

Hi Daniel,

Thanks for the sanity check - I like the way this APi is heading btw.

>> Question - reading through this again I think the goal of call these
>> functions is to work with the current frame and the function get passed
the
>> child frame so they can do a backtrace if it hasn't already been done...
why
>> not call a function to do a 1 level backtrace and then eliminate the
>> next_frame parameter? It would recduce confusion and most ports will have
an
>> internal unwind function anyway.

>Because it doesn't make much difference, I think.  The key is that the
>info generated when doing the backtrace is target specific, and opaque.

I agree, and I don't think it will make much difference eitehr way, however
I was just thinking that it would be a whole lot easier to explain these
functions...

unwind - Given this frame, go analyize its caller and populate a
port-specific info block/cache, return unique id.

this_base - Given your port-specific frame block/cache data back, what is
the frame's base address?

this_locals - Given your port-specific frame block/cache data back, where do
the frame's locals start?

this_args - Given your port-specific frame block/cache data back, where do
the frame's args start?

this_id - Superceeded by unwind fucntion?

It took a day to 'click' about the logic bhind the cache because I was
looking at it the wrong way... If an API is easier to explain then it is
easier for people to get it right.

Out of interest, what is the theory behind the frame id being made up of
address + func?

I should have the ip2k port frame handling working tomorrow so I will post
the tdep if you would like to take a look. It would probably be good to
check it into the FSF trunk.

Thanks

Nick

----- Original Message ----- 
From: "Daniel Jacobowitz" <drow@mvista.com>
To: <jafa@silicondust.com>
Sent: Monday, June 30, 2003 8:43 PM
Subject: Re: Frame handling


*This message was transferred with a trial version of CommuniGate(tm) Pro*
On Mon, Jun 30, 2003 at 06:18:33PM -0700, Jafa wrote:
> Hi all,
>
> I am bringing the ip2k port back in sync with the trunk and I need to
check
> my (limited) understanding of the new scheme...
>
> This email is mostly a ramble about my understanding of the new frame
> handling that I would like a sanity check on.
>
> frame_base_set_default (gdbarch, &avr_frame_base) registers a set of
> function handlers:
> this_base - given a frame, figure out the base address of the caller frame
> (caller's FP)... usually this means doing some analysis to figure
everything
> out about the frame and populating the port-specific cache for this new
> frame.
> this_locals - given a frame, figure out the address of the local variables
> of the callers frame (usually caller's FP as debug info already allows for
> the offset).
> this_args - given a frame, figure out the address of the args passed to
the
> callers frame (usually caller's FP as debug info already allows for the
> offset).
>
> Port specific implementation... The first time one of these functions is
> called the port-specific cache will be a NULL pointer... the code should
> allocate memory to hold the useful frame variables and figure out the
frame
> information. Subsequent calls will receive the cache back and can return
the
> values from the cache.

You're good so far.

> frame_base_set_default also sets the unwind options...

No, it doesn't.  That unwind member is used for comparison purposes
only.  See the "Sneaky" comment in get_frame_base_address, and all of
"frame-unwind.h".  Esp. frame_unwind_append_predicate.

> type - always NORMAL_FRAME?

For a target's unwinders, probably.

> this_id - Given a frame, return a unique identifier for the caller's frame
> based on the caller's frame base address and the calling functions entry
> point.
> prev_register - Given a frame, return the value of a specified register as
> it was on entry to this function (registers that are known to be saved on
> the stack)
>
> Question - what registers is gdb expecting prev_register to give
reasonable
> results for? Just PC? Or SP and FP as well?

As many as possible.  This _completely_ replaces all other unwinding,
for instance frame_chain and the extra_info/saved_registers data.
Might want to take a look at the ARM conversion I just posted; I don't
promise it's right...

> Question - reading through this again I think the goal of call these
> functions is to work with the current frame and the function get passed
the
> child frame so they can do a backtrace if it hasn't already been done...
why
> not call a function to do a 1 level backtrace and then eliminate the
> next_frame parameter? It would recduce confusion and most ports will have
an
> internal unwind function anyway.

Because it doesn't make much difference, I think.  The key is that the
info generated when doing the backtrace is target specific, and opaque.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Frame handling

[Daniel Jacobowitz]

On Mon, Jun 30, 2003 at 10:00:21PM -0700, Jafa wrote:

> Out of interest, what is the theory behind the frame id being made up of
> address + func?

The theory is that the frame ID is persistent.  It lives until the
frame goes out of scope (locals with watchpoints on them disappear,
frame-specific breakpoints, etc.).  Stack addr isn't enough, because of
frameless functions; but PC is too volatile.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Frame handling

[Andrew Cagney]

> Out of interest, what is the theory behind the frame id being made up of
> address + func?

 From the definition of frame ID:

/* The frame object's ID.  This provides a per-frame unique identifier
    that can be used to relocate a `struct frame_info' after a target
    resume or a frame cache destruct.  It of course assumes that the
    inferior hasn't unwound the stack past that frame.  */

struct frame_id
{
   /* The frame's stack address.  This shall be constant through out
      the lifetime of a frame.  Note that this requirement applies to
      not just the function body, but also the prologue and (in theory
      at least) the epilogue.  Since that value needs to fall either on
      the boundary, or within the frame's address range, the frame's
      outer-most address (the inner-most address of the previous frame)
      is used.  Watch out for all the legacy targets that still use the
      function pointer register or stack pointer register.  They are
      wrong.  */
   /* NOTE: cagney/2002-11-16: The ia64 has two stacks and hence two
      frame bases.  This will need to be expanded to accomodate that.  */
   CORE_ADDR stack_addr;
   /* The frame's code address.  This shall be constant through out the
      lifetime of the frame.  While the PC (a.k.a. resume address)
      changes as the function is executed, this code address cannot.
      Typically, it is set to the address of the entry point of the
      frame's function (as returned by frame_func_unwind().  */
   CORE_ADDR code_addr;
};

/* Methods for constructing and comparing Frame IDs.

    NOTE: Given frameless functions A and B, where A calls B (and hence
    B is inner-to A).  The relationships: !eq(A,B); !eq(B,A);
    !inner(A,B); !inner(B,A); all hold.  This is because, while B is
    inner to A, B is not strictly inner to A (being frameless, they
    have the same .base value).  */

Re: Frame handling

[Paul N. Hilfinger]

[Apologies if I've missed a message on this].
Something (recent frame stuff?) seems to have broken backtraces on 
Sparc Solaris 5.8.  Use the head version of GDB (although the GDB6 branch 
shows it also) on the attached silly program (I compiled 
with -g and gcc 3.0.3).   If you stop in, say, inside the first recursive
invocation of g, you will find that 'where' only prints three frames, 
getting the frame pointer screwed up in the last one, as far as I can tell.

Paul Hilfinger

------------------------------------------------------------
#include <stdio.h>

extern int g (int);

int h (int r)
{
  int i;
  int s;

  for (i = r-1, s = 0; i >= 0; i -= 1)
    s += g (i);
  return s;
}

int g (int q)
{
  return h (q);
}

int f (int x, int y)
{
  int z, s;
  for (z = x, s = 0; z < y; z += 1)
    s += z * g(x);
  return s;
}


main ()
{
  printf ("%d\n", f (3, 7));
}