From: Jim Blandy <jimb@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: [rfc] frame->frame => frame->addr && frame->base()
Date: Fri, 12 Apr 2002 14:59:00 -0000 [thread overview]
Message-ID: <np1ydk4lz4.fsf@zwingli.cygnus.com> (raw)
In-Reply-To: <3CB5F868.8070001@cygnus.com>
Andrew Cagney <ac131313@cygnus.com> writes:
> Hello,
>
> 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;
If this needs to be equal to the Dwarf 2 CFA value, it seems to me the
comment should say that explicitly. Of course the explanation
shouldn't be specific to any debug format, but it should relate its
meaning to various interesting debug formats; see my suggested text
below.
> // 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);
Same here --- I think the comment needs to be more explicit on what
this function's value must mean. For example:
Function that returns the frame's base address, for local variable
references. Most debug info formats describe the locations of
stack-based local variables as offsets from some assumed base
address; exactly what that base address is (frame pointer register?
stack pointer?) varies from machine to machine. Whatever the case,
this function computes that base address.
For Dwarf 2, the base address is the value given by the function's
DW_AT_frame_base attribute, and the value that the DW_OP_fbreg
instruction pushes; for STABS, the value of an N_LSYM stab is the
offset from this base address to the variable.
next prev parent reply other threads:[~2002-04-12 21:59 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
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 [this message]
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=np1ydk4lz4.fsf@zwingli.cygnus.com \
--to=jimb@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