This is the mail archive of the
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 13:03:18 -0400 (EDT)
- Subject: Re: think-o: dwarf2 CFA != frame->frame (x86-64)
On Tue, 9 Apr 2002, Andrew Cagney wrote:
> > It might just be misnamed.
> No. DW_OP_fbreg refers explicitly to DW_AT_frame_base. CFA is a
> concept local to the CFI. They would typically evaluate to the same
> value though.
DW_AT_frame_base is part of the .debug_info section.
This is symbolic debug info, none of which is required to be present in an
On the other hand, the CFA info is required to be present on x86-64,
specifically for the purposes of unwinding the stack.
So you can't say that it should use DW_AT_frame_base. It can't.
DW_AT_frame_base is a completely different concept. It is not intended to
have anything to do with unwinding the stack. It also has nothing
necessarily to do with a real frame base. See 3.3.5. This is why it's in
quotes. Most compiler use it in way 1 described in that section, to
simplify location descriptions.
For all intents and purposes, the CFA is the frame base when using dwarf2
> > 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.
Sorry, this is incorrect.
When debug_frame info is present, it is the *only* way used to
retrieve register values.
There is no mixture of methods.
Even in my case, either the executable contains .debug_frame info, and we
use it for *all* cases, or it doesn't, and we use it for *no* cases.
There is no mixture.
There will never be a mixture of methods (unless you do something illegal,
like attempt to use the .eh_frame section, which contains stack unwinding
only for routines throwing exceptions)