Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Luis Machado <lgustavo@codesourcery.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: "Carl E. Love" <cel@us.ibm.com>, Pedro Alves <palves@redhat.com>,
	Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
	Edjunior Barbosa Machado	<emachado@linux.vnet.ibm.com>,
	<gdb-patches@sourceware.org>
Subject: Re: [PATCH] Fix for gdb.base/pc-fp.exp.
Date: Tue, 23 Aug 2016 17:19:00 -0000	[thread overview]
Message-ID: <8507525d-035f-8fb2-d73e-2285d5bb276b@codesourcery.com> (raw)
In-Reply-To: <20160823170619.2D2C75BCB@oc7340732750.ibm.com>

On 08/23/2016 12:06 PM, Ulrich Weigand wrote:
> 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
>

Fair enough. I was just checking what the outcome would be with Power 
Embedded and if it had been tested, since the original mail doesn't make 
it explicit what the failure mode is, nor what specific test is failing.


  reply	other threads:[~2016-08-23 17:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-22 21:16 Carl E. Love
2016-08-22 23:17 ` Pedro Alves
2016-08-23 16:17   ` Carl E. Love
2016-08-23 16:26     ` Luis Machado
2016-08-23 17:06       ` Ulrich Weigand
2016-08-23 17:19         ` Luis Machado [this message]
2016-08-23 16:30     ` Ulrich Weigand
2016-08-24 15:15       ` Carl E. Love

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8507525d-035f-8fb2-d73e-2285d5bb276b@codesourcery.com \
    --to=lgustavo@codesourcery.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=cel@us.ibm.com \
    --cc=emachado@linux.vnet.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=uweigand@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox