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

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Mon, 01 Dec 2014 11:30:30 -0500
> From: David Taylor <dtaylor@usendtaylorx2l.lss.emc.com>
> 
> Joel Brobecker <brobecker@adacore.com> wrote:
> 
> > David,
> > 
> > On Fri, Nov 21, 2014 at 03:58:04PM -0500, David Taylor wrote:
> > > Sometimes when using STABS on x86-64 GNU/Linux, GDB does not know which
> > > register to use for the frame pointer and as a result offsets from the
> > > frame pointer are treated as absolute addresses rather than as
> > > offsets...
> > > 
> > > This patch provides a default for when the debug information doesn't
> > > specify which register to use.
> > > 
> > > We have seen this problem when debugging problems with a previous
> > > release of our software (I believe it was built with GCC 4.5.x, if that
> > > matters).
> > > 
> > > There were no regressions on x86-64 GNU/Linux.
> > > 
> > > 2014-11-21  David Taylor  <dtaylor@emc.com>
> > > 
> > > 	* amd64-tdep.c (amd64_init_abi): Set default frame pointer.
> > 
> > I don't think your patch is correct, as it is going to affect
> > the outcome of...
> > 
> >     (gdb) print $fp
> > 
> > ... for frameless functions compiled with DWARF2. See
> > std-regs.c:value_of_builtin_frame_fp_reg.
> > 
> > If we were to apply your patch, it would unconditionally print
> > the contents of the %rbp register as the result, which is not
> > what we've been printing so far.
> 
> 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.

We deprecated the concept of a frame pointer "register" more than a
decade ago.  There really isn't such a register on many architectures.
On amd64 %rbp is available for the compiler to use for whatever
purpose it sees fit.  Reintroducing a real frame pointer register in
the amd64-tdep.c code would be a mistake.  The
set_gdbarch_deprecated_fp_regnum() function has "deprecated" in its
name for a reason.

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

In GDB there always is a frame.  A frameless function is a function
that doesn't set up its own frame but re-uses the frame set up by its
parent.  So that matches "would be the frame pointer for the most
recent function that had a frame".

> But, my case is different from
> 
>     print $fp
> 
> .  It's more like:
> 
>     print foo
> 
> where the debug information says foo lives at $fp - 24.

The question here is how your debug format actually defines $fp here.
For DWARF2 this is reasonably well defined.  It has the concept of a
call frame address CFA and provides enough information to reconstruct
that address.  For STABS this isn't well defined.  Hopefully it
matches GDB's idea of "frame base", which is what $fp represents.

Few of us have really looked at the STABS code in GDB in the last
decae.  The mainstream Open Source world moved to DWARF2 long ago, and
there is a substantial amount of bitrot in the STABS-related code,
both on the producer (GCC) and consumer (GDB) side.  But judging from
what you write here:

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

This seems to suggest that the real bug is in GDB's STABS code.  It
should probably encode the address of your variable as being
LOC_LOCAL, in which case the address would be calculated as relative
to the "frame locals" address which for most architectures (including
amd64) is the same as "frame base".

...

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

The problem here is that by choosing to use STABS on amd64 for your
platform you're now so far behind the curve that there's basically
nobody around with enough knowledge to help you out.  All I can say to
you is that your suggested fix isn't the right approach.