Re: [PATCH] -stack-info-frame/-stack-list-frames

[Nick Roberts <nickrob@snap.net.nz>]

 > > Well you understand the internals much better than I do, but whenever I've
 > > looked at the frame addresses on i386 they've appeared meaningful.  Are
 > > "stackless recursive functions" special to IA-64 or a consequence of
 > > optimisation?  If the values are meaningful "most of the time" then I think
 > > it's OK to have this field, if not then I guess it might just confuse.
 > 
 > It's an IA-64 thing.  This is the original reason that frame IDs had a
 > third member, the "special address" field.

So it's really an exceptional case rather than the rule.

 > I've actually got patches to add several more items to the frame ID.
 > I hope I'll be submitting them soon.  That's inlined function support,
 > where the stack address really becomes not useful to identify the
 > scope.

Maybe Gdb could somehow identify the cases where the address isn't useful.

 > On Thu, Apr 24, 2008 at 12:40:12PM +1200, Nick Roberts wrote:
 > > Actually it just needs to be a non-zero value for frames in which a varobj
 > > is created.  Perhaps a member of struct frame_id, int varobj_frame say,
 > > which increments when a varobj is created in a new frame.  This could also
 > > then be used to see if a varobj has gone out of scope to avoid the
 > > ambiguities Jim Blandy talked about from using frame_find_by_id.
 > > 
 > > Perhaps this is what you are suggesting, anyway.
 > 
 > Right, this is basically what I had in mind.  It may not solve the
 > going out of scope bit, because we don't usually backtrace all the
 > way up - and how do we avoid having to save an unbounded number of
 > these things so we can map them, so maybe a hash is better than
 > a counter.  I haven't thought about the details yet.

I don't think the number need be that unbounded, it's not needed for each
frame, only those in which a varobj is created.  But it appears that the
linked list of frames gets destroyed and recreated each time execution
occurs, in which case any id information is also lost (I was looking at
using an extra member in struct frame_info).

-- 
Nick                                           http://www.inet.net.nz/~nickrob