list/edit command on frame with available symtab

list/edit command on frame with available symtab

[Jason Kraftcheck]

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.


diff -upr gdb-6.4/gdb/stack.c mod/gdb/stack.c
--- gdb-6.4/gdb/stack.c	2005-08-18 08:26:41.000000000 -0500
+++ mod/gdb/stack.c	2006-02-23 11:55:12.481291546 -0600
@@ -377,8 +377,18 @@ static void
 set_current_sal_from_frame (struct frame_info *frame, int center)
 {
   struct symtab_and_line sal;
+  int count;

   find_frame_sal (frame, &sal);
+  while (!sal.symtab)
+    {
+      count = 1;
+      frame = find_relative_frame( frame, &count );
+      if (count)
+        break;
+      find_frame_sal (frame, &sal);
+    }
+
   if (sal.symtab)
     {
       if (center)

Re: list/edit command on frame with available symtab

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
CodeSourcery

Re: list/edit command on frame with available symtab

[Jason Kraftcheck]

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

Re: list/edit command on frame with available symtab

[Michael Snyder]

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?

Re: list/edit command on frame with available symtab

[Daniel Jacobowitz]

On Wed, Mar 01, 2006 at 02:35:42PM -0800, Michael Snyder wrote:
> >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?

OK, I see what's going on.  Run gdb on coremaker from the GDB
testsuite.  Just load it and type run, then "list"; you'll get main.
Or, list 1, run, list; you'll get line 11.

Here's a slightly nicer patch to do the same thing.  I'm not going to
apply this right now, though, because it makes me a little nervous;
it means that we try to use the unwinder automatically if there is no
debug information, which could lead to e.g. error() complaining about a
corrupt stack, or CFI warnings.

Thoughts?  Is this useful?

2006-03-30  Daniel Jacobowitz  <dan@codesourcery.com>

	* stack.c (set_current_sal_from_frame): Unwind to earlier frames if
	necessary.

Index: stack.c
===================================================================
RCS file: /cvs/src/src/gdb/stack.c,v
retrieving revision 1.137
diff -u -p -r1.137 stack.c
--- stack.c	17 Dec 2005 22:34:03 -0000	1.137
+++ stack.c	30 Mar 2006 16:13:10 -0000
@@ -370,7 +370,8 @@ print_args_stub (void *args)
 }
 
 /* Set the current source and line to the location given by frame
-   FRAME, if possible.  When CENTER is true, adjust so the relevant
+   FRAME, if possible, or the first frame outer of FRAME with line
+   information.  When CENTER is true, adjust so the relevant
    line is in the center of the next 'list'.  */
 
 static void
@@ -378,7 +379,15 @@ set_current_sal_from_frame (struct frame
 {
   struct symtab_and_line sal;
 
-  find_frame_sal (frame, &sal);
+  do
+    {
+      find_frame_sal (frame, &sal);
+      if (sal.symtab)
+	break;
+      frame = get_prev_frame (frame);
+    }
+  while (frame);
+
   if (sal.symtab)
     {
       if (center)


-- 
Daniel Jacobowitz
CodeSourcery