Re: list/edit command on frame with available symtab

[Michael Snyder <msnyder@redhat.com>]

Jason Kraftcheck wrote:
> Daniel Jacobowitz wrote:
> 
>>On Thu, Feb 23, 2006 at 12:40:11PM -0600, Jason Kraftcheck wrote:
>>
>>
>>>If there is no symtab for the current frame, traverse up the stack
>>>looking for a frame with a symtab.  This may at first seem like a
>>>gratuitous feature (and perhaps it is), but I find it is convenient when
>>>working with an application that uses third-party libraries.  Typically
>>>whatever code I'm working on has debug symbols while whatever
>>>third-party code I'm calling does not.  And I'm much more interested in
>>>seeing where the process was in my code at the time a fault occurred.  I
>>>don't think this change will be a problem for anyone, as the previous
>>>behavior was to print an error if there was no symtab.
>>>
>>>
>>>2006-02-23  Jason Kraftcheck  <kraftche@cae.wisc.edu>
>>>
>>>	* stack.c (set_current_sal_from_frame): If list or edit command
>>>       is invoked for a frame without a symtab, move up the stack to
>>>       the neareast frame with a symtab.
>>
>>
>>I'm not sure this is a good idea, but in any case, is that really
>>what's going on? I already get successful "list", and edit opens a file
>>named "unknown", if the parent frame has line info.
>>
> 
> 
> With this patch, I get what I expect.  Without this patch, stopping due
> to a sigabrt, edit and list both show whatever was the previous valid
> sal, which is probably a bug.  After moving up or down a frame, they
> both report an error (in the edit case, editing a file called "unknown").

I've never tried it with edit, and I haven't tried it recently
with list, but my recollection is in line with Daniel's comment --
afaik, it already works, at least for list.  With what version
and configuration of gdb do you find it to be broken?