This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: Understanding GDB frames
- From: Nick Roberts <nickrob at snap dot net dot nz>
- To: "Marc Gauthier" <marc at tensilica dot com>
- Cc: "Ross Morley" <ross at tensilica dot com>, "Daniel Jacobowitz" <drow at false dot org>, "Maxim Grigoriev" <maxim at tensilica dot com>, <gdb at sourceware dot org>, "Pete MacLiesh" <pmac at tensilica dot com>
- Date: Wed, 23 May 2007 08:15:47 +1200
- Subject: RE: Understanding GDB frames
- References: <4652AC74.9050100@tensilica.com> <KAEOLFIOAJBBAFKHIDEAMENFEEAA.marc@tensilica.com>
> It seems at the MI interface one wants a choice of whether a varobj
> is associated with:
> (a) a specific frame (goes away when function returns)
> (b) a function
> (c) a function at the same depth (which some implement)
GDB already does something like (b) if you use:
-var-create - @ myvar
although it's not documented. I think this can specifically be used in the
case of recursion
> How the distinction is made at the GUI level is a separate question.
> And what to do in the event of recursion when one selected a
> function-level varobj (b) is also an interesting question -- perhaps
> it always refers to the topmost instance (or to theseparately selected
> instance if the currently selected stack depth is to that function).
>
> That way, (b) and (c) have less performance impact, and one of them
> could be the default. And (a) being optional, could be fully supported
> like watchpoints by setting a breakpoint at the return PC, even though
> it has a performance hit (especially in the presence of recursion).
>
> And perhaps MI docs could even document this ;-)
If you want this functionality in GDB then I think you will have to contribute
it.
--
Nick http://www.inet.net.nz/~nickrob