This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Understanding GDB frames
- From: Ross Morley <ross at tensilica dot com>
- To: Marc Gauthier <marc at tensilica dot com>
- Cc: Daniel Jacobowitz <drow at false dot org>, Nick Roberts <nickrob at snap dot net dot nz>, Maxim Grigoriev <maxim at tensilica dot com>, gdb at sourceware dot org, Pete MacLiesh <pmac at tensilica dot com>
- Date: Tue, 22 May 2007 10:20:02 -0700
- Subject: Re: Understanding GDB frames
- References: <KAEOLFIOAJBBAFKHIDEAMENFEEAA.marc@tensilica.com>
Marc Gauthier wrote:
Ross Morley wrote:
Associating them with the function has problems with recursion.
It seems to
me the ideal is to recreate vars that have gone out of scope (they really
are new vars). Use of a scope breakpoint can better detect that than the
current methods. However, are there implementation or performance issues?
As we discussed offline yesterday, this has performance implications
on the GUI, which would have to recreate the varobjs every time which
is time consuming.
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).
I believe the performance implication comes mainly from the MI client
having to recreate the MI vars, not so much from the scope breakpoint.
If I recall correctly, the scope breakpoint would disappear the first
time the var went out of scope, and would not exist subsequent times
until the target stops and is resumed again (however it's been a while
since I looked at scope breakpoints).
Ross