From: Kevin Buettner <kevinb@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>, gdb@sources.redhat.com
Subject: Re: [rfc] frame->frame => frame->addr && frame->base()
Date: Thu, 11 Apr 2002 15:29:00 -0000 [thread overview]
Message-ID: <1020411222935.ZM4098@localhost.localdomain> (raw)
In-Reply-To: Andrew Cagney <ac131313@cygnus.com> "[rfc] frame->frame => frame->addr && frame->base()" (Apr 11, 4:56pm)
On Apr 11, 4:56pm, Andrew Cagney wrote:
> This comes from DanielB's and my discussion about dwarf2 CFA and
> dwarf2's frame_base vs GDB's frame->frame.
>
> An executive summary is that the two dwarf2 frame concepts (CFA and
> frame_base) do not go into one GDB frame (frame->frame).
>
> Because of this, I'd like to propose that the frame object have both:
>
> struct frame_info
> {
> ...
>
> // An ISA/ABI specific address within the ``specified frame'' that is
> constant throughout the lifetime of the frame. This address is used by
> GDB as a handle to identify this frame. This field must be initialized
> as part of the creation of a frame object. (see dwarf2 CFA)
>
> CORE_ADDR addr;
I like this. I find frame->frame confusing. Also, I like it that
you're documenting the fact that this value remains constant over the
lifetime of the frame. I think we have a number of targets which
don't get this right.
> // High level language concept of the base address of a frame. Often
> refered to as ``frame_base'' or ``frame pointer''. This value should
> only be computed on-demand. It is strongly recommended, though, that
> implementations cache the computed value in the frame cache. The method
> is initialized as part of the frame objects creation. The default
> method returns frame->addr. (see dwarf2 DW_AT_frame_base)
>
> CORE_ADDR (*base) (struct frame_info *frame);
This translates the CFA (canonical frame address) into an address that's
useful for some other purpose, right? What are the purposes that it
would be used for?
(My worry is that there may be more than one translation which might
prove to be useful.)
Kevin
next prev parent reply other threads:[~2002-04-11 22:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-11 13:56 Andrew Cagney
2002-04-11 15:29 ` Kevin Buettner [this message]
2002-04-11 16:42 ` Andrew Cagney
2002-04-12 5:54 ` Richard Earnshaw
2002-04-12 7:05 ` Andrew Cagney
2002-04-12 5:50 ` Richard Earnshaw
2002-04-12 6:38 ` Andrew Cagney
2002-04-12 8:53 ` Kevin Buettner
2002-04-12 9:05 ` Andrew Cagney
2002-04-12 14:59 ` Jim Blandy
2002-04-26 7:58 ` Andrew Cagney
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=1020411222935.ZM4098@localhost.localdomain \
--to=kevinb@redhat.com \
--cc=ac131313@cygnus.com \
--cc=gdb@sources.redhat.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