This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: backtrace changes current source location
On Fri, Oct 29, 2004 at 11:20:53AM -0400, Andrew Cagney wrote:
> Hmm, things have changed.
>
> Felix Lee wrote:
> >Andrew Cagney <cagney@gnu.org>:
> >
> >>(Don't forget to consider the error case - if an error is thrown a
> >>restore would be lost)
> >
> >
> >is it worth setting up an unwind handler for that? I couldn't
> >think of a case where an error would be usual, and for unusual
> >errors, all bets are off.
>
> As a debugger, we're no longer going to gamble with the user interface -
> even when there's an error the behavior should be well defined.
>
> Can you find out why selected sal is being corrupted, code shouldn't be
> modifying it.
I wrote:
On Wed, Oct 27, 2004 at 01:34:09PM -0400, Andrew Cagney wrote:
> Felix Lee wrote:
> >patch for
> > http://sources.redhat.com/ml/gdb/2004-10/msg00414.html
> >
> >gdb/ChangeLog
> >2004-10-26 Felix Lee <felix+log1@specifixinc.com>
> >
> > * stack.c (backtrace_command_1): Backtrace shouldn't
> > change current source location.
>
> Felix, can you find out where current_sal is being trashed? GDB's
> trying to get away from all this global state - the code at that level
> shouldn't need to meddle with current_sal.
If you follow the link in his message above, Keith introduced it in
2002 - print_frame_info_base.
Does that answer your question?
--
Daniel Jacobowitz