GDB/MI absolute path

GDB/MI absolute path

[Bob Rossi]

Hello,

I've asked this question twice on the gdb mailing list, and received no
response.  Does anyone know the answer?

I am tring to successfully get positive information out of GDB/MI.

Should I be using gdb-5.3 or the latest cvs? They act different.

Also, what is the best way to ask mi for the absolute path to the
current source file. This wasn't a problem using annotate 1 or 2, and I
can't figure out how to get it using mi.

I used to just do this:
(gdb) list test.c:1,1
1  #include <stdio.h>
(gdb) info source
Current source file is test.c
Compilation directory is /home/bob/cvs/gdb/gdb/
Located in /home/bob/cvs/gdb/gdb/test.c
Contains 9 lines.
Source language is c.
Compiled with stabs debugging format.
(gdb)

But with mi I get this:
(gdb)
list test.c:1,1
&"list test.c:1,1\n"
^done,line="1",file="test.c"
(gdb)
info source
&"info source\n"
~"Current source file is test.c\n"
~"Compilation directory is /home/bob/cvs/gdb/gdb/\n"
~"Source language is c.\n"
~"Compiled with stabs debugging format.\n"
~"Does not include preprocessor macro info.\n"
^done
(gdb)

GDB/MI does not have the 'Located in' section. Is this done on purpose?
I am looking at gdb/mi/mi-cmds.c for a command that would be helpfull
but I don't see any.

Thanks,
Bobby

Re: GDB/MI absolute path

[Keith Seitz]

On Thu, 2003-02-06 at 13:55, Bob Rossi wrote:
> Also, what is the best way to ask mi for the absolute path to the
> current source file. This wasn't a problem using annotate 1 or 2, and I
> can't figure out how to get it using mi.

This is a known (to me) problem with MI. The problem is that MI was
desinged to work with an IDE, not just a standalone GUI for the
debugger. In the case of an IDE, this information isn't needed, since
the IDE knows everything there is to know about files.

However, like Insight, cgdb will need some way of turning
"../foo/bar/baz.c" into "/home/a/b/c/foo/bar/baz.c". There are two
options (excluding hacks around the problem):

1. Get the complete source search path from GDB and let the GUI search
for the file. This means the GUI writer would also need the compile
directory for each file.

2. Get gdb to tell you where it thinks a file is located.

Of course, I think we'll all agree that #2 is preferred. This is the
route we took in Insight (see
gdbtk/generic/gdbtk-cmds.c:gdb_find_file_command).

Phew! After saying all that, the real response to your question is:
"It's a bug: open a new bug report." :-(

Keith

Re: GDB/MI absolute path

[Bob Rossi]

Thanks for the great answer.

On Thu, Feb 06, 2003 at 02:17:30PM -0800, Keith Seitz wrote:
> On Thu, 2003-02-06 at 13:55, Bob Rossi wrote:
> > Also, what is the best way to ask mi for the absolute path to the
> > current source file. This wasn't a problem using annotate 1 or 2, and I
> > can't figure out how to get it using mi.
> 
> This is a known (to me) problem with MI. The problem is that MI was
> designed to work with an IDE, not just a stand-alone GUI for the
> debugger. In the case of an IDE, this information isn't needed, since
> the IDE knows everything there is to know about files.
> 
> However, like Insight, cgdb will need some way of turning
> "../foo/bar/baz.c" into "/home/a/b/c/foo/bar/baz.c". There are two
> options (excluding hacks around the problem):
> 
> 1. Get the complete source search path from GDB and let the GUI search
> for the file. This means the GUI writer would also need the compile
> directory for each file.
> 
> 2. Get GDB to tell you where it thinks a file is located.

I would like to write a patch to GDB/MI and send it in with a bug
report. Does any of the GDB/MI maintainers know if the current design
model of GDB/MI would prefer an implicit return of the current 
absolute path ( like annotations ) or an explicit return ( the GUI 
requests it every time via a new GDB/MI command).

Thanks
Bobby

Re: GDB/MI absolute path

[Jim Ingham]

[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]

Bob,

We actually found that even when run from a GUI, you need absolute 
paths for files sometimes.  The reason for this is that the user may 
have several projects, say one which builds a shared library, and one 
an app that uses it.  If debugging with the app project open, but not 
the shlib project, you can end up in  a frame with debug info referring 
to sources you don't know about.

For our purposes, we found it sufficient to add the dir path to the 
-stack-list-frames command.  Pretty much the only time we would not 
know where a file was was when gdb stopped, and we were fetching the 
stack.  You might also want it in the mi -break-insert command as well, 
if you want to map from breakpoints to files in you UI, dunno...

Anyway, we did this by adding a "frame_more_info" hook to the ordinary 
stack.c frame printing.  We haven't needed to add anything but the 
directory yet, but this does seem a place where more info might be 
useful in the future, so...

Anyway, if you are interested, here is a patch against the FSF TOT.  
It's hacked out of our sources - we haven't merged back from the 
interpreter branch yet, so there are a lot of differences between our 
sources & the FSF.  But this is pretty simple, and should work.


[-- Attachment #2: mi-more-stack.diff --]
[-- Type: application/octet-stream, Size: 4812 bytes --]

Index: defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.112
diff -c -w -p -r1.112 defs.h
*** defs.h	4 Feb 2003 18:07:00 -0000	1.112
--- defs.h	7 Feb 2003 17:52:51 -0000
*************** extern void (*show_load_progress) (const
*** 1166,1171 ****
--- 1166,1174 ----
  extern void (*print_frame_info_listing_hook) (struct symtab * s,
  					      int line, int stopline,
  					      int noerror);
+ extern void (*print_frame_more_info_hook) (struct ui_out *uiout,
+ 					    struct symtab_and_line *sal,
+ 					    struct frame_info *fi);
  extern struct frame_info *parse_frame_specification (char *frame_exp);
  extern int (*query_hook) (const char *, va_list);
  extern void (*warning_hook) (const char *, va_list);
Index: stack.c
===================================================================
RCS file: /cvs/src/src/gdb/stack.c,v
retrieving revision 1.65
diff -c -w -p -r1.65 stack.c
*** stack.c	2 Feb 2003 18:30:56 -0000	1.65
--- stack.c	7 Feb 2003 17:52:51 -0000
*************** print_frame (struct frame_info *fi, 
*** 452,457 ****
--- 452,460 ----
        annotate_frame_source_end ();
      }
  
+   if (print_frame_more_info_hook)
+     print_frame_more_info_hook (uiout, &sal, fi);
+ 
  #ifdef PC_SOLIB
    if (!funname || (!sal.symtab || !sal.symtab->filename))
      {
Index: top.c
===================================================================
RCS file: /cvs/src/src/gdb/top.c,v
retrieving revision 1.71
diff -c -w -p -r1.71 top.c
*** top.c	6 Feb 2003 01:19:12 -0000	1.71
--- top.c	7 Feb 2003 17:52:52 -0000
*************** void (*command_loop_hook) (void);
*** 206,211 ****
--- 206,216 ----
  
  void (*print_frame_info_listing_hook) (struct symtab * s, int line,
  				       int stopline, int noerror);
+ 
+ void (*print_frame_more_info_hook) (struct ui_out *uiout, 
+                                     struct symtab_and_line *sal,  
+                                     struct frame_info *fi); 
+                                      
  /* Replaces most of query.  */
  
  int (*query_hook) (const char *, va_list);
Index: mi/mi-cmd-stack.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmd-stack.c,v
retrieving revision 1.13
diff -c -w -p -r1.13 mi-cmd-stack.c
*** mi/mi-cmd-stack.c	29 Nov 2002 19:15:16 -0000	1.13
--- mi/mi-cmd-stack.c	7 Feb 2003 17:52:52 -0000
***************
*** 32,37 ****
--- 32,44 ----
     we pull the plug on the sanitization. */
  extern void select_frame_command_wrapper (char *, int);
  
+ /* Use this to print any extra info in the stack listing output that is
+    not in the standard gdb printing */
+ 
+ void mi_print_frame_more_info (struct ui_out *uiout,
+ 				struct symtab_and_line *sal,
+ 				struct frame_info *fi);
+ 
  static void list_args_or_locals (int locals, int values, struct frame_info *fi);
  
  /* Print a list of the stack frames. Args can be none, in which case
*************** mi_cmd_stack_list_frames (char *command,
*** 101,106 ****
--- 108,127 ----
      error ("mi_cmd_stack_list_frames: Not enough frames in stack.");
  
    return MI_CMD_DONE;
+ }
+ 
+ void 
+ mi_print_frame_more_info (struct ui_out *uiout,
+ 				struct symtab_and_line *sal,
+ 				struct frame_info *fi)
+ {
+   /* I would feel happier if we used ui_out_field_skip for all the fields
+      that we don't know how to set (like the file if we don't have symbols)
+      but the rest of print_frame just omits the fields if they are not known,
+      so I will do the same here...  */
+ 
+   if (sal && sal->symtab && sal->symtab->dirname)
+     ui_out_field_string (uiout, "dir", sal->symtab->dirname);
  }
  
  enum mi_cmd_result
Index: mi/mi-interp.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-interp.c,v
retrieving revision 1.2
diff -c -w -p -r1.2 mi-interp.c
*** mi/mi-interp.c	6 Feb 2003 05:30:17 -0000	1.2
--- mi/mi-interp.c	7 Feb 2003 17:52:52 -0000
*************** static int mi_interp_query_hook (const c
*** 60,65 ****
--- 60,70 ----
  static char *mi_interp_read_one_line_hook (char *prompt, int repeat,
  					   char *anno);
  
+ /* There should be a generic mi .h file where these should go... */
+ extern void mi_print_frame_more_info (struct ui_out *uiout,
+ 				       struct symtab_and_line *sal,
+ 				       struct frame_info *fi);
+ 
  static void mi2_command_loop (void);
  static void mi1_command_loop (void);
  
*************** mi_interpreter_resume (void *data)
*** 129,134 ****
--- 134,140 ----
    clear_interpreter_hooks ();
  
    show_load_progress = mi_load_progress;
+   print_frame_more_info_hook = mi_print_frame_more_info;
  
    /* If we're _the_ interpreter, take control. */
    if (current_interp_named_p (INTERP_MI1))

[-- Attachment #3: Type: text/plain, Size: 2440 bytes --]



In general, I would prefer working in two directions for this sort of 
thing.  First, we like to try to reduce the number of round trips 
between the UI and gdb for performance reasons, so when - like this - 
it is pretty obvious that a piece of info is generally useful when you 
issue some command, we try to include it in the return from that 
command.  Second, it is nice to keep the MI simple and declarative, so 
if you think there will be cases other than when you have a stack in 
front of you that you will  need the full path to a file, I would add 
an explicit command to get this result...  You have to balance these 
two desires so you don't get bloated command returns, but you also 
don't have to go many identical round trips for common operations.

Hope this helps,

Jim


On Friday, February 7, 2003, at 05:06  AM, 
gdb-digest-help@sources.redhat.com wrote:

> Thanks for the great answer.
>
> On Thu, Feb 06, 2003 at 02:17:30PM -0800, Keith Seitz wrote:
>> On Thu, 2003-02-06 at 13:55, Bob Rossi wrote:
>>> Also, what is the best way to ask mi for the absolute path to the
>>> current source file. This wasn't a problem using annotate 1 or 2, 
>>> and I
>>> can't figure out how to get it using mi.
>>
>> This is a known (to me) problem with MI. The problem is that MI was
>> designed to work with an IDE, not just a stand-alone GUI for the
>> debugger. In the case of an IDE, this information isn't needed, since
>> the IDE knows everything there is to know about files.
>>
>> However, like Insight, cgdb will need some way of turning
>> "../foo/bar/baz.c" into "/home/a/b/c/foo/bar/baz.c". There are two
>> options (excluding hacks around the problem):
>>
>> 1. Get the complete source search path from GDB and let the GUI search
>> for the file. This means the GUI writer would also need the compile
>> directory for each file.
>>
>> 2. Get GDB to tell you where it thinks a file is located.
>
> I would like to write a patch to GDB/MI and send it in with a bug
> report. Does any of the GDB/MI maintainers know if the current design
> model of GDB/MI would prefer an implicit return of the current
> absolute path ( like annotations ) or an explicit return ( the GUI
> requests it every time via a new GDB/MI command).
>
> Thanks
> Bobby
>
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
jingham@apple.com
Developer Tools - gdb