* frame->unwind->this_base() @ 2003-03-16 22:04 Andrew Cagney 2003-03-16 22:10 ` frame->unwind->this_base() Daniel Jacobowitz 0 siblings, 1 reply; 22+ messages in thread From: Andrew Cagney @ 2003-03-16 22:04 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-16 22:04 frame->unwind->this_base() Andrew Cagney @ 2003-03-16 22:10 ` Daniel Jacobowitz 2003-03-17 0:09 ` frame->unwind->this_base() Andrew Cagney 0 siblings, 1 reply; 22+ messages in thread From: Daniel Jacobowitz @ 2003-03-16 22:10 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-16 22:10 ` frame->unwind->this_base() Daniel Jacobowitz @ 2003-03-17 0:09 ` Andrew Cagney 2003-03-17 0:14 ` frame->unwind->this_base() Daniel Jacobowitz 0 siblings, 1 reply; 22+ messages in thread From: Andrew Cagney @ 2003-03-17 0:09 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-17 0:09 ` frame->unwind->this_base() Andrew Cagney @ 2003-03-17 0:14 ` Daniel Jacobowitz 2003-03-17 16:22 ` frame->unwind->this_base() Andrew Cagney 0 siblings, 1 reply; 22+ messages in thread From: Daniel Jacobowitz @ 2003-03-17 0:14 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-17 0:14 ` frame->unwind->this_base() Daniel Jacobowitz @ 2003-03-17 16:22 ` Andrew Cagney 2003-03-17 16:38 ` frame->unwind->this_base() Daniel Jacobowitz 0 siblings, 1 reply; 22+ messages in thread From: Andrew Cagney @ 2003-03-17 16:22 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb >> 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-17 16:22 ` frame->unwind->this_base() Andrew Cagney @ 2003-03-17 16:38 ` Daniel Jacobowitz 2003-03-17 16:56 ` frame->unwind->this_base() Andrew Cagney 0 siblings, 1 reply; 22+ messages in thread From: Daniel Jacobowitz @ 2003-03-17 16:38 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-17 16:38 ` frame->unwind->this_base() Daniel Jacobowitz @ 2003-03-17 16:56 ` Andrew Cagney 2003-03-17 17:11 ` frame->unwind->this_base() Daniel Jacobowitz 0 siblings, 1 reply; 22+ messages in thread From: Andrew Cagney @ 2003-03-17 16:56 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-17 16:56 ` frame->unwind->this_base() Andrew Cagney @ 2003-03-17 17:11 ` Daniel Jacobowitz 2003-03-17 18:20 ` frame->unwind->this_base() Andrew Cagney 0 siblings, 1 reply; 22+ messages in thread From: Daniel Jacobowitz @ 2003-03-17 17:11 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-17 17:11 ` frame->unwind->this_base() Daniel Jacobowitz @ 2003-03-17 18:20 ` Andrew Cagney 2003-03-17 19:35 ` frame->unwind->this_base() Daniel Jacobowitz 0 siblings, 1 reply; 22+ messages in thread From: Andrew Cagney @ 2003-03-17 18:20 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb >> >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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-17 18:20 ` frame->unwind->this_base() Andrew Cagney @ 2003-03-17 19:35 ` Daniel Jacobowitz 2003-03-18 4:29 ` frame->unwind->this_base() Andrew Cagney 0 siblings, 1 reply; 22+ messages in thread From: Daniel Jacobowitz @ 2003-03-17 19:35 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-17 19:35 ` frame->unwind->this_base() Daniel Jacobowitz @ 2003-03-18 4:29 ` Andrew Cagney 2003-03-18 5:13 ` frame->unwind->this_base() Daniel Jacobowitz 0 siblings, 1 reply; 22+ messages in thread From: Andrew Cagney @ 2003-03-18 4:29 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-18 4:29 ` frame->unwind->this_base() Andrew Cagney @ 2003-03-18 5:13 ` Daniel Jacobowitz 2003-03-18 15:22 ` frame->unwind->this_base() Andrew Cagney 0 siblings, 1 reply; 22+ messages in thread From: Daniel Jacobowitz @ 2003-03-18 5:13 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-18 5:13 ` frame->unwind->this_base() Daniel Jacobowitz @ 2003-03-18 15:22 ` Andrew Cagney 2003-03-18 16:38 ` frame->unwind->this_base() Daniel Jacobowitz 0 siblings, 1 reply; 22+ messages in thread From: Andrew Cagney @ 2003-03-18 15:22 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-18 15:22 ` frame->unwind->this_base() Andrew Cagney @ 2003-03-18 16:38 ` Daniel Jacobowitz 2003-03-18 17:02 ` frame->unwind->this_base() Andrew Cagney 0 siblings, 1 reply; 22+ messages in thread From: Daniel Jacobowitz @ 2003-03-18 16:38 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-18 16:38 ` frame->unwind->this_base() Daniel Jacobowitz @ 2003-03-18 17:02 ` Andrew Cagney 2003-03-18 17:11 ` frame->unwind->this_base() Daniel Jacobowitz 0 siblings, 1 reply; 22+ messages in thread From: Andrew Cagney @ 2003-03-18 17:02 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-18 17:02 ` frame->unwind->this_base() Andrew Cagney @ 2003-03-18 17:11 ` Daniel Jacobowitz 2003-03-18 17:28 ` frame->unwind->this_base() Andrew Cagney 0 siblings, 1 reply; 22+ messages in thread From: Daniel Jacobowitz @ 2003-03-18 17:11 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-18 17:11 ` frame->unwind->this_base() Daniel Jacobowitz @ 2003-03-18 17:28 ` Andrew Cagney 2003-03-18 17:38 ` frame->unwind->this_base() Daniel Jacobowitz 0 siblings, 1 reply; 22+ messages in thread From: Andrew Cagney @ 2003-03-18 17:28 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-18 17:28 ` frame->unwind->this_base() Andrew Cagney @ 2003-03-18 17:38 ` Daniel Jacobowitz 2003-03-18 20:22 ` frame->unwind->this_base() Andrew Cagney 0 siblings, 1 reply; 22+ messages in thread From: Daniel Jacobowitz @ 2003-03-18 17:38 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-18 17:38 ` frame->unwind->this_base() Daniel Jacobowitz @ 2003-03-18 20:22 ` Andrew Cagney 2003-03-19 14:11 ` frame->unwind->this_base() Daniel Jacobowitz 0 siblings, 1 reply; 22+ messages in thread From: Andrew Cagney @ 2003-03-18 20:22 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-18 20:22 ` frame->unwind->this_base() Andrew Cagney @ 2003-03-19 14:11 ` Daniel Jacobowitz 2003-03-19 15:24 ` frame->unwind->this_base() Andrew Cagney 0 siblings, 1 reply; 22+ messages in thread From: Daniel Jacobowitz @ 2003-03-19 14:11 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-19 14:11 ` frame->unwind->this_base() Daniel Jacobowitz @ 2003-03-19 15:24 ` Andrew Cagney 2003-03-19 15:32 ` frame->unwind->this_base() Daniel Jacobowitz 0 siblings, 1 reply; 22+ messages in thread From: Andrew Cagney @ 2003-03-19 15:24 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb >> 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: frame->unwind->this_base() 2003-03-19 15:24 ` frame->unwind->this_base() Andrew Cagney @ 2003-03-19 15:32 ` Daniel Jacobowitz 0 siblings, 0 replies; 22+ messages in thread From: Daniel Jacobowitz @ 2003-03-19 15:32 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2003-03-19 15:32 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-03-16 22:04 frame->unwind->this_base() Andrew Cagney 2003-03-16 22:10 ` frame->unwind->this_base() Daniel Jacobowitz 2003-03-17 0:09 ` frame->unwind->this_base() Andrew Cagney 2003-03-17 0:14 ` frame->unwind->this_base() Daniel Jacobowitz 2003-03-17 16:22 ` frame->unwind->this_base() Andrew Cagney 2003-03-17 16:38 ` frame->unwind->this_base() Daniel Jacobowitz 2003-03-17 16:56 ` frame->unwind->this_base() Andrew Cagney 2003-03-17 17:11 ` frame->unwind->this_base() Daniel Jacobowitz 2003-03-17 18:20 ` frame->unwind->this_base() Andrew Cagney 2003-03-17 19:35 ` frame->unwind->this_base() Daniel Jacobowitz 2003-03-18 4:29 ` frame->unwind->this_base() Andrew Cagney 2003-03-18 5:13 ` frame->unwind->this_base() Daniel Jacobowitz 2003-03-18 15:22 ` frame->unwind->this_base() Andrew Cagney 2003-03-18 16:38 ` frame->unwind->this_base() Daniel Jacobowitz 2003-03-18 17:02 ` frame->unwind->this_base() Andrew Cagney 2003-03-18 17:11 ` frame->unwind->this_base() Daniel Jacobowitz 2003-03-18 17:28 ` frame->unwind->this_base() Andrew Cagney 2003-03-18 17:38 ` frame->unwind->this_base() Daniel Jacobowitz 2003-03-18 20:22 ` frame->unwind->this_base() Andrew Cagney 2003-03-19 14:11 ` frame->unwind->this_base() Daniel Jacobowitz 2003-03-19 15:24 ` frame->unwind->this_base() Andrew Cagney 2003-03-19 15:32 ` frame->unwind->this_base() Daniel Jacobowitz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).