This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Joel Brobecker <> 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  <>
> > 
> > 	* 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.

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.

But, my case is different from

    print $fp

.  It's more like:

    print foo

where the debug information says foo lives at $fp - 24.

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.

Trying to find a local function variable at address -32 or -28 or -24
does not work.  It is not mapped and even if it was, it wouldn't be the
right address.  Now, $rbp - 32 or $rbp - 28 is another matter entirely.

GDB is currently saying ``I've been asked for the value of $fp, but I
don't know which register is the frame pointer, so I don't have a value
for $fp, and I'll just use 0''.

The one line fix fixed real problems we had with STABS on our legacy
systems.  And has caused no problems with DWARF on our current systems.

> I wish I could suggest another approach but I haven't had to touch
> stabs support in several years, now. If you provided a bit more details
> as to what actually happened in the debugger and where, I might be
> able to help you better.

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.

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.

> > diff --git a/gdb/amd64-tdep.c b/gdb/amd64-tdep.c
> > index e69da01..5a68c33 100644
> > --- a/gdb/amd64-tdep.c
> > +++ b/gdb/amd64-tdep.c
> > @@ -3006,6 +3006,8 @@ amd64_init_abi (struct gdbarch_info info, struct gdbarch *
> > gdbarch)
> >    set_gdbarch_ps_regnum (gdbarch, AMD64_EFLAGS_REGNUM); /* %eflags */
> >    set_gdbarch_fp0_regnum (gdbarch, AMD64_ST0_REGNUM); /* %st(0) */
> >  
> > +  set_gdbarch_deprecated_fp_regnum (gdbarch, AMD64_RBP_REGNUM); /* %rbp */
> > +
> >    /* The "default" register numbering scheme for AMD64 is referred to
> >       as the "DWARF Register Number Mapping" in the System V psABI.
> >       The preferred debugging format for all known AMD64 targets is
> -- 
> Joel

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]