This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] -stack-info-frame/-stack-list-frames
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
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.