This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: list/edit command on frame with available symtab
- From: Jason Kraftcheck <kraftche at cae dot wisc dot edu>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 23 Feb 2006 15:12:54 -0600
- Subject: Re: list/edit command on frame with available symtab
- References: <43FE018B.2050502@cae.wisc.edu> <20060223210007.GB2353@nevyn.them.org>
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").