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)


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. 

For all intents and purposes, the CFA is the frame base when using dwarf2 
cfi info.


> 
> > 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.
> > 
> > 
> 
> See:
> 
> http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=466
> 

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)

> Andrew
> 



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