Re: backtrace changes current source location

[Daniel Jacobowitz <drow at false dot org>]

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