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

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

[Andrew Cagney]

Hello,

The x86-64 port, being the first to try to use dwarf2 cfa, is in the fun 
position of having to figure out how to integrate some of this stuff 
into gdb.  Just noticed this one...

x86-64 sets the function read_fp() to:

   set_gdbarch_read_fp (gdbarch, cfi_read_fp);

And the corresponding code:

/* Return the frame address.  */
CORE_ADDR
cfi_read_fp ()
{
   struct context *context;
   struct frame_state *fs;
   CORE_ADDR cfa;

   context = context_alloc ();
   fs = frame_state_alloc ();

   context->ra = read_pc () + 1;

   frame_state_for (context, fs);
   update_context (context, fs, 0);

   cfa = context->cfa;
   unwind_tmp_obstack_free ();
   return cfa;
}

Going through the dwarf2++ spec, I've seen CFA (Call Frame Address) and 
frame_base.  While they might turn out to have the same value, they are, 
I think, very different.

The CFA is a CFI specific concept (all about how to unwind stack frames 
and find register values) that, as far as I can tell, isn't intended for 
``public consumption''.  It is used by the stack unwind code as a base 
address for the frame being unwound.  As far as

Separate to this is the frame_base attribute of a function. My 
interpretation of this attribute is that it defines the traditional 
``frame pointer''.

I don't think x86-64-tdep.c should be using the CFA for frame->frame. 
Instead it should be computing frame_base.,

I'll likely bug-report this.

enjoy,
Andrew

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

[Daniel Berlin]

On Tue, 9 Apr 2002, Andrew Cagney wrote:

> Hello,
> 
> The x86-64 port, being the first to try to use dwarf2 cfa, is in the fun 
> position of having to figure out how to integrate some of this stuff 
> into gdb.  Just noticed this one...
> 
> x86-64 sets the function read_fp() to:
> 
>    set_gdbarch_read_fp (gdbarch, cfi_read_fp);
> 
> And the corresponding code:
> 
> /* Return the frame address.  */
> CORE_ADDR
> cfi_read_fp ()
> {
>    struct context *context;
>    struct frame_state *fs;
>    CORE_ADDR cfa;
> 
>    context = context_alloc ();
>    fs = frame_state_alloc ();
> 
>    context->ra = read_pc () + 1;
> 
>    frame_state_for (context, fs);
>    update_context (context, fs, 0);
> 
>    cfa = context->cfa;
>    unwind_tmp_obstack_free ();
>    return cfa;
> }
> 
> Going through the dwarf2++ spec, I've seen CFA (Call Frame Address) and 
> frame_base.  While they might turn out to have the same value, they are, 
> I think, very different.
> 
> The CFA is a CFI specific concept (all about how to unwind stack frames 
> and find register values) that, as far as I can tell, isn't intended for 
> ``public consumption''.  It is used by the stack unwind code as a base 
> address for the frame being unwound.  As far as
> 
> Separate to this is the frame_base attribute of a function. My 
> interpretation of this attribute is that it defines the traditional 
> ``frame pointer''.
> 
> I don't think x86-64-tdep.c should be using the CFA for frame->frame. 
> Instead it should be computing frame_base.,
> 
> I'll likely bug-report this.

It might just be misnamed.

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.


 > 
> enjoy,
> Andrew
> 

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

[Andrew Cagney]

> 
> 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.

> 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

Andrew

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

[Daniel Berlin]

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
> 

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

[Andrew Cagney]

>> 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)

Please re-read what I wrote.

Andrew

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

[Daniel Berlin]

On Tue, 9 Apr 2002, Andrew Cagney wrote:

> 
> >> 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)
> 
> Please re-read what I wrote.

You said " The problem is that this algorithm assumes that each frame uses 
the same mechanism for locating register values.  With
                       the introduction of dwarf2cfi, this is no longer 
true.  Some frames may use the debug info while others may use the
                       old prologue analysis technique.
"

You are incorrect.
It's an either-or case. Never is their a mixture of methods, unless you do 
something illegal.

> 
> Andrew
> 

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

[Andrew Cagney]

> 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.

And?

> 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?

> 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.

Andrew

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

[Daniel Berlin]

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 
DW_AT_frame_base.

You claimed it should.
It can't.


> > 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.

> 
> Andrew
> 
> 

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

[Andrew Cagney]

> 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

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

[Andrew Cagney]

>> Please re-read what I wrote.
> 
> 
> You said " The problem is that this algorithm assumes that each frame uses 
> the same mechanism for locating register values.  With
>                        the introduction of dwarf2cfi, this is no longer 
> true.  Some frames may use the debug info while others may use the
>                        old prologue analysis technique.
> "
> 
> You are incorrect.

We're going to have to agree to disagree.

> It's an either-or case. Never is their a mixture of methods, unless you do 
> something illegal.

If GDB decides to do what you state, it will be incapable of unwinding 
through libraries (where there is no debug info).

I think that is a significant feature loss and one I don't consder 
acceptable.

I see no reason why GDB shouldn't act ``illegally'' and use the 
traditional prolog scanner as a fallback to debug info.

Andrew

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

[Daniel Berlin]

On Tue, 9 Apr 2002, Andrew Cagney wrote:

> 
> >> Please re-read what I wrote.
> > 
> > 
> > You said " The problem is that this algorithm assumes that each frame uses 
> > the same mechanism for locating register values.  With
> >                        the introduction of dwarf2cfi, this is no longer 
> > true.  Some frames may use the debug info while others may use the
> >                        old prologue analysis technique.
> > "
> > 
> > You are incorrect.
> 
> We're going to have to agree to disagree.
> 
Okeydokey.

> > It's an either-or case. Never is their a mixture of methods, unless you do 
> > something illegal.
> 
> If GDB decides to do what you state, it will be incapable of unwinding 
> through libraries (where there is no debug info).

Libraries have debug info as well.

Even those without debug info, can still have dwarf2 frame info.
Most do these days.
You just don't realize it.
The default libc that came with my ppc linux distribution contains unwind 
info for all routines, fer instance. It's glibc 2.2.4 based, for the 
curious.  I installed this distribution a *while* ago, so it's not a 
recent happening.
All the libraries have unwind info as well.
No debug info, just unwind info.
> 
> I think that is a significant feature loss and one I don't consder 
> acceptable.
Who says you have lost a feature?
> 
> I see no reason why GDB shouldn't act ``illegally'' and use the 
> traditional prolog scanner as a fallback to debug info.
Now you've twisted my words.
I said it would be illegal to attempt to use .eh_frame under the 
assumption it contains unwind info for all routines. It might, it might 
not.
I said nothing about prolog scanning, besides that it is unnecessary when 
the dwarf2 unwind info is present.
 > 
> Andrew
>