This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: think-o: dwarf2 CFA != frame->frame (x86-64)
- From: Daniel Berlin <dan at dberlin dot org>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Tue, 9 Apr 2002 02:43:08 -0400 (EDT)
- Subject: Re: think-o: dwarf2 CFA != frame->frame (x86-64)
On Tue, 9 Apr 2002, Andrew Cagney wrote:
> Hello,
>
> The x86-64 port, being the first to try to use dwarf2 cfa, is in the fun
> position of having to figure out how to integrate some of this stuff
> into gdb. Just noticed this one...
>
> x86-64 sets the function read_fp() to:
>
> set_gdbarch_read_fp (gdbarch, cfi_read_fp);
>
> And the corresponding code:
>
> /* Return the frame address. */
> CORE_ADDR
> cfi_read_fp ()
> {
> struct context *context;
> struct frame_state *fs;
> CORE_ADDR cfa;
>
> context = context_alloc ();
> fs = frame_state_alloc ();
>
> context->ra = read_pc () + 1;
>
> frame_state_for (context, fs);
> update_context (context, fs, 0);
>
> cfa = context->cfa;
> unwind_tmp_obstack_free ();
> return cfa;
> }
>
> Going through the dwarf2++ spec, I've seen CFA (Call Frame Address) and
> frame_base. While they might turn out to have the same value, they are,
> I think, very different.
>
> The CFA is a CFI specific concept (all about how to unwind stack frames
> and find register values) that, as far as I can tell, isn't intended for
> ``public consumption''. It is used by the stack unwind code as a base
> address for the frame being unwound. As far as
>
> Separate to this is the frame_base attribute of a function. My
> interpretation of this attribute is that it defines the traditional
> ``frame pointer''.
>
> I don't think x86-64-tdep.c should be using the CFA for frame->frame.
> Instead it should be computing frame_base.,
>
> I'll likely bug-report this.
It might just be misnamed.
I've converted rs6000 to use the dwarf2 cfa info (It's a little hairier,
since on x86-64, you *always* have the info, it's part of the ABI), and it
works just fine, even on optimized code. This is with the fallback to
normal methods in case the info isn't in the executable, disabled, so i'd
get errors if it wasn't using *only* the dwarf2 info.
>
> enjoy,
> Andrew
>