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: Maxim Grigoriev <maxim at tensilica dot com>
- Cc: Jim Blandy <jimb at codesourcery dot com>, gdb at sourceware dot org, Marc Gauthier <marc at tensilica dot com>, Pete MacLiesh <pmac at tensilica dot com>, Ross Morley <ross at tensilica dot com>
- Date: Wed, 23 May 2007 08:19:41 +1200
- Subject: Re: Understanding GDB frames
- References: <46521C04.7040405@hq.tensilica.com> <m3y7jgbt7j.fsf@codesourcery.com> <465341B8.9060208@hq.tensilica.com>
Maxim Grigoriev writes:
> > It's worth pointing out that the 'PC' in a frame ID isn't the current
> > PC within the function. It's always the PC of the function's entry
> > point, so that stepping within a function doesn't cause the frame ID
> > to change. Usually it's a PC value returned by 'frame_func_unwind',
> > which takes care of calling get_pc_function_start for you.
>
> We've been using a function return address instead of
> the PC of the function's entry, and it works just fine.
But does this explain why xt-gdb didn't detect the variable objects coming back
into scope when an i386 gdb did?
> The good part of our approach is it allowed to expose some
> problems with MI variable objects :-)
Actually I think we've discussed this behaviour before and done nothing about
it.
--
Nick http://www.inet.net.nz/~nickrob