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

[Daniel Jacobowitz <drow@false.org>]

On Thu, Apr 24, 2008 at 11:23:08AM +1200, Nick Roberts wrote:
> 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.

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.

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.

-- 
Daniel Jacobowitz
CodeSourcery