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: 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.4.44.0204091358180.11863-100000@dberlin.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
> DW_AT_frame_base.
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.
Andrew