From: Daniel Berlin <dan@www.cgsoftware.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: <gdb@sources.redhat.com>
Subject: Re: Integrating DWARF2 CFA info
Date: Thu, 10 May 2001 08:57:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.33.0105101151430.9863-100000@www.cgsoftware.com> (raw)
In-Reply-To: <3AFA0E37.3020906@cygnus.com>
On Wed, 9 May 2001, Andrew Cagney wrote:
> > So i've got the dwarf2 CFA info being used now, when available, to
> > find the location of a register.
>
> (What exactly does CFA mean. I know what you're refering to, just not
> the acronym).
>
Call Frame Annotation.
>
> > gdbarch functions aren't stackable, so i can't just implement a
> > dwarf2_get_saved_register that uses the dwarf2 cfa info, and if it's
> > not available, calls the next lower level get_saved_register function.
>
> I don't think a stack is applicable here. As you move between frames
> the debug info could change and the get_saved_register() functions
> should adapt accordingly. Having a stack would imply a specific
> heirichy and that isn't correct in this case.
Well, actually, IMHO, it is.
The CFA info gives us the location of all saved registers for the entire
procedure.
It's always correct, even in the presence of optimization.
Given the pc for the frame, it can tell you exactly where all the saved
registers are, at that particular point in time.
Therefore, it is strictly better to use the CFA info, than scan the
instructions.
So I see a strict hiearchy of what to use:
Dwarf2 CFA Info
<whatever else>
>
> Andrew
>
>
next prev parent reply other threads:[~2001-05-10 8:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-07 12:08 Daniel Berlin
2001-05-10 8:33 ` Andrew Cagney
2001-05-10 8:57 ` Daniel Berlin [this message]
2001-05-10 10:04 ` Andrew Cagney
2001-05-10 11:07 ` Daniel Berlin
2001-05-10 11:19 ` Daniel Berlin
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=Pine.LNX.4.33.0105101151430.9863-100000@www.cgsoftware.com \
--to=dan@www.cgsoftware.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