This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: list/edit command on frame with available symtab


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").


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]