This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: think-o: dwarf2 CFA != frame->frame (x86-64)


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]