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 14:00:22 -0400 (EDT)
- Subject: Re: think-o: dwarf2 CFA != frame->frame (x86-64)
On Tue, 9 Apr 2002, Andrew Cagney wrote:
> > 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
> > executable
> > 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.
> (Didn't I point you at 3.3.5? :-).
> Location expressions use DW_OP_fbreg when they need to refer to the
> stack. DW_OP_fpreg is defined in terms of DW_AT_frame_base. Can you
> please point me to the section where a location expression OP directly
> (not indirectly as in a register) refers to the CFA?
No, why would I need to?
For all intents and purposes, you could severe the CFA sections of the
dwarf2 spec, and place them into something called "the CFA spec".
It doesn't change the fact that frame->base with CFA info can't use
You claimed it should.
> > For all intents and purposes, the CFA is the frame base when using dwarf2
> > cfi info.
> If you read my original e-mail, you'll notice that I observed that the
> two most likely end up having the same value.