This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix for gdb.base/pc-fp.exp.
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: lgustavo at codesourcery dot com
- Cc: cel at us dot ibm dot com (Carl E. Love), palves at redhat dot com (Pedro Alves), Ulrich dot Weigand at de dot ibm dot com (Ulrich Weigand), emachado at linux dot vnet dot ibm dot com (Edjunior Barbosa Machado), gdb-patches at sourceware dot org
- Date: Tue, 23 Aug 2016 19:06:19 +0200 (CEST)
- Subject: Re: [PATCH] Fix for gdb.base/pc-fp.exp.
- Authentication-results: sourceware.org; auth=none
Luis Machado wrote:
> On 08/23/2016 11:17 AM, Carl E. Love wrote:
> > It is my understanding that GDB used to require each architecture to
> > define a Frame Pointer (fp). However, this functionality was deprecated
> > some time ago so the call to setup the fp_reg was changed to deprecated
> > (set_gdbarch_deprecated_fp_regnum). It should have been removed from the
> > Power code.
> >
> > That said, the code "set_gdbarch_deprecated_fp_regnum
> > (gdbarch, PPC_R0_REGNUM + 1);" sets up register r1 as the frame pointer.
> > Register r1 is no longer used to hold the frame pointer on Power. By
> > removing the fp definition for Power in GDB, it causes GDB to fall back
> > to the call get_frame_base_address (frame) which returns the correct value
> > depending on the specific senario but most of the time is the DWARF
> > canonical frame address.
>
> Is this the case for all Power ABI's or only server? I wonder what the
> impact would be on Power embedded.
This doesn't really have anything to do with the ABI. As I said in the other
email, the only effect of set_gdbarch_deprecated_fp_regnum these days is to
affect what value GDB prints for $fp. This has really no meaning for anything
except that MI front ends use it to identify stack frames: you examine a
frame's $fp value, and use it as argument to the -var-create MI command in
order to create a variable bound to this frame. (And even that usage is
really questionably, and only remains in there to avoid incompatible changes
in the interface. The "natural" way these days to identify a frame would
be via its frame ID.)
For this to work, the value of $fp must be the value of get_frame_base_address,
which means set_gdbarch_deprecated_fp_regnum must not be used. And in fact
basically no targets do use it, except for rs6000 and frv, both of which
seem to be just incorrect.
(Note that in any case, the rs6000 back end sets deprecated_fp_regnum to 1,
which has never been the *frame pointer* register in any ABI, even those
that -sometimes- use one. In fact, it is the *stack pointer* register ...)
(Also note that there is a second remaining use of deprecated_fp_regnum,
in legacy_virtual_frame_pointer. This whole routine is really a hack and
probably doesn't work in any except the most trivial circumstances. Even
so, Carl's change is a no-op for legacy_virtual_frame_pointer, since if
deprecated_fp_regnum isn't set, it will fall back to sp_regnum, which is
in fact also register 1 on rs6000.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com