Re: RFA bug fix -- x86-64 stabs and deprecated fp register

[Joel Brobecker <brobecker at adacore dot com>]

> For a frameless function, I would expect that $fp would be either
> <unavailable> or would be the frame pointer for the most recent function
> that had a frame or would just be %rbp.
> 
> Since a frameless function has no frame, I would consider any of the
> three to be reasonable.  I would also argue that it is an error to ask
> for the frame pointer of a frameless function, but that an error should
> not be thrown as the user shouldn't be expected to know that the
> function is frameless.

I don't know if it's me who used the wrong technical term, or if
the terminology is misleading, but for me, a frameless function
was meant to mean a function which does not use the frame pointer.
But, to me, functions always have a frame, even if maybe in some
case perhaps it is possible for their frame to have zero data in it.
But in any case, there is always a frame address, and that's what
$fp means to me.

> When I first posted this bug report and fix months ago, it drew zero
> responses.  (I noticed recently that it wasn't in so I sent another
> message.)  At that time I could have told you more.

Sorry about that, but I personally have been the busiest I have ever
been at work for the last few months. And I have a feeling that others
have been too. The only tip I can offer to prevent this from happening
is to ping us. Typical protocol we recommend is 2 weeks after submission
and every week thereafter. It's sad that it has to be this way, but
we have to remember that we are all volunteers trying to do their best.
At the moment, I am taking time away from work just to research further
and answer you.

> There are functions where the debug information (STABS) specifies an
> offset from the frame pointer, but does not specify which register is
> the frame pointer.  GDB currently decides to not use any register.  It
> treats the offset as an offset from zero -- put another way, it treats
> it as an absolute address.
[...]
> I remember the symptom but not the details.  For selected functions if
> you typed:
> 
>     print <name_local_variable>
> 
> you would get an error because GDB thought that the variable had an
> address of -32 or -28 or -24 or similar (depending upon which local
> variable you selected).
> 
> The ELF file was using STABS and when I debugged it, GDB said that the
> variable's address was a small offset from the frame pointer.  It didn't
> know what to use for the frame pointer and ended up using zero.
> 
> The fix merely decides what to do if you need a frame pointer and
> haven't been able to otherwise figure out what to use for the frame
> pointer -- use the traditional default frame pointer register %rbp.
> 
> If you already have a frame pointer or do not need a frame pointer,
> nothing is changed.

It's actually not a question of having a register or no register.
We were able to make this work without your patch before, and I just
tested again today and it worked for me.

I invite you to first take a look at findvar.c:default_read_var_value,
which eventually calls frame.c:get_frame_locals_address. This function
then "sniff"es the code to determine which base unwinder to use. And
normally in your case, it should probably find amd64-tdep.c:amd64_frame_base.
That's the vector which is going to use to compute the "frame_id"
object corresponding to your function's frame. And of particular
interest in your case is the "this_local" field which is expected
to query the frame to return the frame's base address. In your case,
it should probably be amd64_frame_base_address which, slightly
simplified, returns the frame->cache->base. And going back further,
you'll find that the frame cache is computed by amd64_frame_cache,
which is a wrapper around amd64_frame_cache_1, which uses prologue
parsing to determine the frame's base address. I am guessing that
this is where you need to look.

-- 
Joel