frame->unwind->this_base()

frame->unwind->this_base()

[Andrew Cagney]

At present there is a per-frame ID method since different frames 
determine their ID using different techniques.  The ID (which identifies 
a given frame instance) includes a base and pc/func value.

GDB's frame code also makes available the get_frame_base() method. 
While the default implementation returns get_frame_id().base, I think 
there is going to need to be a per-frame frame->unwind->this_base method.

For dwarf2 frames, it would return, DW_AT_frame_base.  For prologue 
frames, it would return an attempt at an equivalent value.  Hopefully it 
wouldn't be called for other frame types :-).

It might even be reasonable for a prologue based unwinder to error out 
when asked for the frame's base before the stack frame has been created.

Thoughts?

I should note that dwarf2expr.c contains code that tries to 
locally/directly evaluate the frame base.  I think that should instead 
do a get_frame_base() call.

Andrew

Re: frame->unwind->this_base()

[Daniel Jacobowitz]

On Sun, Mar 16, 2003 at 05:04:36PM -0500, Andrew Cagney wrote:
> At present there is a per-frame ID method since different frames 
> determine their ID using different techniques.  The ID (which identifies 
> a given frame instance) includes a base and pc/func value.
> 
> GDB's frame code also makes available the get_frame_base() method. 
> While the default implementation returns get_frame_id().base, I think 
> there is going to need to be a per-frame frame->unwind->this_base method.
> 
> For dwarf2 frames, it would return, DW_AT_frame_base.  For prologue 
> frames, it would return an attempt at an equivalent value.  Hopefully it 
> wouldn't be called for other frame types :-).
> 
> It might even be reasonable for a prologue based unwinder to error out 
> when asked for the frame's base before the stack frame has been created.
> 
> Thoughts?
> 
> I should note that dwarf2expr.c contains code that tries to 
> locally/directly evaluate the frame base.  I think that should instead 
> do a get_frame_base() call.

There's no guarantee right now that the DW_AT_frame_base agrees with
the frame's base.  I don't even think it's necessary that they be the
same.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: frame->unwind->this_base()

[Andrew Cagney]

> On Sun, Mar 16, 2003 at 05:04:36PM -0500, Andrew Cagney wrote:
> 
>> At present there is a per-frame ID method since different frames 
>> determine their ID using different techniques.  The ID (which identifies 
>> a given frame instance) includes a base and pc/func value.
>> 
>> GDB's frame code also makes available the get_frame_base() method. 
>> While the default implementation returns get_frame_id().base, I think 
>> there is going to need to be a per-frame frame->unwind->this_base method.
>> 
>> For dwarf2 frames, it would return, DW_AT_frame_base.  For prologue 
>> frames, it would return an attempt at an equivalent value.  Hopefully it 
>> wouldn't be called for other frame types :-).
>> 
>> It might even be reasonable for a prologue based unwinder to error out 
>> when asked for the frame's base before the stack frame has been created.
>> 
>> Thoughts?
>> 
>> I should note that dwarf2expr.c contains code that tries to 
>> locally/directly evaluate the frame base.  I think that should instead 
>> do a get_frame_base() call.
> 
> 
> There's no guarantee right now that the DW_AT_frame_base agrees with
> the frame's base.  I don't even think it's necessary that they be the
> same.

There is certainly no guarentee that the DW_AT_frame_base and `struct 
frame_id.base' match.

However, shouldn't the only thing needing the `virtual frame pointer' / 
get_frame_base() be the code that needs a virtual base pointer when 
computing the value of a local variable?

Andrew

Re: frame->unwind->this_base()

[Daniel Jacobowitz]

On Sun, Mar 16, 2003 at 07:09:03PM -0500, Andrew Cagney wrote:
> >On Sun, Mar 16, 2003 at 05:04:36PM -0500, Andrew Cagney wrote:
> >
> >>At present there is a per-frame ID method since different frames 
> >>determine their ID using different techniques.  The ID (which identifies 
> >>a given frame instance) includes a base and pc/func value.
> >>
> >>GDB's frame code also makes available the get_frame_base() method. 
> >>While the default implementation returns get_frame_id().base, I think 
> >>there is going to need to be a per-frame frame->unwind->this_base method.
> >>
> >>For dwarf2 frames, it would return, DW_AT_frame_base.  For prologue 
> >>frames, it would return an attempt at an equivalent value.  Hopefully it 
> >>wouldn't be called for other frame types :-).
> >>
> >>It might even be reasonable for a prologue based unwinder to error out 
> >>when asked for the frame's base before the stack frame has been created.
> >>
> >>Thoughts?
> >>
> >>I should note that dwarf2expr.c contains code that tries to 
> >>locally/directly evaluate the frame base.  I think that should instead 
> >>do a get_frame_base() call.
> >
> >
> >There's no guarantee right now that the DW_AT_frame_base agrees with
> >the frame's base.  I don't even think it's necessary that they be the
> >same.
> 
> There is certainly no guarentee that the DW_AT_frame_base and `struct 
> frame_id.base' match.
> 
> However, shouldn't the only thing needing the `virtual frame pointer' / 
> get_frame_base() be the code that needs a virtual base pointer when 
> computing the value of a local variable?

Yes, and that's the only time that we search for the frame base.  But
what difference does it make?  At that point we have an offset that we
know is relative to DW_AT_frame_base, but we don't know if it's
relative to what the rest of GDB considers the frame base (since we
never use DW_AT_frame_base to compute the frame base in the first
place; and it's not clear to me that we should be).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: frame->unwind->this_base()

[Andrew Cagney]

>> However, shouldn't the only thing needing the `virtual frame pointer' / 
>> get_frame_base() be the code that needs a virtual base pointer when 
>> computing the value of a local variable?
> 
> 
> Yes, and that's the only time that we search for the frame base.  But
> what difference does it make?

(gdb) info frame

will display the correct value.

> At that point we have an offset that we
> know is relative to DW_AT_frame_base, but we don't know if it's
> relative to what the rest of GDB considers the frame base (since we
> never use DW_AT_frame_base to compute the frame base in the first
> place; and it's not clear to me that we should be).

Where, apart from `info frame', and variable evaluation, is it correct 
for GDB to use the frame base?

Andrew

Re: frame->unwind->this_base()

[Daniel Jacobowitz]

On Mon, Mar 17, 2003 at 11:22:35AM -0500, Andrew Cagney wrote:
> 
> >>However, shouldn't the only thing needing the `virtual frame pointer' / 
> >>get_frame_base() be the code that needs a virtual base pointer when 
> >>computing the value of a local variable?
> >
> >
> >Yes, and that's the only time that we search for the frame base.  But
> >what difference does it make?
> 
> (gdb) info frame
> 
> will display the correct value.

What does "correct" mean though?

> >At that point we have an offset that we
> >know is relative to DW_AT_frame_base, but we don't know if it's
> >relative to what the rest of GDB considers the frame base (since we
> >never use DW_AT_frame_base to compute the frame base in the first
> >place; and it's not clear to me that we should be).
> 
> Where, apart from `info frame', and variable evaluation, is it correct 
> for GDB to use the frame base?

I'm sorry, but I just don't understand what you're asking.  We use the
frame base all over.

The current frame base (i.e. id.base) is produced by target specific
code - often via prologue analysis; on x86-64 via CFI; etc.

The prologue analyzer, CFI code, etc. use the frame base when finding
saved registers, the saved PC value, et cetera.  For instance i386 uses
it to read the saved PC off of the stack.  This defines what GDB
expects to be the frame base.

The compiler doesn't necessarily have the same idea of the frame base. 
It can pick a convenient location, which may be biased some number of
words away from what GDB considers the frame base.  There's any number
of reasons this might happen.  Depending on, for instance, the
architecture's ABI and the available instructions for frame-relative
loads.

When using information computed by GDB we may need to use the current
frame base.  When using information provided by the compiler we
probably need to use the compiler provided frame base.

Are you saying that you want GDB always to use the DW_AT_frame_base? 
That's a bit of a leap from where we are today.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: frame->unwind->this_base()

[Andrew Cagney]

> On Mon, Mar 17, 2003 at 11:22:35AM -0500, Andrew Cagney wrote:
> 
>> 
> 
>> >>However, shouldn't the only thing needing the `virtual frame pointer' / 
>> >>get_frame_base() be the code that needs a virtual base pointer when 
>> >>computing the value of a local variable?
> 
>> >
>> >
>> >Yes, and that's the only time that we search for the frame base.  But
>> >what difference does it make?
> 
>> 
>> (gdb) info frame
>> 
>> will display the correct value.
> 
> 
> What does "correct" mean though?

Display the frame's `virtual base pointer'.

>> >At that point we have an offset that we
>> >know is relative to DW_AT_frame_base, but we don't know if it's
>> >relative to what the rest of GDB considers the frame base (since we
>> >never use DW_AT_frame_base to compute the frame base in the first
>> >place; and it's not clear to me that we should be).
> 
>> 
>> Where, apart from `info frame', and variable evaluation, is it correct 
>> for GDB to use the frame base?
> 
> 
> I'm sorry, but I just don't understand what you're asking.  We use the
> frame base all over.
> 
> The current frame base (i.e. id.base) is produced by target specific
> code - often via prologue analysis; on x86-64 via CFI; etc.

Er,

> GDB's frame code also makes available the get_frame_base() method. While the default implementation returns get_frame_id().base, I think there is going to need to be a per-frame frame->unwind->this_base method.

get_frame_base() returns ->frame and NOT ->id.base.

Andrew

Re: frame->unwind->this_base()

[Daniel Jacobowitz]

On Mon, Mar 17, 2003 at 11:56:40AM -0500, Andrew Cagney wrote:
> >On Mon, Mar 17, 2003 at 11:22:35AM -0500, Andrew Cagney wrote:
> >
> >>
> >
> >>>>However, shouldn't the only thing needing the `virtual frame pointer' / 
> >>>>get_frame_base() be the code that needs a virtual base pointer when 
> >>>>computing the value of a local variable?
> >
> >>>
> >>>
> >>>Yes, and that's the only time that we search for the frame base.  But
> >>>what difference does it make?
> >
> >>
> >>(gdb) info frame
> >>
> >>will display the correct value.
> >
> >
> >What does "correct" mean though?
> 
> Display the frame's `virtual base pointer'.
> 
> >>>At that point we have an offset that we
> >>>know is relative to DW_AT_frame_base, but we don't know if it's
> >>>relative to what the rest of GDB considers the frame base (since we
> >>>never use DW_AT_frame_base to compute the frame base in the first
> >>>place; and it's not clear to me that we should be).
> >
> >>
> >>Where, apart from `info frame', and variable evaluation, is it correct 
> >>for GDB to use the frame base?
> >
> >
> >I'm sorry, but I just don't understand what you're asking.  We use the
> >frame base all over.
> >
> >The current frame base (i.e. id.base) is produced by target specific
> >code - often via prologue analysis; on x86-64 via CFI; etc.
> 
> Er,
> 
> >GDB's frame code also makes available the get_frame_base() method. While 
> >the default implementation returns get_frame_id().base, I think there is 
> >going to need to be a per-frame frame->unwind->this_base method.
> 
> get_frame_base() returns ->frame and NOT ->id.base.

OK, I'm definitely going around in confused little circles.  Don't the
two statements above disagree?  The current get_frame_base does return
->frame but you also say above that get_frame_base should return
get_frame_id().base.

Conceptually, are frame->frame and frame->id.base supposed to be the
same?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: frame->unwind->this_base()

[Andrew Cagney]

>> >GDB's frame code also makes available the get_frame_base() method. While 
>> >the default implementation returns get_frame_id().base, I think there is 
>> >going to need to be a per-frame frame->unwind->this_base method.
> 
>> 
>> get_frame_base() returns ->frame and NOT ->id.base.
> 
> 
> OK, I'm definitely going around in confused little circles.  Don't the
> two statements above disagree?

No.  See get_prev_frame() where it is defaulting ->frame to ->id.base.

 > The current get_frame_base does return
> ->frame but you also say above that get_frame_base should return
> get_frame_id().base.

No.  Default to get_frame_id().base.

> Conceptually, are frame->frame and frame->id.base supposed to be the
> same?

No?

Andrew

Re: frame->unwind->this_base()

[Daniel Jacobowitz]

On Mon, Mar 17, 2003 at 01:20:28PM -0500, Andrew Cagney wrote:
> 
> >>>GDB's frame code also makes available the get_frame_base() method. While 
> >>>the default implementation returns get_frame_id().base, I think there is 
> >>>going to need to be a per-frame frame->unwind->this_base method.
> >
> >>
> >>get_frame_base() returns ->frame and NOT ->id.base.
> >
> >
> >OK, I'm definitely going around in confused little circles.  Don't the
> >two statements above disagree?
> 
> No.  See get_prev_frame() where it is defaulting ->frame to ->id.base.
> 
> > The current get_frame_base does return
> >->frame but you also say above that get_frame_base should return
> >get_frame_id().base.
> 
> No.  Default to get_frame_id().base.

So is that supposed to be a statement about the future in the first
paragraph?  It's sure not worded as one, no wonder I'm confused.

> >Conceptually, are frame->frame and frame->id.base supposed to be the
> >same?
> 
> No?

Then could you enlighten me as to what the difference is supposed to
be?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: frame->unwind->this_base()

[Andrew Cagney]

> On Mon, Mar 17, 2003 at 01:20:28PM -0500, Andrew Cagney wrote:
> 
>> 
> 
>> >>>GDB's frame code also makes available the get_frame_base() method. While 
>> >>>the default implementation returns get_frame_id().base, I think there is 
>> >>>going to need to be a per-frame frame->unwind->this_base method.
> 
>> >
> 
>> >>
>> >>get_frame_base() returns ->frame and NOT ->id.base.
> 
>> >
>> >
>> >OK, I'm definitely going around in confused little circles.  Don't the
>> >two statements above disagree?
> 
>> 
>> No.  See get_prev_frame() where it is defaulting ->frame to ->id.base.
>> 
> 
>> > The current get_frame_base does return
>> >->frame but you also say above that get_frame_base should return
>> >get_frame_id().base.
> 
>> 
>> No.  Default to get_frame_id().base.
> 
> 
> So is that supposed to be a statement about the future in the first
> paragraph?  It's sure not worded as one, no wonder I'm confused.

The present.  GDB historically has had FRAME_FP and frame->frame and 
their intended purposes were overloaded: per frame unique identifier, 
frame base pointer, ...

Frame ID provides a per-frame unique identifier.

>> >Conceptually, are frame->frame and frame->id.base supposed to be the
>> >same?
> 
>> 
>> No?
> 
> 
> Then could you enlighten me as to what the difference is supposed to
> be?

For dwarf2, check the spec where it discuss CFA (see CFI) and frame-base 
(see 3.3.5).

CFA + &function == frame_id
A per frame unique identifier that must be constant through out the 
lifetime of the frame.  CFI recommends the top-of-stack from the 
previous frame.

frame-base == get_frame_base()
What ever the debug info would like it to be.   The ISAs ABI will 
provide a strong set of guidelines though (if, for a framed function it 
doesn't match what the user expects, the'll likely complain :-).  It 
will often point into the middle of the stack frame.

Andrew

Re: frame->unwind->this_base()

[Daniel Jacobowitz]

On Mon, Mar 17, 2003 at 08:05:58PM -0500, Andrew Cagney wrote:
> >On Mon, Mar 17, 2003 at 01:20:28PM -0500, Andrew Cagney wrote:
> >
> >>
> >
> >>>>>GDB's frame code also makes available the get_frame_base() method. 
> >>While >>>the default implementation returns get_frame_id().base, I think 
> >>there is >>>going to need to be a per-frame frame->unwind->this_base 
> >>method.
> >
> >>>
> >
> >>>>
> >>>>get_frame_base() returns ->frame and NOT ->id.base.
> >
> >>>
> >>>
> >>>OK, I'm definitely going around in confused little circles.  Don't the
> >>>two statements above disagree?
> >
> >>
> >>No.  See get_prev_frame() where it is defaulting ->frame to ->id.base.
> >>
> >
> >>> The current get_frame_base does return
> >>>->frame but you also say above that get_frame_base should return
> >>>get_frame_id().base.
> >
> >>
> >>No.  Default to get_frame_id().base.
> >
> >
> >So is that supposed to be a statement about the future in the first
> >paragraph?  It's sure not worded as one, no wonder I'm confused.
> 
> The present.  GDB historically has had FRAME_FP and frame->frame and 
> their intended purposes were overloaded: per frame unique identifier, 
> frame base pointer, ...
> 
> Frame ID provides a per-frame unique identifier.
> 
> >>>Conceptually, are frame->frame and frame->id.base supposed to be the
> >>>same?
> >
> >>
> >>No?
> >
> >
> >Then could you enlighten me as to what the difference is supposed to
> >be?
> 
> For dwarf2, check the spec where it discuss CFA (see CFI) and frame-base 
> (see 3.3.5).
> 
> CFA + &function == frame_id
> A per frame unique identifier that must be constant through out the 
> lifetime of the frame.  CFI recommends the top-of-stack from the 
> previous frame.
> 
> frame-base == get_frame_base()
> What ever the debug info would like it to be.   The ISAs ABI will 
> provide a strong set of guidelines though (if, for a framed function it 
> doesn't match what the user expects, the'll likely complain :-).  It 
> will often point into the middle of the stack frame.

So in this case should we be hooking the get_frame_base() call to
return the computed DW_AT_frame_base?  If so, we're going to need to go
through all the uses and computations of the frame base in all targets
for consistency.  And what happens if we don't have DWARF-2
information?

I guess I just don't see how this evolves.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: frame->unwind->this_base()

[Andrew Cagney]

> 
> So in this case should we be hooking the get_frame_base() call to
> return the computed DW_AT_frame_base?  [...]  And what happens if we don't have DWARF-2
> information?

At the start I wrote:

 > For dwarf2 frames, it would return, DW_AT_frame_base.  For prologue 
frames, it would return an attempt at an equivalent value.  Hopefully it 
wouldn't be called for other frame types :-).

A better question is, what about other debug types?  The definition of 
the frame-base is dependant on the debug info.

Dig dig.  Other debug info (e.g., LOC_LOCAL) depends on 
FRAME_LOCALS_ADDRESS().  So to take this a step further, it is a merged 
FRAME_LOCALS_ADDRESS() + get_frame_base() that is needs to become per frame.

 > If so, we're going to need to go
 > through all the uses and computations of the frame base in all targets
 > for consistency.

All existing calls to get_frame_base() in core-gdb need to be audited 
anyway :-(  This is so that breakage such as VALUE_FRAME() can finally 
be laid to rest (see "frame.h", "frame ID" for why get_frame_base() 
isn't up to the task).

Andrew

Re: frame->unwind->this_base()

[Daniel Jacobowitz]

On Tue, Mar 18, 2003 at 09:54:29AM -0500, Andrew Cagney wrote:
> >
> >So in this case should we be hooking the get_frame_base() call to
> >return the computed DW_AT_frame_base?  [...]  And what happens if we don't 
> >have DWARF-2
> >information?
> 
> At the start I wrote:
> 
> > For dwarf2 frames, it would return, DW_AT_frame_base.  For prologue 
> frames, it would return an attempt at an equivalent value.  Hopefully it 
> wouldn't be called for other frame types :-).

OK.  I'll make the assumption that the DW_AT_frame_base and the CFA in
the dwarf2 unwind information (if both present) will agree.  If they
don't, well... we'll have to deal with that later.

> A better question is, what about other debug types?  The definition of 
> the frame-base is dependant on the debug info.
> 
> Dig dig.  Other debug info (e.g., LOC_LOCAL) depends on 
> FRAME_LOCALS_ADDRESS().  So to take this a step further, it is a merged 
> FRAME_LOCALS_ADDRESS() + get_frame_base() that is needs to become per frame.
> 
> > If so, we're going to need to go
> > through all the uses and computations of the frame base in all targets
> > for consistency.
> 
> All existing calls to get_frame_base() in core-gdb need to be audited 
> anyway :-(  This is so that breakage such as VALUE_FRAME() can finally 
> be laid to rest (see "frame.h", "frame ID" for why get_frame_base() 
> isn't up to the task).

Yep.  Thanks for holding my hand through this; I think I'm back on the
same page now.  I agree that eventually the business with evaluating
the DW_AT_frame_base should be reduced to a get_frame_base call,
although it may be... a little while.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: frame->unwind->this_base()

[Andrew Cagney]

> On Tue, Mar 18, 2003 at 09:54:29AM -0500, Andrew Cagney wrote:
> 
>> >
>> >So in this case should we be hooking the get_frame_base() call to
>> >return the computed DW_AT_frame_base?  [...]  And what happens if we don't 
>> >have DWARF-2
>> >information?
> 
>> 
>> At the start I wrote:
>> 
> 
>> > For dwarf2 frames, it would return, DW_AT_frame_base.  For prologue 
> 
>> frames, it would return an attempt at an equivalent value.  Hopefully it 
>> wouldn't be called for other frame types :-).
> 
> 
> OK.  I'll make the assumption that the DW_AT_frame_base and the CFA in
> the dwarf2 unwind information (if both present) will agree.

That would be a very bad assumption.  They are pratically guarenteed to 
be different.

Andrew

Re: frame->unwind->this_base()

[Daniel Jacobowitz]

On Tue, Mar 18, 2003 at 12:01:58PM -0500, Andrew Cagney wrote:
> >On Tue, Mar 18, 2003 at 09:54:29AM -0500, Andrew Cagney wrote:
> >
> >>>
> >>>So in this case should we be hooking the get_frame_base() call to
> >>>return the computed DW_AT_frame_base?  [...]  And what happens if we 
> >>don't >have DWARF-2
> >>>information?
> >
> >>
> >>At the start I wrote:
> >>
> >
> >>> For dwarf2 frames, it would return, DW_AT_frame_base.  For prologue 
> >
> >>frames, it would return an attempt at an equivalent value.  Hopefully it 
> >>wouldn't be called for other frame types :-).
> >
> >
> >OK.  I'll make the assumption that the DW_AT_frame_base and the CFA in
> >the dwarf2 unwind information (if both present) will agree.
> 
> That would be a very bad assumption.  They are pratically guarenteed to 
> be different.

Then what do you mean by a "dwarf2 frame"?  I'd assume you meant the
CFA, but it sounds like you mean a frame for which we have dwarf2
.debug_info.

Checking, I do see that they're different... Hum.  We need both
concepts obviously, and I need to reread this dwarf3 draft on my desk.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: frame->unwind->this_base()

[Andrew Cagney]

> That would be a very bad assumption.  They are pratically guarenteed to 
>> be different.
> 
> 
> Then what do you mean by a "dwarf2 frame"?  I'd assume you meant the
> CFA, but it sounds like you mean a frame for which we have dwarf2
> .debug_info.

A frame with debug info provided by dwarf2.  CFI gives the register 
info, location expressions give the variable info, ...

What started out as a simple cfi-frame looks like it might need to 
evolve into dwarf2-frame ...

Andrew

Re: frame->unwind->this_base()

[Daniel Jacobowitz]

On Tue, Mar 18, 2003 at 12:28:47PM -0500, Andrew Cagney wrote:
> >That would be a very bad assumption.  They are pratically guarenteed to 
> >>be different.
> >
> >
> >Then what do you mean by a "dwarf2 frame"?  I'd assume you meant the
> >CFA, but it sounds like you mean a frame for which we have dwarf2
> >.debug_info.
> 
> A frame with debug info provided by dwarf2.  CFI gives the register 
> info, location expressions give the variable info, ...
> 
> What started out as a simple cfi-frame looks like it might need to 
> evolve into dwarf2-frame ...

DWARF-2 debug info does not corelate with CFI info.  For instance, GCC
will generate DWARF-2 CFI with stabs debug info.  It will also generate
CFI with no debug info at all, or DWARF-2 info without any CFI (if
requested).

Can't lump 'em that way.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: frame->unwind->this_base()

[Andrew Cagney]

> On Tue, Mar 18, 2003 at 12:28:47PM -0500, Andrew Cagney wrote:
> 
>> >That would be a very bad assumption.  They are pratically guarenteed to 
> 
>> >>be different.
> 
>> >
>> >
>> >Then what do you mean by a "dwarf2 frame"?  I'd assume you meant the
>> >CFA, but it sounds like you mean a frame for which we have dwarf2
>> >.debug_info.
> 
>> 
>> A frame with debug info provided by dwarf2.  CFI gives the register 
>> info, location expressions give the variable info, ...
>> 
>> What started out as a simple cfi-frame looks like it might need to 
>> evolve into dwarf2-frame ...
> 
> 
> DWARF-2 debug info does not corelate with CFI info.  For instance, GCC
> will generate DWARF-2 CFI with stabs debug info.  It will also generate
> CFI with no debug info at all, or DWARF-2 info without any CFI (if
> requested).

True dwarf2 debug info or that .eh_frame stuff (i'm curious)?

For stabs to work, it needs FRAME_LOCALS_ADDRESS(); and 
FRAME_LOCALS_ADDRESS() relies on the prologue analyzer (since frame ID 
won't correspond to `frame-base') for the computation of the correct 
value; and that means unwinding the same frame two ways.  Outch.

Andrew

Re: frame->unwind->this_base()

[Daniel Jacobowitz]

On Tue, Mar 18, 2003 at 03:22:17PM -0500, Andrew Cagney wrote:
> >On Tue, Mar 18, 2003 at 12:28:47PM -0500, Andrew Cagney wrote:
> >
> >>>That would be a very bad assumption.  They are pratically guarenteed to 
> >
> >>>>be different.
> >
> >>>
> >>>
> >>>Then what do you mean by a "dwarf2 frame"?  I'd assume you meant the
> >>>CFA, but it sounds like you mean a frame for which we have dwarf2
> >>>.debug_info.
> >
> >>
> >>A frame with debug info provided by dwarf2.  CFI gives the register 
> >>info, location expressions give the variable info, ...
> >>
> >>What started out as a simple cfi-frame looks like it might need to 
> >>evolve into dwarf2-frame ...
> >
> >
> >DWARF-2 debug info does not corelate with CFI info.  For instance, GCC
> >will generate DWARF-2 CFI with stabs debug info.  It will also generate
> >CFI with no debug info at all, or DWARF-2 info without any CFI (if
> >requested).
> 
> True dwarf2 debug info or that .eh_frame stuff (i'm curious)?

Hmm, I thought it would write out .debug_frame without DWARF-2 but
peering at the GCC source I seem to be wrong again.  So just .eh_frame.

In any case, we'll parse both, so I stand by my statement.  We'll have
.eh_frame even without normal debug info.

> For stabs to work, it needs FRAME_LOCALS_ADDRESS(); and 
> FRAME_LOCALS_ADDRESS() relies on the prologue analyzer (since frame ID 
> won't correspond to `frame-base') for the computation of the correct 
> value; and that means unwinding the same frame two ways.  Outch.

Yeah...
 - if we have CFI use it to find the frame address.  Does this
become the frame ID?
 - if we have dwarf2 debug and CFI, then we don't need to do prologue
analysis; CFI should give us everything we need
 - if we have stabs debug and CFI, then we do need to do prologue
analysis to get FRAME_LOCALS_ADDRESS
 - if we have either kind of debug info and no CFI then we need to do
prologue analysis; for dwarf2 we'll also need to calculate the frame
base from DW_AT_frame_base in order to use it to find locals

Is that about right?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: frame->unwind->this_base()

[Andrew Cagney]

>> True dwarf2 debug info or that .eh_frame stuff (i'm curious)?
> 
> 
> Hmm, I thought it would write out .debug_frame without DWARF-2 but
> peering at the GCC source I seem to be wrong again.  So just .eh_frame.

So using .eh_frame is along the same lines as using ia64's libunwind. 
.eh_frame just happens to be implemented using something very like 
dwarf2's unwind code.

> In any case, we'll parse both, so I stand by my statement.  We'll have
> .eh_frame even without normal debug info.

I think there needs to be separate eh-frame and cfi-frame but with a 
common implementation.  That way the subtle, but important, differences 
are clear.

>> For stabs to work, it needs FRAME_LOCALS_ADDRESS(); and 
>> FRAME_LOCALS_ADDRESS() relies on the prologue analyzer (since frame ID 
>> won't correspond to `frame-base') for the computation of the correct 
>> value; and that means unwinding the same frame two ways.  Outch.
> 
> 
> Yeah...
>  - if we have CFI use it to find the frame address.  Does this
> become the frame ID?
>  - if we have dwarf2 debug and CFI, then we don't need to do prologue
> analysis; CFI should give us everything we need
>  - if we have stabs debug and CFI, then we do need to do prologue
> analysis to get FRAME_LOCALS_ADDRESS
>  - if we have either kind of debug info and no CFI then we need to do
> prologue analysis; for dwarf2 we'll also need to calculate the frame
> base from DW_AT_frame_base in order to use it to find locals
> 
> Is that about right?

Yes.  Try the following higher-level view of the problem:

On the left is the unwinder.  It exports methods to obtain the frame's 
ID and the registers.  It can be implemented using CFA, EH, libunwind, 
prologue analysis, ...; and the implementation is selected based on the 
low-level unwind information, or lack there of.

On the right is the local variable code and that needs a frame-base / 
frame-locals-address / ....  It uses high-level debug info and unwound 
register values to compute that base.  It can be implemented using 
dwarf2's frame_base, or prologue analysis (stabs), or ...; and the 
implementation is selected based on the frame's high-level debug info.

The mess occures when the high-level RHS frame-locals-address starts 
assuming the flavour of the low-level LHS unwinder and, consequently, 
tries to directly exploit that knowledge.  For instance, a RHS prologue 
based frame-locals-address assuming that the LHS is also prologue based, 
and hence, can directly access the LHS's prologue analysis cache.

It can be `fixed' two ways:

- refusing to allow that sharing of data, forcing the RHS 
frame-locals-address to re-analyze the prologue.

- make it possible to tease out the prologue analysis object so that 
both the LHS and RHS can share it.

I guess the second is it.

Andrew

Re: frame->unwind->this_base()

[Daniel Jacobowitz]

On Wed, Mar 19, 2003 at 10:24:37AM -0500, Andrew Cagney wrote:
> 
> >>True dwarf2 debug info or that .eh_frame stuff (i'm curious)?
> >
> >
> >Hmm, I thought it would write out .debug_frame without DWARF-2 but
> >peering at the GCC source I seem to be wrong again.  So just .eh_frame.
> 
> So using .eh_frame is along the same lines as using ia64's libunwind. 
> .eh_frame just happens to be implemented using something very like 
> dwarf2's unwind code.
> 
> >In any case, we'll parse both, so I stand by my statement.  We'll have
> >.eh_frame even without normal debug info.
> 
> I think there needs to be separate eh-frame and cfi-frame but with a 
> common implementation.  That way the subtle, but important, differences 
> are clear.

What's your perception of the difference?  Just based on the different
on-disk format?  The information contained is essentially the same.  I
certainly don't object, though.  This will be painless.

> >>For stabs to work, it needs FRAME_LOCALS_ADDRESS(); and 
> >>FRAME_LOCALS_ADDRESS() relies on the prologue analyzer (since frame ID 
> >>won't correspond to `frame-base') for the computation of the correct 
> >>value; and that means unwinding the same frame two ways.  Outch.
> >
> >
> >Yeah...
> > - if we have CFI use it to find the frame address.  Does this
> >become the frame ID?
> > - if we have dwarf2 debug and CFI, then we don't need to do prologue
> >analysis; CFI should give us everything we need
> > - if we have stabs debug and CFI, then we do need to do prologue
> >analysis to get FRAME_LOCALS_ADDRESS
> > - if we have either kind of debug info and no CFI then we need to do
> >prologue analysis; for dwarf2 we'll also need to calculate the frame
> >base from DW_AT_frame_base in order to use it to find locals
> >
> >Is that about right?
> 
> Yes.  Try the following higher-level view of the problem:
> 
> On the left is the unwinder.  It exports methods to obtain the frame's 
> ID and the registers.  It can be implemented using CFA, EH, libunwind, 
> prologue analysis, ...; and the implementation is selected based on the 
> low-level unwind information, or lack there of.
> 
> On the right is the local variable code and that needs a frame-base / 
> frame-locals-address / ....  It uses high-level debug info and unwound 
> register values to compute that base.  It can be implemented using 
> dwarf2's frame_base, or prologue analysis (stabs), or ...; and the 
> implementation is selected based on the frame's high-level debug info.
> 
> The mess occures when the high-level RHS frame-locals-address starts 
> assuming the flavour of the low-level LHS unwinder and, consequently, 
> tries to directly exploit that knowledge.  For instance, a RHS prologue 
> based frame-locals-address assuming that the LHS is also prologue based, 
> and hence, can directly access the LHS's prologue analysis cache.
> 
> It can be `fixed' two ways:
> 
> - refusing to allow that sharing of data, forcing the RHS 
> frame-locals-address to re-analyze the prologue.
> 
> - make it possible to tease out the prologue analysis object so that 
> both the LHS and RHS can share it.
> 
> I guess the second is it.

I agree.  Personally, what I would like would be to generate something
structurally/conceptually equivalent to the unwind data from the
prologue reader.  This requires a bit of rewriting and a great deal of
testing/patience.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer