This is the mail archive of the
mailing list for the GDB project.
Re: think-o: dwarf2 CFA != frame->frame (x86-64)
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Daniel Berlin <dan at dberlin dot org>
- Cc: gdb at sources dot redhat dot com
- Date: Tue, 09 Apr 2002 14:52:15 -0400
- Subject: Re: think-o: dwarf2 CFA != frame->frame (x86-64)
- References: <Pine.LNX.firstname.lastname@example.org>
> 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
There are two concepts here (frame_base and CFA). GDB's frame->frame
can only correspond to one. My point is that GDB's concept of a
frame->frame best fits DW_AT_frame_base (the high level language frame
pointer) and not CFA (something for reverse engineering register locations).
Perhaphs GDB's concept is wrong. Given it is for debugging high level
languages I don't think so.