-file-list-exec-source-files

-file-list-exec-source-files

[Bob Rossi]

Hi,

Here is an initial patch for -file-list-exec-source-files.
Some feedback would be appreciated.

I ran the testsuite and the results are the same before and after this
patch.

Index: gdb/ChangeLog
	* dbxread.c (read_dbx_symtab): set pst->dirname when known
	* dwarf2read.c (partial_die_info) : add dirname field
	(dwarf2_build_psymtabs_hard) : set pst->dirname when known
	(read_partial_die) : save away DW_AT_comp_dir
	* defs.h (symtab_to_filename) : Removed.
	* source.c (find_and_open_source) : Added.
	(open_source_file): just calls find_and_open_source
	(symtab_to_filename) : Removed.
	(symtab_to_fullname, psymtab_to_fullname ) : Added.
	* source.h (psymtab_to_fullname,symtab_to_fullname): Added.
	* symtab.c (lookup_symtab): Call symtab_to_fullname instead of
	symtab_to_filename
	* symtab.h (partial_symtab): Add dirname field.
	* mi/mi-cmd-file.c (FILENAME,FULLNAME): Add
	(mi_cmd_file_list_exec_source_file): Call new function symtab_to_fullname
	to find fullname. Print out "filename", instead of "file"
	(mi_cmd_file_list_exec_source_files): Added.
	* mi/mi-cmds.c (mi_cmd_mi_cmds) : Add -file-list-exec-source-files
	* mi/mi-cmds.h (mi_cmd_file_list_exec_source_files): Added

Index: gdb/doc/ChangeLog
    * gdb.texinfo: Add -file-list-exec-source-files doco
	(-file-list-exec-source-file): change "file" to "filename"

Index: gdb/testsuite/ChangeLog
   * gdb.mi/mi-file.exp: Change "file" to "filename"
	* gdb.mi/mi2-file.exp: 
	(test_file_list_exec_source_files) Added
	(test_file_list_exec_source_file) Added
	(test_tbreak_creation_and_listing) Removed

Index: gdb/dbxread.c
===================================================================
RCS file: /cvs/src/src/gdb/dbxread.c,v
retrieving revision 1.64
diff -w -u -r1.64 dbxread.c
--- gdb/dbxread.c	14 Feb 2004 15:46:32 -0000	1.64
+++ gdb/dbxread.c	25 Feb 2004 03:51:34 -0000
@@ -1463,6 +1463,7 @@
 	    static int prev_so_symnum = -10;
 	    static int first_so_symnum;
 	    char *p;
+	    static char *dirname_nso;
 	    int prev_textlow_not_set;
 
 	    valu = nlist.n_value + ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile));
@@ -1520,18 +1521,27 @@
 
 	    p = strrchr (namestring, '/');
 	    if (p && *(p + 1) == '\000')
-	      continue;		/* Simply ignore directory name SOs */
+	      {
+		/* Save the directory name SOs locally, then save it into
+		   the psymtab when it's created below. */
+	        dirname_nso = namestring;
+	        continue;		
+	      }
 
 	    /* Some other compilers (C++ ones in particular) emit useless
 	       SOs for non-existant .c files.  We ignore all subsequent SOs that
 	       immediately follow the first.  */
 
 	    if (!pst)
+	      {
 	      pst = start_psymtab (objfile,
 				   namestring, valu,
 				   first_so_symnum * symbol_size,
 				   objfile->global_psymbols.next,
 				   objfile->static_psymbols.next);
+		pst->dirname = dirname_nso;
+		dirname_nso = NULL;
+	      }
 	    continue;
 	  }
 
Index: gdb/defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.143
diff -w -u -r1.143 defs.h
--- gdb/defs.h	23 Feb 2004 19:26:14 -0000	1.143
+++ gdb/defs.h	25 Feb 2004 03:51:35 -0000
@@ -616,8 +616,6 @@
 
 extern void init_last_source_visited (void);
 
-extern char *symtab_to_filename (struct symtab *);
-
 /* From exec.c */
 
 extern void exec_set_section_offsets (bfd_signed_vma text_off,
Index: gdb/dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.135
diff -w -u -r1.135 dwarf2read.c
--- gdb/dwarf2read.c	21 Feb 2004 02:13:35 -0000	1.135
+++ gdb/dwarf2read.c	25 Feb 2004 03:51:43 -0000
@@ -316,6 +316,7 @@
     unsigned int offset;
     unsigned int abbrev;
     char *name;
+    char *dirname;
     int has_pc_info;
     CORE_ADDR lowpc;
     CORE_ADDR highpc;
@@ -1254,6 +1255,8 @@
 				  objfile->global_psymbols.next,
 				  objfile->static_psymbols.next);
 
+      pst->dirname = xstrdup ( comp_unit_die.dirname );
+
       pst->read_symtab_private = (char *)
 	obstack_alloc (&objfile->objfile_obstack, sizeof (struct dwarf2_pinfo));
       DWARF_INFO_BUFFER (pst) = dwarf_info_buffer;
@@ -4326,6 +4329,10 @@
 	  /* Prefer DW_AT_MIPS_linkage_name over DW_AT_name.  */
 	  if (part_die->name == NULL)
 	    part_die->name = DW_STRING (&attr);
+	  break;
+	case DW_AT_comp_dir:
+	  if (part_die->dirname == NULL)
+	    part_die->dirname = DW_STRING (&attr);
 	  break;
 	case DW_AT_MIPS_linkage_name:
 	  part_die->name = DW_STRING (&attr);
Index: gdb/source.c
===================================================================
RCS file: /cvs/src/src/gdb/source.c,v
retrieving revision 1.49
diff -w -u -r1.49 source.c
--- gdb/source.c	27 Jan 2004 23:19:51 -0000	1.49
+++ gdb/source.c	25 Feb 2004 03:51:45 -0000
@@ -805,30 +805,47 @@
   return 1;
 }
 
-
-/* Open a source file given a symtab S.  Returns a file descriptor or
-   negative number for error.  */
-
+/* This function is capable of finding the absolute path to a
+   source file, and opening it, provided you give it an 
+   OBJFILE and FILENAME. Both the DIRNAME and FULLNAME are only
+   added suggestions on where to find the file. 
+
+   OBJFILE should be the objfile associated with a psymtab or symtab. 
+   FILENAME should be the filename to open.
+   DIRNAME is the compilation directory of a particular source file.
+           Only some debug formats provide this info.
+   FULLNAME can be the last known absolute path to the file in question.
+
+   On Success 
+     A valid file descriptor is returned. ( the return value is positive )
+     FULLNAME is set to the absolute path to the file just opened.
+
+   On Failure
+     A non valid file descriptor is returned. ( the return value is negitive ) 
+     FULLNAME is set to NULL.  */
 int
-open_source_file (struct symtab *s)
+find_and_open_source ( 
+  struct objfile *objfile,	
+  const char *filename,
+  const char *dirname,
+  char **fullname )
 {
   char *path = source_path;
   const char *p;
   int result;
-  char *fullname;
 
   /* Quick way out if we already know its full name */
-  if (s->fullname)
+  if (*fullname)
     {
-      result = open (s->fullname, OPEN_MODE);
+      result = open (*fullname, OPEN_MODE);
       if (result >= 0)
 	return result;
       /* Didn't work -- free old one, try again. */
-      xmfree (s->objfile->md, s->fullname);
-      s->fullname = NULL;
+      xmfree (objfile->md, *fullname);
+      *fullname = NULL;
     }
 
-  if (s->dirname != NULL)
+  if (dirname != NULL)
     {
       /* Replace a path entry of  $cdir  with the compilation directory name */
 #define	cdir_len	5
@@ -841,60 +858,102 @@
 	  int len;
 
 	  path = (char *)
-	    alloca (strlen (source_path) + 1 + strlen (s->dirname) + 1);
+	    alloca (strlen (source_path) + 1 + strlen (dirname) + 1);
 	  len = p - source_path;
 	  strncpy (path, source_path, len);	/* Before $cdir */
-	  strcpy (path + len, s->dirname);	/* new stuff */
+	  strcpy (path + len, dirname);	/* new stuff */
 	  strcat (path + len, source_path + len + cdir_len);	/* After $cdir */
 	}
     }
 
-  result = openp (path, 0, s->filename, OPEN_MODE, 0, &s->fullname);
+  result = openp (path, 0, filename, OPEN_MODE, 0, fullname);
   if (result < 0)
     {
       /* Didn't work.  Try using just the basename. */
-      p = lbasename (s->filename);
-      if (p != s->filename)
-	result = openp (path, 0, p, OPEN_MODE, 0, &s->fullname);
+      p = lbasename (filename);
+      if (p != filename)
+	result = openp (path, 0, p, OPEN_MODE, 0, fullname);
     }
 
   if (result >= 0)
     {
-      fullname = s->fullname;
-      s->fullname = mstrsave (s->objfile->md, s->fullname);
-      xfree (fullname);
+      char *tmp_fullname;
+      tmp_fullname = *fullname;
+      *fullname = mstrsave (objfile->md, *fullname);
+      xfree (tmp_fullname);
     }
   return result;
 }
 
-/* Return the path to the source file associated with symtab.  Returns NULL
-   if no symtab.  */
+/* Open a source file given a symtab S.  Returns a file descriptor or
+   negative number for error.  
+   
+   This function is a convience function to find_and_open_source. */
+
+int
+open_source_file (struct symtab *s)
+{
+    if (!s)
+      return -1;
+
+    return find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname );
+}
+
+/* Finds the fullname that a symtab represents.
+
+   If this functions finds the fullname, it will save it in ps->fullname
+   and it will also return the value.
 
+   If this function fails to find the file that this symtab represents,
+   NULL will be returned and ps->fullname will be set to NULL.  */
 char *
-symtab_to_filename (struct symtab *s)
+symtab_to_fullname (struct symtab *s)
 {
-  int fd;
+  int r;
 
   if (!s)
     return NULL;
 
-  /* If we've seen the file before, just return fullname. */
+  /* Don't check s->fullname here, the file could have been 
+     deleted/moved/..., look for it again */
+  r = find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname);
 
-  if (s->fullname)
+  if (r)
+  {
+    close (r);
     return s->fullname;
+  }
 
-  /* Try opening the file to setup fullname */
+  return NULL;
+}
 
-  fd = open_source_file (s);
-  if (fd < 0)
-    return s->filename;		/* File not found.  Just use short name */
+/* Finds the fullname that a partial_symtab represents.
 
-  /* Found the file.  Cleanup and return the full name */
+   If this functions finds the fullname, it will save it in ps->fullname
+   and it will also return the value.
 
-  close (fd);
-  return s->fullname;
+   If this function fails to find the file that this partial_symtab represents,
+   NULL will be returned and ps->fullname will be set to NULL.  */
+char *
+psymtab_to_fullname (struct partial_symtab *ps)
+{
+  int r;
+
+  if (!ps)
+    return NULL;
+
+  /* Don't check ps->fullname here, the file could have been
+     deleted/moved/..., look for it again */
+  r = find_and_open_source ( ps->objfile, ps->filename, ps->dirname, &ps->fullname);
+
+  if (r) 
+  {
+    close (r);
+    return ps->fullname;
 }
 \f
+  return NULL;
+}
 
 /* Create and initialize the table S->line_charpos that records
    the positions of the lines in the source file, which is assumed
Index: gdb/source.h
===================================================================
RCS file: /cvs/src/src/gdb/source.h,v
retrieving revision 1.4
diff -w -u -r1.4 source.h
--- gdb/source.h	12 Apr 2003 17:41:25 -0000	1.4
+++ gdb/source.h	25 Feb 2004 03:51:45 -0000
@@ -27,6 +27,9 @@
    negative number for error.  */
 extern int open_source_file (struct symtab *s);
 
+extern char* psymtab_to_fullname ( struct partial_symtab *ps );
+extern char* symtab_to_fullname ( struct symtab *s );
+
 /* Create and initialize the table S->line_charpos that records the
    positions of the lines in the source file, which is assumed to be
    open on descriptor DESC.  All set S->nlines to the number of such
Index: gdb/symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.128
diff -w -u -r1.128 symtab.c
--- gdb/symtab.c	19 Feb 2004 19:01:26 -0000	1.128
+++ gdb/symtab.c	25 Feb 2004 03:51:49 -0000
@@ -181,7 +181,7 @@
     
     if (full_path != NULL)
       {
-	const char *fp = symtab_to_filename (s);
+	const char *fp = symtab_to_fullname (s);
 	if (FILENAME_CMP (full_path, fp) == 0)
 	  {
 	    return s;
@@ -190,7 +190,7 @@
 
     if (real_path != NULL)
       {
-	char *rp = gdb_realpath (symtab_to_filename (s));
+	char *rp = gdb_realpath (symtab_to_fullname (s));
         make_cleanup (xfree, rp);
 	if (FILENAME_CMP (real_path, rp) == 0)
 	  {
Index: gdb/symtab.h
===================================================================
RCS file: /cvs/src/src/gdb/symtab.h,v
retrieving revision 1.88
diff -w -u -r1.88 symtab.h
--- gdb/symtab.h	17 Feb 2004 15:21:22 -0000	1.88
+++ gdb/symtab.h	25 Feb 2004 03:51:51 -0000
@@ -877,6 +877,10 @@
 
   char *fullname;
 
+  /* Directory in which it was compiled, or NULL if we don't know.  */
+
+  char *dirname;
+
   /* Information about the object file from which symbols should be read.  */
 
   struct objfile *objfile;
Index: gdb/doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.196
diff -w -u -r1.196 gdb.texinfo
--- gdb/doc/gdb.texinfo	24 Feb 2004 15:41:29 -0000	1.196
+++ gdb/doc/gdb.texinfo	25 Feb 2004 03:52:19 -0000
@@ -16740,7 +16740,7 @@
 @smallexample
 (@value{GDBP})
 123-file-list-exec-source-file
-123^done,line="1",file="foo.c",fullname="/home/bar/foo.c"
+123^done,line="1",filename="foo.c",fullname="/home/bar/foo.c"
 (@value{GDBP})
 @end smallexample
 
@@ -16756,14 +16756,24 @@
 
 List the source files for the current executable.
 
+It will always output the filename, but only when GDB can find the absolute
+path to a source file, will it output the fullname.
+
 @subsubheading @value{GDBN} Command
 
 There's no @value{GDBN} command which directly corresponds to this one.
 @code{gdbtk} has an analogous command @samp{gdb_listfiles}.
 
 @subsubheading Example
-N.A.
-
+@smallexample
+(@value{GDBP})
+-file-list-exec-source-files
+^done,files=[
+@{filename=foo.c,fullname=/home/foo.c@},
+@{filename=/home/bar.c,fullname=/home/bar.c@},
+@{filename=gdb_could_not_find_fullpath.c@}]
+(@value{GDBP})
+@end smallexample
 
 @subheading The @code{-file-list-shared-libraries} Command
 @findex -file-list-shared-libraries
Index: gdb/mi/mi-cmd-file.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmd-file.c,v
retrieving revision 1.1
diff -w -u -r1.1 mi-cmd-file.c
--- gdb/mi/mi-cmd-file.c	2 Apr 2003 22:10:35 -0000	1.1
+++ gdb/mi/mi-cmd-file.c	25 Feb 2004 03:52:20 -0000
@@ -25,6 +25,10 @@
 #include "ui-out.h"
 #include "symtab.h"
 #include "source.h"
+#include "objfiles.h"
+
+static const char * const FILENAME = "filename";
+static const char * const FULLNAME = "fullname";
 
 /* Return to the client the absolute path and line number of the 
    current file being executed. */
@@ -39,7 +43,6 @@
   if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_file", argc, argv) )
     error ("mi_cmd_file_list_exec_source_file: Usage: No args");
 
-  
   /* Set the default file and line, also get them */
   set_default_source_symtab_and_line();
   st = get_current_source_symtab_and_line();
@@ -51,17 +54,67 @@
     error ("mi_cmd_file_list_exec_source_file: No symtab");
 
   /* Extract the fullname if it is not known yet */
-  if (st.symtab->fullname == NULL)
-    symtab_to_filename (st.symtab);
-
-  /* We may not be able to open the file (not available). */
-  if (st.symtab->fullname == NULL)
-    error ("mi_cmd_file_list_exec_source_file: File not found");
+  symtab_to_fullname (st.symtab);
 
   /* Print to the user the line, filename and fullname */
   ui_out_field_int (uiout, "line", st.line);
-  ui_out_field_string (uiout, "file", st.symtab->filename);
-  ui_out_field_string (uiout, "fullname", st.symtab->fullname);
+  ui_out_field_string (uiout, FILENAME, st.symtab->filename);
+  
+  /* We may not be able to open the file (not available). */
+  if (st.symtab->fullname)
+    ui_out_field_string (uiout, FULLNAME, st.symtab->fullname);
+
+  return MI_CMD_DONE;
+}
+
+enum mi_cmd_result
+mi_cmd_file_list_exec_source_files(char *command, char **argv, int argc)
+{
+  struct symtab *s;
+  struct partial_symtab *ps;
+  struct objfile *objfile;
+
+  if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_files", argc, argv) )
+    error ("mi_cmd_file_list_exec_source_files: Usage: No args");
+
+  /* Print the table header */
+  ui_out_begin ( uiout, ui_out_type_list, "files");
+
+  /* Look at all of the symtabs */
+  ALL_SYMTABS (objfile, s)
+  {
+    ui_out_begin ( uiout, ui_out_type_tuple, NULL);
+
+    ui_out_field_string (uiout, FILENAME, s->filename);
+
+	/* Extract the fullname if it is not known yet */
+	symtab_to_fullname (s);
+
+	if (s->fullname)
+      ui_out_field_string (uiout, FULLNAME, s->fullname);
+
+    ui_out_end ( uiout, ui_out_type_tuple );
+  }
+
+  /* Look at all of the psymtabs */
+  ALL_PSYMTABS (objfile, ps)
+  {
+    if (!ps->readin) {
+      ui_out_begin ( uiout, ui_out_type_tuple, NULL);
+
+      ui_out_field_string (uiout, FILENAME, ps->filename);
+
+      /* Extract the fullname if it is not known yet */
+	  psymtab_to_fullname (ps);
+
+	  if (ps->fullname) 
+	    ui_out_field_string (uiout, FULLNAME, ps->fullname);
+
+      ui_out_end ( uiout, ui_out_type_tuple );
+    }
+  }
+
+  ui_out_end ( uiout, ui_out_type_list );
 
   return MI_CMD_DONE;
 }
Index: gdb/mi/mi-cmds.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmds.c,v
retrieving revision 1.14
diff -w -u -r1.14 mi-cmds.c
--- gdb/mi/mi-cmds.c	4 Aug 2003 23:18:50 -0000	1.14
+++ gdb/mi/mi-cmds.c	25 Feb 2004 03:52:20 -0000
@@ -81,7 +81,7 @@
   { "file-exec-file", { "exec-file", 1 }, NULL, NULL },
   { "file-list-exec-sections", { NULL, 0 }, NULL, NULL },
   { "file-list-exec-source-file", { NULL, 0 }, 0, mi_cmd_file_list_exec_source_file},
-  { "file-list-exec-source-files", { NULL, 0 }, NULL, NULL },
+  { "file-list-exec-source-files", { NULL, 0 }, NULL, mi_cmd_file_list_exec_source_files },
   { "file-list-shared-libraries", { NULL, 0 }, NULL, NULL },
   { "file-list-symbol-files", { NULL, 0 }, NULL, NULL },
   { "file-symbol-file", { "symbol-file", 1 }, NULL, NULL },
Index: gdb/mi/mi-cmds.h
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmds.h,v
retrieving revision 1.12
diff -w -u -r1.12 mi-cmds.h
--- gdb/mi/mi-cmds.h	24 Jan 2004 04:21:43 -0000	1.12
+++ gdb/mi/mi-cmds.h	25 Feb 2004 03:52:20 -0000
@@ -87,6 +87,7 @@
 extern mi_cmd_args_ftype mi_cmd_exec_until;
 extern mi_cmd_args_ftype mi_cmd_exec_interrupt;
 extern mi_cmd_argv_ftype mi_cmd_file_list_exec_source_file;
+extern mi_cmd_argv_ftype mi_cmd_file_list_exec_source_files;
 extern mi_cmd_argv_ftype mi_cmd_gdb_exit;
 extern mi_cmd_argv_ftype mi_cmd_interpreter_exec;
 extern mi_cmd_argv_ftype mi_cmd_stack_info_depth;
Index: gdb/testsuite/gdb.mi/mi-file.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-file.exp,v
retrieving revision 1.1
diff -w -u -r1.1 mi-file.exp
--- gdb/testsuite/gdb.mi/mi-file.exp	2 Apr 2003 22:10:35 -0000	1.1
+++ gdb/testsuite/gdb.mi/mi-file.exp	25 Feb 2004 03:52:36 -0000
@@ -55,7 +55,7 @@
 
     # get the path and absolute path to the current executable
     mi_gdb_test "111-file-list-exec-source-file" \
-	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
+	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
                "request path info of current source file (${srcfile})"
 }
 
Index: gdb/testsuite/gdb.mi/mi2-file.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi2-file.exp,v
retrieving revision 1.1
diff -w -u -r1.1 mi2-file.exp
--- gdb/testsuite/gdb.mi/mi2-file.exp	7 Aug 2003 17:47:42 -0000	1.1
+++ gdb/testsuite/gdb.mi/mi2-file.exp	25 Feb 2004 03:52:36 -0000
@@ -47,7 +47,7 @@
 mi_gdb_reinitialize_dir $srcdir/$subdir
 mi_gdb_load ${binfile}
 
-proc test_tbreak_creation_and_listing {} {
+proc test_file_list_exec_source_file {} {
     global srcfile
     global srcdir
     global subdir
@@ -55,11 +55,21 @@
 
     # get the path and absolute path to the current executable
     mi_gdb_test "111-file-list-exec-source-file" \
-	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
+	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
                "request path info of current source file (${srcfile})"
 }
 
-test_tbreak_creation_and_listing
+proc test_file_list_exec_source_files {} {
+    global srcfile
+
+    # get the path and absolute path to the current executable
+    mi_gdb_test "222-file-list-exec-source-files" \
+	    "222\\\^done,files=\\\[\{filename=\".*/${srcfile}\",fullname=\"/.*/${srcfile}\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\}\\\]" \
+              "Getting a list of source files failed."
+}
+
+test_file_list_exec_source_file
+test_file_list_exec_source_files
 
 mi_gdb_exit
 return 0

Re: -file-list-exec-source-files

[Elena Zannoni]

Bob Rossi writes:
 > Hi,
 > 
 > Here is an initial patch for -file-list-exec-source-files.
 > Some feedback would be appreciated.
 > 
 > I ran the testsuite and the results are the same before and after this
 > patch.
 > 
 > Index: gdb/ChangeLog
 > 	* dbxread.c (read_dbx_symtab): set pst->dirname when known

Each entry should start with capital letter and end with period.

I see some coding standards are not adhered to throughout the code.
Most noticeably "foo ( int a )" should be "foo (int a)". Similarly for
calls.

 > 
 > Index: gdb/dbxread.c
 > ===================================================================
 > Index: gdb/dwarf2read.c
 > ===================================================================

These are ok

 >  
 > Index: gdb/defs.h
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/defs.h,v
 > retrieving revision 1.143
 > diff -w -u -r1.143 defs.h
 > --- gdb/defs.h	23 Feb 2004 19:26:14 -0000	1.143
 > +++ gdb/defs.h	25 Feb 2004 03:51:35 -0000
 > @@ -616,8 +616,6 @@
 >  
 >  extern void init_last_source_visited (void);
 >  
 > -extern char *symtab_to_filename (struct symtab *);
 > -
 >  /* From exec.c */
 >  
 >  extern void exec_set_section_offsets (bfd_signed_vma text_off,
 > Index: gdb/dwarf2read.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/dwarf2read.c,v
 > retrieving revision 1.135
 > diff -w -u -r1.135 dwarf2read.c
 > --- gdb/dwarf2read.c	21 Feb 2004 02:13:35 -0000	1.135
 > +++ gdb/dwarf2read.c	25 Feb 2004 03:51:43 -0000
 > @@ -316,6 +316,7 @@
 >      unsigned int offset;
 >      unsigned int abbrev;
 >      char *name;
 > +    char *dirname;
 >      int has_pc_info;
 >      CORE_ADDR lowpc;
 >      CORE_ADDR highpc;
 > @@ -1254,6 +1255,8 @@
 >  				  objfile->global_psymbols.next,
 >  				  objfile->static_psymbols.next);
 >  
 > +      pst->dirname = xstrdup ( comp_unit_die.dirname );
 > +
 >        pst->read_symtab_private = (char *)
 >  	obstack_alloc (&objfile->objfile_obstack, sizeof (struct dwarf2_pinfo));
 >        DWARF_INFO_BUFFER (pst) = dwarf_info_buffer;
 > @@ -4326,6 +4329,10 @@
 >  	  /* Prefer DW_AT_MIPS_linkage_name over DW_AT_name.  */
 >  	  if (part_die->name == NULL)
 >  	    part_die->name = DW_STRING (&attr);
 > +	  break;
 > +	case DW_AT_comp_dir:
 > +	  if (part_die->dirname == NULL)
 > +	    part_die->dirname = DW_STRING (&attr);

The dwarf2 specs say that the name is in the form ":pathname" or
"hostname:pathname". Should we worry about the hostname? Does gcc emit
that?  I have looked at a few executables and didn't see the hostname
part.


 > Index: gdb/source.c
 > ===================================================================

this part I am not clear about.

There is already a function called source_full_path_of() would it help
if you used it?

What is the difference between find_and_open_source and
open_source_file?  I.e. why did you need to introduce it. I think it's
not clear just from your comments about the file possibly baing moved
around.

I am a bit worried about the substitution of symtab_to_filename with
symtab_to_fullname. The former returns null only if there is no
symtab.  The latter returns null when there is no symtab OR when it
cannot find the file. So the behavior is slightly different.


 > RCS file: /cvs/src/src/gdb/source.c,v
 > retrieving revision 1.49
 > diff -w -u -r1.49 source.c
 > --- gdb/source.c	27 Jan 2004 23:19:51 -0000	1.49
 > +++ gdb/source.c	25 Feb 2004 03:51:45 -0000
 > @@ -805,30 +805,47 @@
 >    return 1;
 >  }
 >  
 > -
 > -/* Open a source file given a symtab S.  Returns a file descriptor or
 > -   negative number for error.  */
 > -
 > +/* This function is capable of finding the absolute path to a
 > +   source file, and opening it, provided you give it an 
 > +   OBJFILE and FILENAME. Both the DIRNAME and FULLNAME are only
 > +   added suggestions on where to find the file. 
 > +
 > +   OBJFILE should be the objfile associated with a psymtab or symtab. 
 > +   FILENAME should be the filename to open.
 > +   DIRNAME is the compilation directory of a particular source file.
 > +           Only some debug formats provide this info.
 > +   FULLNAME can be the last known absolute path to the file in question.
 > +
 > +   On Success 
 > +     A valid file descriptor is returned. ( the return value is positive )
 > +     FULLNAME is set to the absolute path to the file just opened.
 > +
 > +   On Failure
 > +     A non valid file descriptor is returned. ( the return value is negitive ) 
 > +     FULLNAME is set to NULL.  */
 >  int
 > -open_source_file (struct symtab *s)
 > +find_and_open_source ( 
 > +  struct objfile *objfile,	
 > +  const char *filename,
 > +  const char *dirname,
 > +  char **fullname )
 >  {

coding standards....

 >    char *path = source_path;
 >    const char *p;
 >    int result;
 > -  char *fullname;
 >  
 >    /* Quick way out if we already know its full name */
 > -  if (s->fullname)
 > +  if (*fullname)
 >      {
 > -      result = open (s->fullname, OPEN_MODE);
 > +      result = open (*fullname, OPEN_MODE);
 >        if (result >= 0)
 >  	return result;
 >        /* Didn't work -- free old one, try again. */
 > -      xmfree (s->objfile->md, s->fullname);
 > -      s->fullname = NULL;
 > +      xmfree (objfile->md, *fullname);
 > +      *fullname = NULL;
 >      }
 >  
 > -  if (s->dirname != NULL)
 > +  if (dirname != NULL)
 >      {
 >        /* Replace a path entry of  $cdir  with the compilation directory name */
 >  #define	cdir_len	5
 > @@ -841,60 +858,102 @@
 >  	  int len;
 >  
 >  	  path = (char *)
 > -	    alloca (strlen (source_path) + 1 + strlen (s->dirname) + 1);
 > +	    alloca (strlen (source_path) + 1 + strlen (dirname) + 1);
 >  	  len = p - source_path;
 >  	  strncpy (path, source_path, len);	/* Before $cdir */
 > -	  strcpy (path + len, s->dirname);	/* new stuff */
 > +	  strcpy (path + len, dirname);	/* new stuff */
 >  	  strcat (path + len, source_path + len + cdir_len);	/* After $cdir */
 >  	}
 >      }
 >  
 > -  result = openp (path, 0, s->filename, OPEN_MODE, 0, &s->fullname);
 > +  result = openp (path, 0, filename, OPEN_MODE, 0, fullname);
 >    if (result < 0)
 >      {
 >        /* Didn't work.  Try using just the basename. */
 > -      p = lbasename (s->filename);
 > -      if (p != s->filename)
 > -	result = openp (path, 0, p, OPEN_MODE, 0, &s->fullname);
 > +      p = lbasename (filename);
 > +      if (p != filename)
 > +	result = openp (path, 0, p, OPEN_MODE, 0, fullname);
 >      }
 >  
 >    if (result >= 0)
 >      {
 > -      fullname = s->fullname;
 > -      s->fullname = mstrsave (s->objfile->md, s->fullname);
 > -      xfree (fullname);
 > +      char *tmp_fullname;
 > +      tmp_fullname = *fullname;
 > +      *fullname = mstrsave (objfile->md, *fullname);
 > +      xfree (tmp_fullname);
 >      }
 >    return result;
 >  }
 >  
 > -/* Return the path to the source file associated with symtab.  Returns NULL
 > -   if no symtab.  */
 > +/* Open a source file given a symtab S.  Returns a file descriptor or
 > +   negative number for error.  
 > +   
 > +   This function is a convience function to find_and_open_source. */
 > +
 > +int
 > +open_source_file (struct symtab *s)
 > +{
 > +    if (!s)
 > +      return -1;
 > +
 > +    return find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname );
 > +}
 > +
 > +/* Finds the fullname that a symtab represents.
 > +
 > +   If this functions finds the fullname, it will save it in ps->fullname
 > +   and it will also return the value.
 >  
 > +   If this function fails to find the file that this symtab represents,
 > +   NULL will be returned and ps->fullname will be set to NULL.  */
 >  char *
 > -symtab_to_filename (struct symtab *s)
 > +symtab_to_fullname (struct symtab *s)
 >  {
 > -  int fd;
 > +  int r;
 >  
 >    if (!s)
 >      return NULL;
 >  
 > -  /* If we've seen the file before, just return fullname. */
 > +  /* Don't check s->fullname here, the file could have been 
 > +     deleted/moved/..., look for it again */
 > +  r = find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname);
 >  
 > -  if (s->fullname)
 > +  if (r)
 > +  {
 > +    close (r);
 >      return s->fullname;
 > +  }
 >  
 > -  /* Try opening the file to setup fullname */
 > +  return NULL;
 > +}
 >  
 > -  fd = open_source_file (s);
 > -  if (fd < 0)
 > -    return s->filename;		/* File not found.  Just use short name */
 > +/* Finds the fullname that a partial_symtab represents.
 >  
 > -  /* Found the file.  Cleanup and return the full name */
 > +   If this functions finds the fullname, it will save it in ps->fullname
 > +   and it will also return the value.
 >  
 > -  close (fd);
 > -  return s->fullname;
 > +   If this function fails to find the file that this partial_symtab represents,
 > +   NULL will be returned and ps->fullname will be set to NULL.  */
 > +char *
 > +psymtab_to_fullname (struct partial_symtab *ps)
 > +{
 > +  int r;
 > +
 > +  if (!ps)
 > +    return NULL;
 > +
 > +  /* Don't check ps->fullname here, the file could have been
 > +     deleted/moved/..., look for it again */
 > +  r = find_and_open_source ( ps->objfile, ps->filename, ps->dirname, &ps->fullname);
 > +
 > +  if (r) 
 > +  {
 > +    close (r);
 > +    return ps->fullname;
 >  }
 >  \f
 > +  return NULL;
 > +}
 >  
 >  /* Create and initialize the table S->line_charpos that records
 >     the positions of the lines in the source file, which is assumed



 > Index: gdb/source.h
 > ===================================================================
 > Index: gdb/symtab.c
 > ===================================================================

These are obvious if the rest goes in.


 > Index: gdb/symtab.h
 > ===================================================================

OK.


 > Index: gdb/mi/mi-cmd-file.c
 > ===================================================================


 > +static const char * const FILENAME = "filename";
 > +static const char * const FULLNAME = "fullname";

I don't think these are necessary.

 >  
 >  /* Return to the client the absolute path and line number of the 
 >     current file being executed. */
 > @@ -39,7 +43,6 @@
 >    if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_file", argc, argv) )
 >      error ("mi_cmd_file_list_exec_source_file: Usage: No args");
 >  
 > -  
 >    /* Set the default file and line, also get them */
 >    set_default_source_symtab_and_line();
 >    st = get_current_source_symtab_and_line();
 > @@ -51,17 +54,67 @@
 >      error ("mi_cmd_file_list_exec_source_file: No symtab");
 >  
 >    /* Extract the fullname if it is not known yet */
 > -  if (st.symtab->fullname == NULL)
 > -    symtab_to_filename (st.symtab);
 > -
 > -  /* We may not be able to open the file (not available). */
 > -  if (st.symtab->fullname == NULL)
 > -    error ("mi_cmd_file_list_exec_source_file: File not found");

Why get rid of the error message?

 > +  symtab_to_fullname (st.symtab);
 >  
 >    /* Print to the user the line, filename and fullname */
 >    ui_out_field_int (uiout, "line", st.line);
 > -  ui_out_field_string (uiout, "file", st.symtab->filename);
 > -  ui_out_field_string (uiout, "fullname", st.symtab->fullname);
 > +  ui_out_field_string (uiout, FILENAME, st.symtab->filename);
 > +  
 > +  /* We may not be able to open the file (not available). */
 > +  if (st.symtab->fullname)
 > +    ui_out_field_string (uiout, FULLNAME, st.symtab->fullname);
 > +

if this test fails shouldn't some warning/error be issued?

 > +  return MI_CMD_DONE;
 > +}
 > +
 > +enum mi_cmd_result
 > +mi_cmd_file_list_exec_source_files(char *command, char **argv, int argc)
 > +{
 > +  struct symtab *s;
 > +  struct partial_symtab *ps;
 > +  struct objfile *objfile;
 > +
 > +  if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_files", argc, argv) )
 > +    error ("mi_cmd_file_list_exec_source_files: Usage: No args");
 > +
 > +  /* Print the table header */
 > +  ui_out_begin ( uiout, ui_out_type_list, "files");
 > +
 > +  /* Look at all of the symtabs */
 > +  ALL_SYMTABS (objfile, s)
 > +  {
 > +    ui_out_begin ( uiout, ui_out_type_tuple, NULL);
 > +
 > +    ui_out_field_string (uiout, FILENAME, s->filename);
 > +
 > +	/* Extract the fullname if it is not known yet */
 > +	symtab_to_fullname (s);
 > +
 > +	if (s->fullname)
 > +      ui_out_field_string (uiout, FULLNAME, s->fullname);
 > +
 > +    ui_out_end ( uiout, ui_out_type_tuple );
 > +  }
 > +
 > +  /* Look at all of the psymtabs */
 > +  ALL_PSYMTABS (objfile, ps)
 > +  {
 > +    if (!ps->readin) {

coding standards....

 > +      ui_out_begin ( uiout, ui_out_type_tuple, NULL);
 > +
 > +      ui_out_field_string (uiout, FILENAME, ps->filename);
 > +
 > +      /* Extract the fullname if it is not known yet */
 > +	  psymtab_to_fullname (ps);
 > +
 > +	  if (ps->fullname) 
 > +	    ui_out_field_string (uiout, FULLNAME, ps->fullname);
 > +
 > +      ui_out_end ( uiout, ui_out_type_tuple );
 > +    }
 > +  }
 > +
 > +  ui_out_end ( uiout, ui_out_type_list );
 >  
 >    return MI_CMD_DONE;
 >  }



 > Index: gdb/mi/mi-cmds.c
 > ===================================================================

 > Index: gdb/mi/mi-cmds.h
 > ===================================================================

these changes are ok.




 > Index: gdb/testsuite/gdb.mi/mi-file.exp
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-file.exp,v
 > retrieving revision 1.1
 > diff -w -u -r1.1 mi-file.exp
 > --- gdb/testsuite/gdb.mi/mi-file.exp	2 Apr 2003 22:10:35 -0000	1.1
 > +++ gdb/testsuite/gdb.mi/mi-file.exp	25 Feb 2004 03:52:36 -0000
 > @@ -55,7 +55,7 @@
 >  
 >      # get the path and absolute path to the current executable
 >      mi_gdb_test "111-file-list-exec-source-file" \
 > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
 > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \

Wouldn't this break existing MI parsers?


 >                 "request path info of current source file (${srcfile})"
 >  }
 >  
 > Index: gdb/testsuite/gdb.mi/mi2-file.exp
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi2-file.exp,v
 > retrieving revision 1.1
 > diff -w -u -r1.1 mi2-file.exp
 > --- gdb/testsuite/gdb.mi/mi2-file.exp	7 Aug 2003 17:47:42 -0000	1.1
 > +++ gdb/testsuite/gdb.mi/mi2-file.exp	25 Feb 2004 03:52:36 -0000
 > @@ -47,7 +47,7 @@
 >  mi_gdb_reinitialize_dir $srcdir/$subdir
 >  mi_gdb_load ${binfile}
 >  
 > -proc test_tbreak_creation_and_listing {} {
 > +proc test_file_list_exec_source_file {} {
 >      global srcfile
 >      global srcdir
 >      global subdir
 > @@ -55,11 +55,21 @@
 >  
 >      # get the path and absolute path to the current executable
 >      mi_gdb_test "111-file-list-exec-source-file" \
 > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
 > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
 >                 "request path info of current source file (${srcfile})"
 >  }
 >  
 > -test_tbreak_creation_and_listing
 > +proc test_file_list_exec_source_files {} {
 > +    global srcfile
 > +
 > +    # get the path and absolute path to the current executable
 > +    mi_gdb_test "222-file-list-exec-source-files" \
 > +	    "222\\\^done,files=\\\[\{filename=\".*/${srcfile}\",fullname=\"/.*/${srcfile}\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\}\\\]" \

 > +              "Getting a list of source files failed."
                                                 ^^^^^^^
                                                  why failed?

Re: -file-list-exec-source-files

[Elena Zannoni]

Bob Rossi writes:
 > Hi,
 > 
 > Here is an initial patch for -file-list-exec-source-files.
 > Some feedback would be appreciated.
 > 
 > I ran the testsuite and the results are the same before and after this
 > patch.
 > 
 > Index: gdb/ChangeLog
 > 	* dbxread.c (read_dbx_symtab): set pst->dirname when known

Each entry should start with capital letter and end with period.

I see some coding standards are not adhered to throughout the code.
Most noticeably "foo ( int a )" should be "foo (int a)". Similarly for
calls.

 > 
 > Index: gdb/dbxread.c
 > ===================================================================
 > Index: gdb/dwarf2read.c
 > ===================================================================

These are ok

 >  
 > Index: gdb/defs.h
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/defs.h,v
 > retrieving revision 1.143
 > diff -w -u -r1.143 defs.h
 > --- gdb/defs.h	23 Feb 2004 19:26:14 -0000	1.143
 > +++ gdb/defs.h	25 Feb 2004 03:51:35 -0000
 > @@ -616,8 +616,6 @@
 >  
 >  extern void init_last_source_visited (void);
 >  
 > -extern char *symtab_to_filename (struct symtab *);
 > -
 >  /* From exec.c */
 >  
 >  extern void exec_set_section_offsets (bfd_signed_vma text_off,
 > Index: gdb/dwarf2read.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/dwarf2read.c,v
 > retrieving revision 1.135
 > diff -w -u -r1.135 dwarf2read.c
 > --- gdb/dwarf2read.c	21 Feb 2004 02:13:35 -0000	1.135
 > +++ gdb/dwarf2read.c	25 Feb 2004 03:51:43 -0000
 > @@ -316,6 +316,7 @@
 >      unsigned int offset;
 >      unsigned int abbrev;
 >      char *name;
 > +    char *dirname;
 >      int has_pc_info;
 >      CORE_ADDR lowpc;
 >      CORE_ADDR highpc;
 > @@ -1254,6 +1255,8 @@
 >  				  objfile->global_psymbols.next,
 >  				  objfile->static_psymbols.next);
 >  
 > +      pst->dirname = xstrdup ( comp_unit_die.dirname );
 > +
 >        pst->read_symtab_private = (char *)
 >  	obstack_alloc (&objfile->objfile_obstack, sizeof (struct dwarf2_pinfo));
 >        DWARF_INFO_BUFFER (pst) = dwarf_info_buffer;
 > @@ -4326,6 +4329,10 @@
 >  	  /* Prefer DW_AT_MIPS_linkage_name over DW_AT_name.  */
 >  	  if (part_die->name == NULL)
 >  	    part_die->name = DW_STRING (&attr);
 > +	  break;
 > +	case DW_AT_comp_dir:
 > +	  if (part_die->dirname == NULL)
 > +	    part_die->dirname = DW_STRING (&attr);

The dwarf2 specs say that the name is in the form ":pathname" or
"hostname:pathname". Should we worry about the hostname? Does gcc emit
that?  I have looked at a few executables and didn't see the hostname
part.


 > Index: gdb/source.c
 > ===================================================================

this part I am not clear about.

There is already a function called source_full_path_of() would it help
if you used it?

What is the difference between find_and_open_source and
open_source_file?  I.e. why did you need to introduce it. I think it's
not clear just from your comments about the file possibly baing moved
around.

I am a bit worried about the substitution of symtab_to_filename with
symtab_to_fullname. The former returns null only if there is no
symtab.  The latter returns null when there is no symtab OR when it
cannot find the file. So the behavior is slightly different.


 > RCS file: /cvs/src/src/gdb/source.c,v
 > retrieving revision 1.49
 > diff -w -u -r1.49 source.c
 > --- gdb/source.c	27 Jan 2004 23:19:51 -0000	1.49
 > +++ gdb/source.c	25 Feb 2004 03:51:45 -0000
 > @@ -805,30 +805,47 @@
 >    return 1;
 >  }
 >  
 > -
 > -/* Open a source file given a symtab S.  Returns a file descriptor or
 > -   negative number for error.  */
 > -
 > +/* This function is capable of finding the absolute path to a
 > +   source file, and opening it, provided you give it an 
 > +   OBJFILE and FILENAME. Both the DIRNAME and FULLNAME are only
 > +   added suggestions on where to find the file. 
 > +
 > +   OBJFILE should be the objfile associated with a psymtab or symtab. 
 > +   FILENAME should be the filename to open.
 > +   DIRNAME is the compilation directory of a particular source file.
 > +           Only some debug formats provide this info.
 > +   FULLNAME can be the last known absolute path to the file in question.
 > +
 > +   On Success 
 > +     A valid file descriptor is returned. ( the return value is positive )
 > +     FULLNAME is set to the absolute path to the file just opened.
 > +
 > +   On Failure
 > +     A non valid file descriptor is returned. ( the return value is negitive ) 
 > +     FULLNAME is set to NULL.  */
 >  int
 > -open_source_file (struct symtab *s)
 > +find_and_open_source ( 
 > +  struct objfile *objfile,	
 > +  const char *filename,
 > +  const char *dirname,
 > +  char **fullname )
 >  {

coding standards....

 >    char *path = source_path;
 >    const char *p;
 >    int result;
 > -  char *fullname;
 >  
 >    /* Quick way out if we already know its full name */
 > -  if (s->fullname)
 > +  if (*fullname)
 >      {
 > -      result = open (s->fullname, OPEN_MODE);
 > +      result = open (*fullname, OPEN_MODE);
 >        if (result >= 0)
 >  	return result;
 >        /* Didn't work -- free old one, try again. */
 > -      xmfree (s->objfile->md, s->fullname);
 > -      s->fullname = NULL;
 > +      xmfree (objfile->md, *fullname);
 > +      *fullname = NULL;
 >      }
 >  
 > -  if (s->dirname != NULL)
 > +  if (dirname != NULL)
 >      {
 >        /* Replace a path entry of  $cdir  with the compilation directory name */
 >  #define	cdir_len	5
 > @@ -841,60 +858,102 @@
 >  	  int len;
 >  
 >  	  path = (char *)
 > -	    alloca (strlen (source_path) + 1 + strlen (s->dirname) + 1);
 > +	    alloca (strlen (source_path) + 1 + strlen (dirname) + 1);
 >  	  len = p - source_path;
 >  	  strncpy (path, source_path, len);	/* Before $cdir */
 > -	  strcpy (path + len, s->dirname);	/* new stuff */
 > +	  strcpy (path + len, dirname);	/* new stuff */
 >  	  strcat (path + len, source_path + len + cdir_len);	/* After $cdir */
 >  	}
 >      }
 >  
 > -  result = openp (path, 0, s->filename, OPEN_MODE, 0, &s->fullname);
 > +  result = openp (path, 0, filename, OPEN_MODE, 0, fullname);
 >    if (result < 0)
 >      {
 >        /* Didn't work.  Try using just the basename. */
 > -      p = lbasename (s->filename);
 > -      if (p != s->filename)
 > -	result = openp (path, 0, p, OPEN_MODE, 0, &s->fullname);
 > +      p = lbasename (filename);
 > +      if (p != filename)
 > +	result = openp (path, 0, p, OPEN_MODE, 0, fullname);
 >      }
 >  
 >    if (result >= 0)
 >      {
 > -      fullname = s->fullname;
 > -      s->fullname = mstrsave (s->objfile->md, s->fullname);
 > -      xfree (fullname);
 > +      char *tmp_fullname;
 > +      tmp_fullname = *fullname;
 > +      *fullname = mstrsave (objfile->md, *fullname);
 > +      xfree (tmp_fullname);
 >      }
 >    return result;
 >  }
 >  
 > -/* Return the path to the source file associated with symtab.  Returns NULL
 > -   if no symtab.  */
 > +/* Open a source file given a symtab S.  Returns a file descriptor or
 > +   negative number for error.  
 > +   
 > +   This function is a convience function to find_and_open_source. */
 > +
 > +int
 > +open_source_file (struct symtab *s)
 > +{
 > +    if (!s)
 > +      return -1;
 > +
 > +    return find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname );
 > +}
 > +
 > +/* Finds the fullname that a symtab represents.
 > +
 > +   If this functions finds the fullname, it will save it in ps->fullname
 > +   and it will also return the value.
 >  
 > +   If this function fails to find the file that this symtab represents,
 > +   NULL will be returned and ps->fullname will be set to NULL.  */
 >  char *
 > -symtab_to_filename (struct symtab *s)
 > +symtab_to_fullname (struct symtab *s)
 >  {
 > -  int fd;
 > +  int r;
 >  
 >    if (!s)
 >      return NULL;
 >  
 > -  /* If we've seen the file before, just return fullname. */
 > +  /* Don't check s->fullname here, the file could have been 
 > +     deleted/moved/..., look for it again */
 > +  r = find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname);
 >  
 > -  if (s->fullname)
 > +  if (r)
 > +  {
 > +    close (r);
 >      return s->fullname;
 > +  }
 >  
 > -  /* Try opening the file to setup fullname */
 > +  return NULL;
 > +}
 >  
 > -  fd = open_source_file (s);
 > -  if (fd < 0)
 > -    return s->filename;		/* File not found.  Just use short name */
 > +/* Finds the fullname that a partial_symtab represents.
 >  
 > -  /* Found the file.  Cleanup and return the full name */
 > +   If this functions finds the fullname, it will save it in ps->fullname
 > +   and it will also return the value.
 >  
 > -  close (fd);
 > -  return s->fullname;
 > +   If this function fails to find the file that this partial_symtab represents,
 > +   NULL will be returned and ps->fullname will be set to NULL.  */
 > +char *
 > +psymtab_to_fullname (struct partial_symtab *ps)
 > +{
 > +  int r;
 > +
 > +  if (!ps)
 > +    return NULL;
 > +
 > +  /* Don't check ps->fullname here, the file could have been
 > +     deleted/moved/..., look for it again */
 > +  r = find_and_open_source ( ps->objfile, ps->filename, ps->dirname, &ps->fullname);
 > +
 > +  if (r) 
 > +  {
 > +    close (r);
 > +    return ps->fullname;
 >  }
 >  \f
 > +  return NULL;
 > +}
 >  
 >  /* Create and initialize the table S->line_charpos that records
 >     the positions of the lines in the source file, which is assumed



 > Index: gdb/source.h
 > ===================================================================
 > Index: gdb/symtab.c
 > ===================================================================

These are obvious if the rest goes in.


 > Index: gdb/symtab.h
 > ===================================================================

OK.


 > Index: gdb/mi/mi-cmd-file.c
 > ===================================================================


 > +static const char * const FILENAME = "filename";
 > +static const char * const FULLNAME = "fullname";

I don't think these are necessary.

 >  
 >  /* Return to the client the absolute path and line number of the 
 >     current file being executed. */
 > @@ -39,7 +43,6 @@
 >    if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_file", argc, argv) )
 >      error ("mi_cmd_file_list_exec_source_file: Usage: No args");
 >  
 > -  
 >    /* Set the default file and line, also get them */
 >    set_default_source_symtab_and_line();
 >    st = get_current_source_symtab_and_line();
 > @@ -51,17 +54,67 @@
 >      error ("mi_cmd_file_list_exec_source_file: No symtab");
 >  
 >    /* Extract the fullname if it is not known yet */
 > -  if (st.symtab->fullname == NULL)
 > -    symtab_to_filename (st.symtab);
 > -
 > -  /* We may not be able to open the file (not available). */
 > -  if (st.symtab->fullname == NULL)
 > -    error ("mi_cmd_file_list_exec_source_file: File not found");

Why get rid of the error message?

 > +  symtab_to_fullname (st.symtab);
 >  
 >    /* Print to the user the line, filename and fullname */
 >    ui_out_field_int (uiout, "line", st.line);
 > -  ui_out_field_string (uiout, "file", st.symtab->filename);
 > -  ui_out_field_string (uiout, "fullname", st.symtab->fullname);
 > +  ui_out_field_string (uiout, FILENAME, st.symtab->filename);
 > +  
 > +  /* We may not be able to open the file (not available). */
 > +  if (st.symtab->fullname)
 > +    ui_out_field_string (uiout, FULLNAME, st.symtab->fullname);
 > +

if this test fails shouldn't some warning/error be issued?

 > +  return MI_CMD_DONE;
 > +}
 > +
 > +enum mi_cmd_result
 > +mi_cmd_file_list_exec_source_files(char *command, char **argv, int argc)
 > +{
 > +  struct symtab *s;
 > +  struct partial_symtab *ps;
 > +  struct objfile *objfile;
 > +
 > +  if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_files", argc, argv) )
 > +    error ("mi_cmd_file_list_exec_source_files: Usage: No args");
 > +
 > +  /* Print the table header */
 > +  ui_out_begin ( uiout, ui_out_type_list, "files");
 > +
 > +  /* Look at all of the symtabs */
 > +  ALL_SYMTABS (objfile, s)
 > +  {
 > +    ui_out_begin ( uiout, ui_out_type_tuple, NULL);
 > +
 > +    ui_out_field_string (uiout, FILENAME, s->filename);
 > +
 > +	/* Extract the fullname if it is not known yet */
 > +	symtab_to_fullname (s);
 > +
 > +	if (s->fullname)
 > +      ui_out_field_string (uiout, FULLNAME, s->fullname);
 > +
 > +    ui_out_end ( uiout, ui_out_type_tuple );
 > +  }
 > +
 > +  /* Look at all of the psymtabs */
 > +  ALL_PSYMTABS (objfile, ps)
 > +  {
 > +    if (!ps->readin) {

coding standards....

 > +      ui_out_begin ( uiout, ui_out_type_tuple, NULL);
 > +
 > +      ui_out_field_string (uiout, FILENAME, ps->filename);
 > +
 > +      /* Extract the fullname if it is not known yet */
 > +	  psymtab_to_fullname (ps);
 > +
 > +	  if (ps->fullname) 
 > +	    ui_out_field_string (uiout, FULLNAME, ps->fullname);
 > +
 > +      ui_out_end ( uiout, ui_out_type_tuple );
 > +    }
 > +  }
 > +
 > +  ui_out_end ( uiout, ui_out_type_list );
 >  
 >    return MI_CMD_DONE;
 >  }



 > Index: gdb/mi/mi-cmds.c
 > ===================================================================

 > Index: gdb/mi/mi-cmds.h
 > ===================================================================

these changes are ok.




 > Index: gdb/testsuite/gdb.mi/mi-file.exp
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-file.exp,v
 > retrieving revision 1.1
 > diff -w -u -r1.1 mi-file.exp
 > --- gdb/testsuite/gdb.mi/mi-file.exp	2 Apr 2003 22:10:35 -0000	1.1
 > +++ gdb/testsuite/gdb.mi/mi-file.exp	25 Feb 2004 03:52:36 -0000
 > @@ -55,7 +55,7 @@
 >  
 >      # get the path and absolute path to the current executable
 >      mi_gdb_test "111-file-list-exec-source-file" \
 > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
 > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \

Wouldn't this break existing MI parsers?


 >                 "request path info of current source file (${srcfile})"
 >  }
 >  
 > Index: gdb/testsuite/gdb.mi/mi2-file.exp
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi2-file.exp,v
 > retrieving revision 1.1
 > diff -w -u -r1.1 mi2-file.exp
 > --- gdb/testsuite/gdb.mi/mi2-file.exp	7 Aug 2003 17:47:42 -0000	1.1
 > +++ gdb/testsuite/gdb.mi/mi2-file.exp	25 Feb 2004 03:52:36 -0000
 > @@ -47,7 +47,7 @@
 >  mi_gdb_reinitialize_dir $srcdir/$subdir
 >  mi_gdb_load ${binfile}
 >  
 > -proc test_tbreak_creation_and_listing {} {
 > +proc test_file_list_exec_source_file {} {
 >      global srcfile
 >      global srcdir
 >      global subdir
 > @@ -55,11 +55,21 @@
 >  
 >      # get the path and absolute path to the current executable
 >      mi_gdb_test "111-file-list-exec-source-file" \
 > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
 > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
 >                 "request path info of current source file (${srcfile})"
 >  }
 >  
 > -test_tbreak_creation_and_listing
 > +proc test_file_list_exec_source_files {} {
 > +    global srcfile
 > +
 > +    # get the path and absolute path to the current executable
 > +    mi_gdb_test "222-file-list-exec-source-files" \
 > +	    "222\\\^done,files=\\\[\{filename=\".*/${srcfile}\",fullname=\"/.*/${srcfile}\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\}\\\]" \

 > +              "Getting a list of source files failed."
                                                 ^^^^^^^
                                                  why failed?

Re: -file-list-exec-source-files

[Jason Molenda]

Hi Elena,


On Mar 5, 2004, at 2:31 PM, Elena Zannoni wrote:

>> @@ -1254,6 +1255,8 @@
>>  				  objfile->global_psymbols.next,
>>  				  objfile->static_psymbols.next);
>>
>> +      pst->dirname = xstrdup ( comp_unit_die.dirname );
>> +
>>        pst->read_symtab_private = (char *)
>>  	obstack_alloc (&objfile->objfile_obstack, sizeof (struct 
>> dwarf2_pinfo));
>>        DWARF_INFO_BUFFER (pst) = dwarf_info_buffer;
>> @@ -4326,6 +4329,10 @@
>>  	  /* Prefer DW_AT_MIPS_linkage_name over DW_AT_name.  */
>>  	  if (part_die->name == NULL)
>>  	    part_die->name = DW_STRING (&attr);
>> +	  break;
>> +	case DW_AT_comp_dir:
>> +	  if (part_die->dirname == NULL)
>> +	    part_die->dirname = DW_STRING (&attr);
>
> The dwarf2 specs say that the name is in the form ":pathname" or
> "hostname:pathname". Should we worry about the hostname? Does gcc emit
> that?  I have looked at a few executables and didn't see the hostname
> part.


Oh that the DWARF spec were this cut-and-dried. :-)  DWARF3 draft 8 says


A DW_AT_comp_dir attribute whose value is a null-terminated string 
containing the current working directory of the compilation command 
that produced this compilation unit in whatever form makes sense for 
the host system.

The suggested form for the value of DW_AT_comp_dir attribute on UNIX 
systems is "hostname:pathname".  If no hostname is available, the 
suggested form is ":pathname".


gcc puts the output of getpwd() into DW_AT_comp_dir.  Obviously the 
spec allows this.  I suppose a consumer must be prepared to handle any 
one of

   /path/to/file
   :/path/to/file
   hostname:/path/to/file
   C:/path/to/file
   hostname:C:/path/to/file

And I wonder what should be done if one of the directory names contains 
a ":".  /path/to:haha/file is clearly ambiguous -- a producer could 
disambiguate by always prepending a ":", but the consumer has no way of 
knowing what it might be receiving.  Quite a sticky wicket.


J

Re: -file-list-exec-source-files

[Jason Molenda]

Hi Elena,


On Mar 5, 2004, at 2:31 PM, Elena Zannoni wrote:

>> @@ -1254,6 +1255,8 @@
>>  				  objfile->global_psymbols.next,
>>  				  objfile->static_psymbols.next);
>>
>> +      pst->dirname = xstrdup ( comp_unit_die.dirname );
>> +
>>        pst->read_symtab_private = (char *)
>>  	obstack_alloc (&objfile->objfile_obstack, sizeof (struct 
>> dwarf2_pinfo));
>>        DWARF_INFO_BUFFER (pst) = dwarf_info_buffer;
>> @@ -4326,6 +4329,10 @@
>>  	  /* Prefer DW_AT_MIPS_linkage_name over DW_AT_name.  */
>>  	  if (part_die->name == NULL)
>>  	    part_die->name = DW_STRING (&attr);
>> +	  break;
>> +	case DW_AT_comp_dir:
>> +	  if (part_die->dirname == NULL)
>> +	    part_die->dirname = DW_STRING (&attr);
>
> The dwarf2 specs say that the name is in the form ":pathname" or
> "hostname:pathname". Should we worry about the hostname? Does gcc emit
> that?  I have looked at a few executables and didn't see the hostname
> part.


Oh that the DWARF spec were this cut-and-dried. :-)  DWARF3 draft 8 says


A DW_AT_comp_dir attribute whose value is a null-terminated string 
containing the current working directory of the compilation command 
that produced this compilation unit in whatever form makes sense for 
the host system.

The suggested form for the value of DW_AT_comp_dir attribute on UNIX 
systems is "hostname:pathname".  If no hostname is available, the 
suggested form is ":pathname".


gcc puts the output of getpwd() into DW_AT_comp_dir.  Obviously the 
spec allows this.  I suppose a consumer must be prepared to handle any 
one of

   /path/to/file
   :/path/to/file
   hostname:/path/to/file
   C:/path/to/file
   hostname:C:/path/to/file

And I wonder what should be done if one of the directory names contains 
a ":".  /path/to:haha/file is clearly ambiguous -- a producer could 
disambiguate by always prepending a ":", but the consumer has no way of 
knowing what it might be receiving.  Quite a sticky wicket.


J

Re: -file-list-exec-source-files

[Bob Rossi]

Elena, thanks for taking the time to review my patch.

When is a good point to resubmit a patch? After every review, or after
all the issues are ironed out?

>  > Here is an initial patch for -file-list-exec-source-files.
>  > Some feedback would be appreciated.
>  > 
>  > I ran the testsuite and the results are the same before and after this
>  > patch.
>  > 
>  > Index: gdb/ChangeLog
>  > 	* dbxread.c (read_dbx_symtab): set pst->dirname when known
> 
> Each entry should start with capital letter and end with period.
> 
> I see some coding standards are not adhered to throughout the code.
> Most noticeably "foo ( int a )" should be "foo (int a)". Similarly for
> calls.

Ok, I will try to fix all of the coding standard errors. Is there a
program I can run on the source files before I create the diff that
formats the code according to the standard?

> 
>  > 
>  > Index: gdb/dbxread.c
>  > ===================================================================
>  > Index: gdb/dwarf2read.c
>  > ===================================================================
> 
> These are ok

Great!

>  >  
>  > Index: gdb/defs.h
>  > ===================================================================
>  > RCS file: /cvs/src/src/gdb/defs.h,v
>  > retrieving revision 1.143
>  > diff -w -u -r1.143 defs.h
>  > --- gdb/defs.h	23 Feb 2004 19:26:14 -0000	1.143
>  > +++ gdb/defs.h	25 Feb 2004 03:51:35 -0000
>  > @@ -616,8 +616,6 @@
>  >  
>  >  extern void init_last_source_visited (void);
>  >  
>  > -extern char *symtab_to_filename (struct symtab *);
>  > -
>  >  /* From exec.c */
>  >  
>  >  extern void exec_set_section_offsets (bfd_signed_vma text_off,
>  > Index: gdb/dwarf2read.c
>  > ===================================================================
>  > RCS file: /cvs/src/src/gdb/dwarf2read.c,v
>  > retrieving revision 1.135
>  > diff -w -u -r1.135 dwarf2read.c
>  > --- gdb/dwarf2read.c	21 Feb 2004 02:13:35 -0000	1.135
>  > +++ gdb/dwarf2read.c	25 Feb 2004 03:51:43 -0000
>  > @@ -316,6 +316,7 @@
>  >      unsigned int offset;
>  >      unsigned int abbrev;
>  >      char *name;
>  > +    char *dirname;
>  >      int has_pc_info;
>  >      CORE_ADDR lowpc;
>  >      CORE_ADDR highpc;
>  > @@ -1254,6 +1255,8 @@
>  >  				  objfile->global_psymbols.next,
>  >  				  objfile->static_psymbols.next);
>  >  
>  > +      pst->dirname = xstrdup ( comp_unit_die.dirname );
>  > +
>  >        pst->read_symtab_private = (char *)
>  >  	obstack_alloc (&objfile->objfile_obstack, sizeof (struct dwarf2_pinfo));
>  >        DWARF_INFO_BUFFER (pst) = dwarf_info_buffer;
>  > @@ -4326,6 +4329,10 @@
>  >  	  /* Prefer DW_AT_MIPS_linkage_name over DW_AT_name.  */
>  >  	  if (part_die->name == NULL)
>  >  	    part_die->name = DW_STRING (&attr);
>  > +	  break;
>  > +	case DW_AT_comp_dir:
>  > +	  if (part_die->dirname == NULL)
>  > +	    part_die->dirname = DW_STRING (&attr);
> 
> The dwarf2 specs say that the name is in the form ":pathname" or
> "hostname:pathname". Should we worry about the hostname? Does gcc emit
> that?  I have looked at a few executables and didn't see the hostname
> part.

It would probably just be best if you told me what case's you want me to
implement here. It seems that Jason Molenda understodd most of the
cases. I really don't know anything about what GCC emits and would would
be practical to implement.

>  > Index: gdb/source.c
>  > ===================================================================
> 
> this part I am not clear about.

Ok, Ok. I thought about this a lot. I think I made the best decision and
can describe why.

A few assumptions are in order. In order to get the fullname (abs path) 
to a file, GDB need's three things. The directory the file was compiled 
in (dirname), the filename in question (filename) and a list of paths 
to search.

> There is already a function called source_full_path_of() would it help
> if you used it?

The function source_full_path_of does not take into account 'dirname'.
It calls openp, which is not capable of finding the fullname of a file,
since it doesn't understand what dirname is. Basically, I don't even
think this function (source_full_path_of) is "truly" capable of 
finding the fullpath to a file. However, instead of removing it, 
I left it, since caller's of this function might be using for something 
I know nothing about.

> What is the difference between find_and_open_source and
> open_source_file?  I.e. why did you need to introduce it. I think it's
> not clear just from your comments about the file possibly baing moved
> around.

open_source_file was left around for backwards compatibility. The unit
source.c was used to calling a function, with just passing the symtab,
and getting back the symtab with a valid fullname. I could remove all
occurences of this function and replace it with symtab_to_fullname.

> I am a bit worried about the substitution of symtab_to_filename with
> symtab_to_fullname. The former returns null only if there is no
> symtab.  The latter returns null when there is no symtab OR when it
> cannot find the file. So the behavior is slightly different.

I basically think that the call -file-list-exec-source-files shouldn't 
'cache' it's results. GDB looks for each file, every time it is
requested to get the fullname. This is because, the user could have 
changed the path, or moved/deleted the file. I don't think GDB should
just return the filename instead, of the fullname.

So, if find_and_open_source couldn't "find and open the source file", it
returns NULL. Also, as a side effect, fullname in the [ps]ymtab also
get's set to NULL.

The testsuite didn't seem to have a problem with this, and I think it
makes sense to not trick the caller into having results when it couldn't
find any.

If the caller really wanted this functionality,
  return s->filename; /* File not found.  Just use short name */
I believe it should be the caller's responsibility.

if ( symtab_to_fullname ( s ) == NULL )
   /* use symtab->filename */ 
else
   /* use symtab->fullname */

It doesn't really make sense to return the filename and not state that
it is not really the fullname. Also, if the caller tries to access
s->fullname, it will not be successful, because the file simply isn't
there.

>  > RCS file: /cvs/src/src/gdb/source.c,v
>  > retrieving revision 1.49
>  > diff -w -u -r1.49 source.c
>  > --- gdb/source.c	27 Jan 2004 23:19:51 -0000	1.49
>  > +++ gdb/source.c	25 Feb 2004 03:51:45 -0000
>  > @@ -805,30 +805,47 @@
>  >    return 1;
>  >  }
>  >  
>  > -
>  > -/* Open a source file given a symtab S.  Returns a file descriptor or
>  > -   negative number for error.  */
>  > -
>  > +/* This function is capable of finding the absolute path to a
>  > +   source file, and opening it, provided you give it an 
>  > +   OBJFILE and FILENAME. Both the DIRNAME and FULLNAME are only
>  > +   added suggestions on where to find the file. 
>  > +
>  > +   OBJFILE should be the objfile associated with a psymtab or symtab. 
>  > +   FILENAME should be the filename to open.
>  > +   DIRNAME is the compilation directory of a particular source file.
>  > +           Only some debug formats provide this info.
>  > +   FULLNAME can be the last known absolute path to the file in question.
>  > +
>  > +   On Success 
>  > +     A valid file descriptor is returned. ( the return value is positive )
>  > +     FULLNAME is set to the absolute path to the file just opened.
>  > +
>  > +   On Failure
>  > +     A non valid file descriptor is returned. ( the return value is negitive ) 
>  > +     FULLNAME is set to NULL.  */
>  >  int
>  > -open_source_file (struct symtab *s)
>  > +find_and_open_source ( 
>  > +  struct objfile *objfile,	
>  > +  const char *filename,
>  > +  const char *dirname,
>  > +  char **fullname )
>  >  {
> 
> coding standards....

Ok.

>  >    char *path = source_path;
>  >    const char *p;
>  >    int result;
>  > -  char *fullname;
>  >  
>  >    /* Quick way out if we already know its full name */
>  > -  if (s->fullname)
>  > +  if (*fullname)
>  >      {
>  > -      result = open (s->fullname, OPEN_MODE);
>  > +      result = open (*fullname, OPEN_MODE);
>  >        if (result >= 0)
>  >  	return result;
>  >        /* Didn't work -- free old one, try again. */
>  > -      xmfree (s->objfile->md, s->fullname);
>  > -      s->fullname = NULL;
>  > +      xmfree (objfile->md, *fullname);
>  > +      *fullname = NULL;
>  >      }
>  >  
>  > -  if (s->dirname != NULL)
>  > +  if (dirname != NULL)
>  >      {
>  >        /* Replace a path entry of  $cdir  with the compilation directory name */
>  >  #define	cdir_len	5
>  > @@ -841,60 +858,102 @@
>  >  	  int len;
>  >  
>  >  	  path = (char *)
>  > -	    alloca (strlen (source_path) + 1 + strlen (s->dirname) + 1);
>  > +	    alloca (strlen (source_path) + 1 + strlen (dirname) + 1);
>  >  	  len = p - source_path;
>  >  	  strncpy (path, source_path, len);	/* Before $cdir */
>  > -	  strcpy (path + len, s->dirname);	/* new stuff */
>  > +	  strcpy (path + len, dirname);	/* new stuff */
>  >  	  strcat (path + len, source_path + len + cdir_len);	/* After $cdir */
>  >  	}
>  >      }
>  >  
>  > -  result = openp (path, 0, s->filename, OPEN_MODE, 0, &s->fullname);
>  > +  result = openp (path, 0, filename, OPEN_MODE, 0, fullname);
>  >    if (result < 0)
>  >      {
>  >        /* Didn't work.  Try using just the basename. */
>  > -      p = lbasename (s->filename);
>  > -      if (p != s->filename)
>  > -	result = openp (path, 0, p, OPEN_MODE, 0, &s->fullname);
>  > +      p = lbasename (filename);
>  > +      if (p != filename)
>  > +	result = openp (path, 0, p, OPEN_MODE, 0, fullname);
>  >      }
>  >  
>  >    if (result >= 0)
>  >      {
>  > -      fullname = s->fullname;
>  > -      s->fullname = mstrsave (s->objfile->md, s->fullname);
>  > -      xfree (fullname);
>  > +      char *tmp_fullname;
>  > +      tmp_fullname = *fullname;
>  > +      *fullname = mstrsave (objfile->md, *fullname);
>  > +      xfree (tmp_fullname);
>  >      }
>  >    return result;
>  >  }
>  >  
>  > -/* Return the path to the source file associated with symtab.  Returns NULL
>  > -   if no symtab.  */
>  > +/* Open a source file given a symtab S.  Returns a file descriptor or
>  > +   negative number for error.  
>  > +   
>  > +   This function is a convience function to find_and_open_source. */
>  > +
>  > +int
>  > +open_source_file (struct symtab *s)
>  > +{
>  > +    if (!s)
>  > +      return -1;
>  > +
>  > +    return find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname );
>  > +}
>  > +
>  > +/* Finds the fullname that a symtab represents.
>  > +
>  > +   If this functions finds the fullname, it will save it in ps->fullname
>  > +   and it will also return the value.
>  >  
>  > +   If this function fails to find the file that this symtab represents,
>  > +   NULL will be returned and ps->fullname will be set to NULL.  */
>  >  char *
>  > -symtab_to_filename (struct symtab *s)
>  > +symtab_to_fullname (struct symtab *s)
>  >  {
>  > -  int fd;
>  > +  int r;
>  >  
>  >    if (!s)
>  >      return NULL;
>  >  
>  > -  /* If we've seen the file before, just return fullname. */
>  > +  /* Don't check s->fullname here, the file could have been 
>  > +     deleted/moved/..., look for it again */
>  > +  r = find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname);
>  >  
>  > -  if (s->fullname)
>  > +  if (r)
>  > +  {
>  > +    close (r);
>  >      return s->fullname;
>  > +  }
>  >  
>  > -  /* Try opening the file to setup fullname */
>  > +  return NULL;
>  > +}
>  >  
>  > -  fd = open_source_file (s);
>  > -  if (fd < 0)
>  > -    return s->filename;		/* File not found.  Just use short name */
>  > +/* Finds the fullname that a partial_symtab represents.
>  >  
>  > -  /* Found the file.  Cleanup and return the full name */
>  > +   If this functions finds the fullname, it will save it in ps->fullname
>  > +   and it will also return the value.
>  >  
>  > -  close (fd);
>  > -  return s->fullname;
>  > +   If this function fails to find the file that this partial_symtab represents,
>  > +   NULL will be returned and ps->fullname will be set to NULL.  */
>  > +char *
>  > +psymtab_to_fullname (struct partial_symtab *ps)
>  > +{
>  > +  int r;
>  > +
>  > +  if (!ps)
>  > +    return NULL;
>  > +
>  > +  /* Don't check ps->fullname here, the file could have been
>  > +     deleted/moved/..., look for it again */
>  > +  r = find_and_open_source ( ps->objfile, ps->filename, ps->dirname, &ps->fullname);
>  > +
>  > +  if (r) 
>  > +  {
>  > +    close (r);
>  > +    return ps->fullname;
>  >  }
>  >  \f
>  > +  return NULL;
>  > +}
>  >  
>  >  /* Create and initialize the table S->line_charpos that records
>  >     the positions of the lines in the source file, which is assumed
> 
> 
> 
>  > Index: gdb/source.h
>  > ===================================================================
>  > Index: gdb/symtab.c
>  > ===================================================================
> 
> These are obvious if the rest goes in.
> 
> 
>  > Index: gdb/symtab.h
>  > ===================================================================
> 
> OK.
> 
> 
>  > Index: gdb/mi/mi-cmd-file.c
>  > ===================================================================
> 
> 
>  > +static const char * const FILENAME = "filename";
>  > +static const char * const FULLNAME = "fullname";
> 
> I don't think these are necessary.

It just unifies the output convention I am using in the
mi-cmd-file unit. What would you prefer to see?

>  >  
>  >  /* Return to the client the absolute path and line number of the 
>  >     current file being executed. */
>  > @@ -39,7 +43,6 @@
>  >    if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_file", argc, argv) )
>  >      error ("mi_cmd_file_list_exec_source_file: Usage: No args");
>  >  
>  > -  
>  >    /* Set the default file and line, also get them */
>  >    set_default_source_symtab_and_line();
>  >    st = get_current_source_symtab_and_line();
>  > @@ -51,17 +54,67 @@
>  >      error ("mi_cmd_file_list_exec_source_file: No symtab");
>  >  
>  >    /* Extract the fullname if it is not known yet */
>  > -  if (st.symtab->fullname == NULL)
>  > -    symtab_to_filename (st.symtab);
>  > -
>  > -  /* We may not be able to open the file (not available). */
>  > -  if (st.symtab->fullname == NULL)
>  > -    error ("mi_cmd_file_list_exec_source_file: File not found");
> 
> Why get rid of the error message?

Ok.

>  > +  symtab_to_fullname (st.symtab);
>  >  
>  >    /* Print to the user the line, filename and fullname */
>  >    ui_out_field_int (uiout, "line", st.line);
>  > -  ui_out_field_string (uiout, "file", st.symtab->filename);
>  > -  ui_out_field_string (uiout, "fullname", st.symtab->fullname);
>  > +  ui_out_field_string (uiout, FILENAME, st.symtab->filename);
>  > +  
>  > +  /* We may not be able to open the file (not available). */
>  > +  if (st.symtab->fullname)
>  > +    ui_out_field_string (uiout, FULLNAME, st.symtab->fullname);
>  > +
> 
> if this test fails shouldn't some warning/error be issued?

I don't know. I am thinking that GDB should just return the absolute
path to all of the source files it can find. If it can not find some,
should it issue a warning? That way the front end could say, "you need
to add a directory to the source search path".

>  > +  return MI_CMD_DONE;
>  > +}
>  > +
>  > +enum mi_cmd_result
>  > +mi_cmd_file_list_exec_source_files(char *command, char **argv, int argc)
>  > +{
>  > +  struct symtab *s;
>  > +  struct partial_symtab *ps;
>  > +  struct objfile *objfile;
>  > +
>  > +  if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_files", argc, argv) )
>  > +    error ("mi_cmd_file_list_exec_source_files: Usage: No args");
>  > +
>  > +  /* Print the table header */
>  > +  ui_out_begin ( uiout, ui_out_type_list, "files");
>  > +
>  > +  /* Look at all of the symtabs */
>  > +  ALL_SYMTABS (objfile, s)
>  > +  {
>  > +    ui_out_begin ( uiout, ui_out_type_tuple, NULL);
>  > +
>  > +    ui_out_field_string (uiout, FILENAME, s->filename);
>  > +
>  > +	/* Extract the fullname if it is not known yet */
>  > +	symtab_to_fullname (s);
>  > +
>  > +	if (s->fullname)
>  > +      ui_out_field_string (uiout, FULLNAME, s->fullname);
>  > +
>  > +    ui_out_end ( uiout, ui_out_type_tuple );
>  > +  }
>  > +
>  > +  /* Look at all of the psymtabs */
>  > +  ALL_PSYMTABS (objfile, ps)
>  > +  {
>  > +    if (!ps->readin) {
> 
> coding standards....

Ok.

>  > +      ui_out_begin ( uiout, ui_out_type_tuple, NULL);
>  > +
>  > +      ui_out_field_string (uiout, FILENAME, ps->filename);
>  > +
>  > +      /* Extract the fullname if it is not known yet */
>  > +	  psymtab_to_fullname (ps);
>  > +
>  > +	  if (ps->fullname) 
>  > +	    ui_out_field_string (uiout, FULLNAME, ps->fullname);
>  > +
>  > +      ui_out_end ( uiout, ui_out_type_tuple );
>  > +    }
>  > +  }
>  > +
>  > +  ui_out_end ( uiout, ui_out_type_list );
>  >  
>  >    return MI_CMD_DONE;
>  >  }
> 
> 
> 
>  > Index: gdb/mi/mi-cmds.c
>  > ===================================================================
> 
>  > Index: gdb/mi/mi-cmds.h
>  > ===================================================================
> 
> these changes are ok.

Great!

>  > Index: gdb/testsuite/gdb.mi/mi-file.exp
>  > ===================================================================
>  > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-file.exp,v
>  > retrieving revision 1.1
>  > diff -w -u -r1.1 mi-file.exp
>  > --- gdb/testsuite/gdb.mi/mi-file.exp	2 Apr 2003 22:10:35 -0000	1.1
>  > +++ gdb/testsuite/gdb.mi/mi-file.exp	25 Feb 2004 03:52:36 -0000
>  > @@ -55,7 +55,7 @@
>  >  
>  >      # get the path and absolute path to the current executable
>  >      mi_gdb_test "111-file-list-exec-source-file" \
>  > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
>  > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> 
> Wouldn't this break existing MI parsers?

Yes. I figured it could be mi2. Also, for some reason, I thought no one
would be using this function since I wrote it for CGDB, and I haven't
used it yet. I have a larger plan in mind for MI, than just these 2
commands (-file-list-exec-source-file and -file-list-exec-source-files).
I would like to add the fullname to a lot of commands. However, I think
'filename' and 'fullname' should be standardized, so that front end
writers immediatly understand what they are. It is awkard to have 1
function say "file=" and another say "filename=", when those 2 words
mean the same thing. 

However, if this changes isn't acceptable, I can change it back.

>  >                 "request path info of current source file (${srcfile})"
>  >  }
>  >  
>  > Index: gdb/testsuite/gdb.mi/mi2-file.exp
>  > ===================================================================
>  > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi2-file.exp,v
>  > retrieving revision 1.1
>  > diff -w -u -r1.1 mi2-file.exp
>  > --- gdb/testsuite/gdb.mi/mi2-file.exp	7 Aug 2003 17:47:42 -0000	1.1
>  > +++ gdb/testsuite/gdb.mi/mi2-file.exp	25 Feb 2004 03:52:36 -0000
>  > @@ -47,7 +47,7 @@
>  >  mi_gdb_reinitialize_dir $srcdir/$subdir
>  >  mi_gdb_load ${binfile}
>  >  
>  > -proc test_tbreak_creation_and_listing {} {
>  > +proc test_file_list_exec_source_file {} {
>  >      global srcfile
>  >      global srcdir
>  >      global subdir
>  > @@ -55,11 +55,21 @@
>  >  
>  >      # get the path and absolute path to the current executable
>  >      mi_gdb_test "111-file-list-exec-source-file" \
>  > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
>  > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
>  >                 "request path info of current source file (${srcfile})"
>  >  }
>  >  
>  > -test_tbreak_creation_and_listing
>  > +proc test_file_list_exec_source_files {} {
>  > +    global srcfile
>  > +
>  > +    # get the path and absolute path to the current executable
>  > +    mi_gdb_test "222-file-list-exec-source-files" \
>  > +	    "222\\\^done,files=\\\[\{filename=\".*/${srcfile}\",fullname=\"/.*/${srcfile}\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\}\\\]" \
> 
>  > +              "Getting a list of source files failed."
>                                                  ^^^^^^^
>                                                   why failed?

OOO, That isn't an error condition, it's just a comment. I see.

Thanks,
Bob Rossi

Re: -file-list-exec-source-files

[Bob Rossi]

Elena, thanks for taking the time to review my patch.

When is a good point to resubmit a patch? After every review, or after
all the issues are ironed out?

>  > Here is an initial patch for -file-list-exec-source-files.
>  > Some feedback would be appreciated.
>  > 
>  > I ran the testsuite and the results are the same before and after this
>  > patch.
>  > 
>  > Index: gdb/ChangeLog
>  > 	* dbxread.c (read_dbx_symtab): set pst->dirname when known
> 
> Each entry should start with capital letter and end with period.
> 
> I see some coding standards are not adhered to throughout the code.
> Most noticeably "foo ( int a )" should be "foo (int a)". Similarly for
> calls.

Ok, I will try to fix all of the coding standard errors. Is there a
program I can run on the source files before I create the diff that
formats the code according to the standard?

> 
>  > 
>  > Index: gdb/dbxread.c
>  > ===================================================================
>  > Index: gdb/dwarf2read.c
>  > ===================================================================
> 
> These are ok

Great!

>  >  
>  > Index: gdb/defs.h
>  > ===================================================================
>  > RCS file: /cvs/src/src/gdb/defs.h,v
>  > retrieving revision 1.143
>  > diff -w -u -r1.143 defs.h
>  > --- gdb/defs.h	23 Feb 2004 19:26:14 -0000	1.143
>  > +++ gdb/defs.h	25 Feb 2004 03:51:35 -0000
>  > @@ -616,8 +616,6 @@
>  >  
>  >  extern void init_last_source_visited (void);
>  >  
>  > -extern char *symtab_to_filename (struct symtab *);
>  > -
>  >  /* From exec.c */
>  >  
>  >  extern void exec_set_section_offsets (bfd_signed_vma text_off,
>  > Index: gdb/dwarf2read.c
>  > ===================================================================
>  > RCS file: /cvs/src/src/gdb/dwarf2read.c,v
>  > retrieving revision 1.135
>  > diff -w -u -r1.135 dwarf2read.c
>  > --- gdb/dwarf2read.c	21 Feb 2004 02:13:35 -0000	1.135
>  > +++ gdb/dwarf2read.c	25 Feb 2004 03:51:43 -0000
>  > @@ -316,6 +316,7 @@
>  >      unsigned int offset;
>  >      unsigned int abbrev;
>  >      char *name;
>  > +    char *dirname;
>  >      int has_pc_info;
>  >      CORE_ADDR lowpc;
>  >      CORE_ADDR highpc;
>  > @@ -1254,6 +1255,8 @@
>  >  				  objfile->global_psymbols.next,
>  >  				  objfile->static_psymbols.next);
>  >  
>  > +      pst->dirname = xstrdup ( comp_unit_die.dirname );
>  > +
>  >        pst->read_symtab_private = (char *)
>  >  	obstack_alloc (&objfile->objfile_obstack, sizeof (struct dwarf2_pinfo));
>  >        DWARF_INFO_BUFFER (pst) = dwarf_info_buffer;
>  > @@ -4326,6 +4329,10 @@
>  >  	  /* Prefer DW_AT_MIPS_linkage_name over DW_AT_name.  */
>  >  	  if (part_die->name == NULL)
>  >  	    part_die->name = DW_STRING (&attr);
>  > +	  break;
>  > +	case DW_AT_comp_dir:
>  > +	  if (part_die->dirname == NULL)
>  > +	    part_die->dirname = DW_STRING (&attr);
> 
> The dwarf2 specs say that the name is in the form ":pathname" or
> "hostname:pathname". Should we worry about the hostname? Does gcc emit
> that?  I have looked at a few executables and didn't see the hostname
> part.

It would probably just be best if you told me what case's you want me to
implement here. It seems that Jason Molenda understodd most of the
cases. I really don't know anything about what GCC emits and would would
be practical to implement.

>  > Index: gdb/source.c
>  > ===================================================================
> 
> this part I am not clear about.

Ok, Ok. I thought about this a lot. I think I made the best decision and
can describe why.

A few assumptions are in order. In order to get the fullname (abs path) 
to a file, GDB need's three things. The directory the file was compiled 
in (dirname), the filename in question (filename) and a list of paths 
to search.

> There is already a function called source_full_path_of() would it help
> if you used it?

The function source_full_path_of does not take into account 'dirname'.
It calls openp, which is not capable of finding the fullname of a file,
since it doesn't understand what dirname is. Basically, I don't even
think this function (source_full_path_of) is "truly" capable of 
finding the fullpath to a file. However, instead of removing it, 
I left it, since caller's of this function might be using for something 
I know nothing about.

> What is the difference between find_and_open_source and
> open_source_file?  I.e. why did you need to introduce it. I think it's
> not clear just from your comments about the file possibly baing moved
> around.

open_source_file was left around for backwards compatibility. The unit
source.c was used to calling a function, with just passing the symtab,
and getting back the symtab with a valid fullname. I could remove all
occurences of this function and replace it with symtab_to_fullname.

> I am a bit worried about the substitution of symtab_to_filename with
> symtab_to_fullname. The former returns null only if there is no
> symtab.  The latter returns null when there is no symtab OR when it
> cannot find the file. So the behavior is slightly different.

I basically think that the call -file-list-exec-source-files shouldn't 
'cache' it's results. GDB looks for each file, every time it is
requested to get the fullname. This is because, the user could have 
changed the path, or moved/deleted the file. I don't think GDB should
just return the filename instead, of the fullname.

So, if find_and_open_source couldn't "find and open the source file", it
returns NULL. Also, as a side effect, fullname in the [ps]ymtab also
get's set to NULL.

The testsuite didn't seem to have a problem with this, and I think it
makes sense to not trick the caller into having results when it couldn't
find any.

If the caller really wanted this functionality,
  return s->filename; /* File not found.  Just use short name */
I believe it should be the caller's responsibility.

if ( symtab_to_fullname ( s ) == NULL )
   /* use symtab->filename */ 
else
   /* use symtab->fullname */

It doesn't really make sense to return the filename and not state that
it is not really the fullname. Also, if the caller tries to access
s->fullname, it will not be successful, because the file simply isn't
there.

>  > RCS file: /cvs/src/src/gdb/source.c,v
>  > retrieving revision 1.49
>  > diff -w -u -r1.49 source.c
>  > --- gdb/source.c	27 Jan 2004 23:19:51 -0000	1.49
>  > +++ gdb/source.c	25 Feb 2004 03:51:45 -0000
>  > @@ -805,30 +805,47 @@
>  >    return 1;
>  >  }
>  >  
>  > -
>  > -/* Open a source file given a symtab S.  Returns a file descriptor or
>  > -   negative number for error.  */
>  > -
>  > +/* This function is capable of finding the absolute path to a
>  > +   source file, and opening it, provided you give it an 
>  > +   OBJFILE and FILENAME. Both the DIRNAME and FULLNAME are only
>  > +   added suggestions on where to find the file. 
>  > +
>  > +   OBJFILE should be the objfile associated with a psymtab or symtab. 
>  > +   FILENAME should be the filename to open.
>  > +   DIRNAME is the compilation directory of a particular source file.
>  > +           Only some debug formats provide this info.
>  > +   FULLNAME can be the last known absolute path to the file in question.
>  > +
>  > +   On Success 
>  > +     A valid file descriptor is returned. ( the return value is positive )
>  > +     FULLNAME is set to the absolute path to the file just opened.
>  > +
>  > +   On Failure
>  > +     A non valid file descriptor is returned. ( the return value is negitive ) 
>  > +     FULLNAME is set to NULL.  */
>  >  int
>  > -open_source_file (struct symtab *s)
>  > +find_and_open_source ( 
>  > +  struct objfile *objfile,	
>  > +  const char *filename,
>  > +  const char *dirname,
>  > +  char **fullname )
>  >  {
> 
> coding standards....

Ok.

>  >    char *path = source_path;
>  >    const char *p;
>  >    int result;
>  > -  char *fullname;
>  >  
>  >    /* Quick way out if we already know its full name */
>  > -  if (s->fullname)
>  > +  if (*fullname)
>  >      {
>  > -      result = open (s->fullname, OPEN_MODE);
>  > +      result = open (*fullname, OPEN_MODE);
>  >        if (result >= 0)
>  >  	return result;
>  >        /* Didn't work -- free old one, try again. */
>  > -      xmfree (s->objfile->md, s->fullname);
>  > -      s->fullname = NULL;
>  > +      xmfree (objfile->md, *fullname);
>  > +      *fullname = NULL;
>  >      }
>  >  
>  > -  if (s->dirname != NULL)
>  > +  if (dirname != NULL)
>  >      {
>  >        /* Replace a path entry of  $cdir  with the compilation directory name */
>  >  #define	cdir_len	5
>  > @@ -841,60 +858,102 @@
>  >  	  int len;
>  >  
>  >  	  path = (char *)
>  > -	    alloca (strlen (source_path) + 1 + strlen (s->dirname) + 1);
>  > +	    alloca (strlen (source_path) + 1 + strlen (dirname) + 1);
>  >  	  len = p - source_path;
>  >  	  strncpy (path, source_path, len);	/* Before $cdir */
>  > -	  strcpy (path + len, s->dirname);	/* new stuff */
>  > +	  strcpy (path + len, dirname);	/* new stuff */
>  >  	  strcat (path + len, source_path + len + cdir_len);	/* After $cdir */
>  >  	}
>  >      }
>  >  
>  > -  result = openp (path, 0, s->filename, OPEN_MODE, 0, &s->fullname);
>  > +  result = openp (path, 0, filename, OPEN_MODE, 0, fullname);
>  >    if (result < 0)
>  >      {
>  >        /* Didn't work.  Try using just the basename. */
>  > -      p = lbasename (s->filename);
>  > -      if (p != s->filename)
>  > -	result = openp (path, 0, p, OPEN_MODE, 0, &s->fullname);
>  > +      p = lbasename (filename);
>  > +      if (p != filename)
>  > +	result = openp (path, 0, p, OPEN_MODE, 0, fullname);
>  >      }
>  >  
>  >    if (result >= 0)
>  >      {
>  > -      fullname = s->fullname;
>  > -      s->fullname = mstrsave (s->objfile->md, s->fullname);
>  > -      xfree (fullname);
>  > +      char *tmp_fullname;
>  > +      tmp_fullname = *fullname;
>  > +      *fullname = mstrsave (objfile->md, *fullname);
>  > +      xfree (tmp_fullname);
>  >      }
>  >    return result;
>  >  }
>  >  
>  > -/* Return the path to the source file associated with symtab.  Returns NULL
>  > -   if no symtab.  */
>  > +/* Open a source file given a symtab S.  Returns a file descriptor or
>  > +   negative number for error.  
>  > +   
>  > +   This function is a convience function to find_and_open_source. */
>  > +
>  > +int
>  > +open_source_file (struct symtab *s)
>  > +{
>  > +    if (!s)
>  > +      return -1;
>  > +
>  > +    return find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname );
>  > +}
>  > +
>  > +/* Finds the fullname that a symtab represents.
>  > +
>  > +   If this functions finds the fullname, it will save it in ps->fullname
>  > +   and it will also return the value.
>  >  
>  > +   If this function fails to find the file that this symtab represents,
>  > +   NULL will be returned and ps->fullname will be set to NULL.  */
>  >  char *
>  > -symtab_to_filename (struct symtab *s)
>  > +symtab_to_fullname (struct symtab *s)
>  >  {
>  > -  int fd;
>  > +  int r;
>  >  
>  >    if (!s)
>  >      return NULL;
>  >  
>  > -  /* If we've seen the file before, just return fullname. */
>  > +  /* Don't check s->fullname here, the file could have been 
>  > +     deleted/moved/..., look for it again */
>  > +  r = find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname);
>  >  
>  > -  if (s->fullname)
>  > +  if (r)
>  > +  {
>  > +    close (r);
>  >      return s->fullname;
>  > +  }
>  >  
>  > -  /* Try opening the file to setup fullname */
>  > +  return NULL;
>  > +}
>  >  
>  > -  fd = open_source_file (s);
>  > -  if (fd < 0)
>  > -    return s->filename;		/* File not found.  Just use short name */
>  > +/* Finds the fullname that a partial_symtab represents.
>  >  
>  > -  /* Found the file.  Cleanup and return the full name */
>  > +   If this functions finds the fullname, it will save it in ps->fullname
>  > +   and it will also return the value.
>  >  
>  > -  close (fd);
>  > -  return s->fullname;
>  > +   If this function fails to find the file that this partial_symtab represents,
>  > +   NULL will be returned and ps->fullname will be set to NULL.  */
>  > +char *
>  > +psymtab_to_fullname (struct partial_symtab *ps)
>  > +{
>  > +  int r;
>  > +
>  > +  if (!ps)
>  > +    return NULL;
>  > +
>  > +  /* Don't check ps->fullname here, the file could have been
>  > +     deleted/moved/..., look for it again */
>  > +  r = find_and_open_source ( ps->objfile, ps->filename, ps->dirname, &ps->fullname);
>  > +
>  > +  if (r) 
>  > +  {
>  > +    close (r);
>  > +    return ps->fullname;
>  >  }
>  >  \f
>  > +  return NULL;
>  > +}
>  >  
>  >  /* Create and initialize the table S->line_charpos that records
>  >     the positions of the lines in the source file, which is assumed
> 
> 
> 
>  > Index: gdb/source.h
>  > ===================================================================
>  > Index: gdb/symtab.c
>  > ===================================================================
> 
> These are obvious if the rest goes in.
> 
> 
>  > Index: gdb/symtab.h
>  > ===================================================================
> 
> OK.
> 
> 
>  > Index: gdb/mi/mi-cmd-file.c
>  > ===================================================================
> 
> 
>  > +static const char * const FILENAME = "filename";
>  > +static const char * const FULLNAME = "fullname";
> 
> I don't think these are necessary.

It just unifies the output convention I am using in the
mi-cmd-file unit. What would you prefer to see?

>  >  
>  >  /* Return to the client the absolute path and line number of the 
>  >     current file being executed. */
>  > @@ -39,7 +43,6 @@
>  >    if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_file", argc, argv) )
>  >      error ("mi_cmd_file_list_exec_source_file: Usage: No args");
>  >  
>  > -  
>  >    /* Set the default file and line, also get them */
>  >    set_default_source_symtab_and_line();
>  >    st = get_current_source_symtab_and_line();
>  > @@ -51,17 +54,67 @@
>  >      error ("mi_cmd_file_list_exec_source_file: No symtab");
>  >  
>  >    /* Extract the fullname if it is not known yet */
>  > -  if (st.symtab->fullname == NULL)
>  > -    symtab_to_filename (st.symtab);
>  > -
>  > -  /* We may not be able to open the file (not available). */
>  > -  if (st.symtab->fullname == NULL)
>  > -    error ("mi_cmd_file_list_exec_source_file: File not found");
> 
> Why get rid of the error message?

Ok.

>  > +  symtab_to_fullname (st.symtab);
>  >  
>  >    /* Print to the user the line, filename and fullname */
>  >    ui_out_field_int (uiout, "line", st.line);
>  > -  ui_out_field_string (uiout, "file", st.symtab->filename);
>  > -  ui_out_field_string (uiout, "fullname", st.symtab->fullname);
>  > +  ui_out_field_string (uiout, FILENAME, st.symtab->filename);
>  > +  
>  > +  /* We may not be able to open the file (not available). */
>  > +  if (st.symtab->fullname)
>  > +    ui_out_field_string (uiout, FULLNAME, st.symtab->fullname);
>  > +
> 
> if this test fails shouldn't some warning/error be issued?

I don't know. I am thinking that GDB should just return the absolute
path to all of the source files it can find. If it can not find some,
should it issue a warning? That way the front end could say, "you need
to add a directory to the source search path".

>  > +  return MI_CMD_DONE;
>  > +}
>  > +
>  > +enum mi_cmd_result
>  > +mi_cmd_file_list_exec_source_files(char *command, char **argv, int argc)
>  > +{
>  > +  struct symtab *s;
>  > +  struct partial_symtab *ps;
>  > +  struct objfile *objfile;
>  > +
>  > +  if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_files", argc, argv) )
>  > +    error ("mi_cmd_file_list_exec_source_files: Usage: No args");
>  > +
>  > +  /* Print the table header */
>  > +  ui_out_begin ( uiout, ui_out_type_list, "files");
>  > +
>  > +  /* Look at all of the symtabs */
>  > +  ALL_SYMTABS (objfile, s)
>  > +  {
>  > +    ui_out_begin ( uiout, ui_out_type_tuple, NULL);
>  > +
>  > +    ui_out_field_string (uiout, FILENAME, s->filename);
>  > +
>  > +	/* Extract the fullname if it is not known yet */
>  > +	symtab_to_fullname (s);
>  > +
>  > +	if (s->fullname)
>  > +      ui_out_field_string (uiout, FULLNAME, s->fullname);
>  > +
>  > +    ui_out_end ( uiout, ui_out_type_tuple );
>  > +  }
>  > +
>  > +  /* Look at all of the psymtabs */
>  > +  ALL_PSYMTABS (objfile, ps)
>  > +  {
>  > +    if (!ps->readin) {
> 
> coding standards....

Ok.

>  > +      ui_out_begin ( uiout, ui_out_type_tuple, NULL);
>  > +
>  > +      ui_out_field_string (uiout, FILENAME, ps->filename);
>  > +
>  > +      /* Extract the fullname if it is not known yet */
>  > +	  psymtab_to_fullname (ps);
>  > +
>  > +	  if (ps->fullname) 
>  > +	    ui_out_field_string (uiout, FULLNAME, ps->fullname);
>  > +
>  > +      ui_out_end ( uiout, ui_out_type_tuple );
>  > +    }
>  > +  }
>  > +
>  > +  ui_out_end ( uiout, ui_out_type_list );
>  >  
>  >    return MI_CMD_DONE;
>  >  }
> 
> 
> 
>  > Index: gdb/mi/mi-cmds.c
>  > ===================================================================
> 
>  > Index: gdb/mi/mi-cmds.h
>  > ===================================================================
> 
> these changes are ok.

Great!

>  > Index: gdb/testsuite/gdb.mi/mi-file.exp
>  > ===================================================================
>  > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-file.exp,v
>  > retrieving revision 1.1
>  > diff -w -u -r1.1 mi-file.exp
>  > --- gdb/testsuite/gdb.mi/mi-file.exp	2 Apr 2003 22:10:35 -0000	1.1
>  > +++ gdb/testsuite/gdb.mi/mi-file.exp	25 Feb 2004 03:52:36 -0000
>  > @@ -55,7 +55,7 @@
>  >  
>  >      # get the path and absolute path to the current executable
>  >      mi_gdb_test "111-file-list-exec-source-file" \
>  > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
>  > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> 
> Wouldn't this break existing MI parsers?

Yes. I figured it could be mi2. Also, for some reason, I thought no one
would be using this function since I wrote it for CGDB, and I haven't
used it yet. I have a larger plan in mind for MI, than just these 2
commands (-file-list-exec-source-file and -file-list-exec-source-files).
I would like to add the fullname to a lot of commands. However, I think
'filename' and 'fullname' should be standardized, so that front end
writers immediatly understand what they are. It is awkard to have 1
function say "file=" and another say "filename=", when those 2 words
mean the same thing. 

However, if this changes isn't acceptable, I can change it back.

>  >                 "request path info of current source file (${srcfile})"
>  >  }
>  >  
>  > Index: gdb/testsuite/gdb.mi/mi2-file.exp
>  > ===================================================================
>  > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi2-file.exp,v
>  > retrieving revision 1.1
>  > diff -w -u -r1.1 mi2-file.exp
>  > --- gdb/testsuite/gdb.mi/mi2-file.exp	7 Aug 2003 17:47:42 -0000	1.1
>  > +++ gdb/testsuite/gdb.mi/mi2-file.exp	25 Feb 2004 03:52:36 -0000
>  > @@ -47,7 +47,7 @@
>  >  mi_gdb_reinitialize_dir $srcdir/$subdir
>  >  mi_gdb_load ${binfile}
>  >  
>  > -proc test_tbreak_creation_and_listing {} {
>  > +proc test_file_list_exec_source_file {} {
>  >      global srcfile
>  >      global srcdir
>  >      global subdir
>  > @@ -55,11 +55,21 @@
>  >  
>  >      # get the path and absolute path to the current executable
>  >      mi_gdb_test "111-file-list-exec-source-file" \
>  > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
>  > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
>  >                 "request path info of current source file (${srcfile})"
>  >  }
>  >  
>  > -test_tbreak_creation_and_listing
>  > +proc test_file_list_exec_source_files {} {
>  > +    global srcfile
>  > +
>  > +    # get the path and absolute path to the current executable
>  > +    mi_gdb_test "222-file-list-exec-source-files" \
>  > +	    "222\\\^done,files=\\\[\{filename=\".*/${srcfile}\",fullname=\"/.*/${srcfile}\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\}\\\]" \
> 
>  > +              "Getting a list of source files failed."
>                                                  ^^^^^^^
>                                                   why failed?

OOO, That isn't an error condition, it's just a comment. I see.

Thanks,
Bob Rossi

Re: -file-list-exec-source-files

[Bob Rossi]

What do you think?

Bob Rossi

On Sat, Mar 06, 2004 at 10:57:00AM -0500, Bob Rossi wrote:
> Elena, thanks for taking the time to review my patch.
> 
> When is a good point to resubmit a patch? After every review, or after
> all the issues are ironed out?
> 
> >  > Here is an initial patch for -file-list-exec-source-files.
> >  > Some feedback would be appreciated.
> >  > 
> >  > I ran the testsuite and the results are the same before and after this
> >  > patch.
> >  > 
> >  > Index: gdb/ChangeLog
> >  > 	* dbxread.c (read_dbx_symtab): set pst->dirname when known
> > 
> > Each entry should start with capital letter and end with period.
> > 
> > I see some coding standards are not adhered to throughout the code.
> > Most noticeably "foo ( int a )" should be "foo (int a)". Similarly for
> > calls.
> 
> Ok, I will try to fix all of the coding standard errors. Is there a
> program I can run on the source files before I create the diff that
> formats the code according to the standard?
> 
> > 
> >  > 
> >  > Index: gdb/dbxread.c
> >  > ===================================================================
> >  > Index: gdb/dwarf2read.c
> >  > ===================================================================
> > 
> > These are ok
> 
> Great!
> 
> >  >  
> >  > Index: gdb/defs.h
> >  > ===================================================================
> >  > RCS file: /cvs/src/src/gdb/defs.h,v
> >  > retrieving revision 1.143
> >  > diff -w -u -r1.143 defs.h
> >  > --- gdb/defs.h	23 Feb 2004 19:26:14 -0000	1.143
> >  > +++ gdb/defs.h	25 Feb 2004 03:51:35 -0000
> >  > @@ -616,8 +616,6 @@
> >  >  
> >  >  extern void init_last_source_visited (void);
> >  >  
> >  > -extern char *symtab_to_filename (struct symtab *);
> >  > -
> >  >  /* From exec.c */
> >  >  
> >  >  extern void exec_set_section_offsets (bfd_signed_vma text_off,
> >  > Index: gdb/dwarf2read.c
> >  > ===================================================================
> >  > RCS file: /cvs/src/src/gdb/dwarf2read.c,v
> >  > retrieving revision 1.135
> >  > diff -w -u -r1.135 dwarf2read.c
> >  > --- gdb/dwarf2read.c	21 Feb 2004 02:13:35 -0000	1.135
> >  > +++ gdb/dwarf2read.c	25 Feb 2004 03:51:43 -0000
> >  > @@ -316,6 +316,7 @@
> >  >      unsigned int offset;
> >  >      unsigned int abbrev;
> >  >      char *name;
> >  > +    char *dirname;
> >  >      int has_pc_info;
> >  >      CORE_ADDR lowpc;
> >  >      CORE_ADDR highpc;
> >  > @@ -1254,6 +1255,8 @@
> >  >  				  objfile->global_psymbols.next,
> >  >  				  objfile->static_psymbols.next);
> >  >  
> >  > +      pst->dirname = xstrdup ( comp_unit_die.dirname );
> >  > +
> >  >        pst->read_symtab_private = (char *)
> >  >  	obstack_alloc (&objfile->objfile_obstack, sizeof (struct dwarf2_pinfo));
> >  >        DWARF_INFO_BUFFER (pst) = dwarf_info_buffer;
> >  > @@ -4326,6 +4329,10 @@
> >  >  	  /* Prefer DW_AT_MIPS_linkage_name over DW_AT_name.  */
> >  >  	  if (part_die->name == NULL)
> >  >  	    part_die->name = DW_STRING (&attr);
> >  > +	  break;
> >  > +	case DW_AT_comp_dir:
> >  > +	  if (part_die->dirname == NULL)
> >  > +	    part_die->dirname = DW_STRING (&attr);
> > 
> > The dwarf2 specs say that the name is in the form ":pathname" or
> > "hostname:pathname". Should we worry about the hostname? Does gcc emit
> > that?  I have looked at a few executables and didn't see the hostname
> > part.
> 
> It would probably just be best if you told me what case's you want me to
> implement here. It seems that Jason Molenda understodd most of the
> cases. I really don't know anything about what GCC emits and would would
> be practical to implement.
> 
> >  > Index: gdb/source.c
> >  > ===================================================================
> > 
> > this part I am not clear about.
> 
> Ok, Ok. I thought about this a lot. I think I made the best decision and
> can describe why.
> 
> A few assumptions are in order. In order to get the fullname (abs path) 
> to a file, GDB need's three things. The directory the file was compiled 
> in (dirname), the filename in question (filename) and a list of paths 
> to search.
> 
> > There is already a function called source_full_path_of() would it help
> > if you used it?
> 
> The function source_full_path_of does not take into account 'dirname'.
> It calls openp, which is not capable of finding the fullname of a file,
> since it doesn't understand what dirname is. Basically, I don't even
> think this function (source_full_path_of) is "truly" capable of 
> finding the fullpath to a file. However, instead of removing it, 
> I left it, since caller's of this function might be using for something 
> I know nothing about.
> 
> > What is the difference between find_and_open_source and
> > open_source_file?  I.e. why did you need to introduce it. I think it's
> > not clear just from your comments about the file possibly baing moved
> > around.
> 
> open_source_file was left around for backwards compatibility. The unit
> source.c was used to calling a function, with just passing the symtab,
> and getting back the symtab with a valid fullname. I could remove all
> occurences of this function and replace it with symtab_to_fullname.
> 
> > I am a bit worried about the substitution of symtab_to_filename with
> > symtab_to_fullname. The former returns null only if there is no
> > symtab.  The latter returns null when there is no symtab OR when it
> > cannot find the file. So the behavior is slightly different.
> 
> I basically think that the call -file-list-exec-source-files shouldn't 
> 'cache' it's results. GDB looks for each file, every time it is
> requested to get the fullname. This is because, the user could have 
> changed the path, or moved/deleted the file. I don't think GDB should
> just return the filename instead, of the fullname.
> 
> So, if find_and_open_source couldn't "find and open the source file", it
> returns NULL. Also, as a side effect, fullname in the [ps]ymtab also
> get's set to NULL.
> 
> The testsuite didn't seem to have a problem with this, and I think it
> makes sense to not trick the caller into having results when it couldn't
> find any.
> 
> If the caller really wanted this functionality,
>   return s->filename; /* File not found.  Just use short name */
> I believe it should be the caller's responsibility.
> 
> if ( symtab_to_fullname ( s ) == NULL )
>    /* use symtab->filename */ 
> else
>    /* use symtab->fullname */
> 
> It doesn't really make sense to return the filename and not state that
> it is not really the fullname. Also, if the caller tries to access
> s->fullname, it will not be successful, because the file simply isn't
> there.
> 
> >  > RCS file: /cvs/src/src/gdb/source.c,v
> >  > retrieving revision 1.49
> >  > diff -w -u -r1.49 source.c
> >  > --- gdb/source.c	27 Jan 2004 23:19:51 -0000	1.49
> >  > +++ gdb/source.c	25 Feb 2004 03:51:45 -0000
> >  > @@ -805,30 +805,47 @@
> >  >    return 1;
> >  >  }
> >  >  
> >  > -
> >  > -/* Open a source file given a symtab S.  Returns a file descriptor or
> >  > -   negative number for error.  */
> >  > -
> >  > +/* This function is capable of finding the absolute path to a
> >  > +   source file, and opening it, provided you give it an 
> >  > +   OBJFILE and FILENAME. Both the DIRNAME and FULLNAME are only
> >  > +   added suggestions on where to find the file. 
> >  > +
> >  > +   OBJFILE should be the objfile associated with a psymtab or symtab. 
> >  > +   FILENAME should be the filename to open.
> >  > +   DIRNAME is the compilation directory of a particular source file.
> >  > +           Only some debug formats provide this info.
> >  > +   FULLNAME can be the last known absolute path to the file in question.
> >  > +
> >  > +   On Success 
> >  > +     A valid file descriptor is returned. ( the return value is positive )
> >  > +     FULLNAME is set to the absolute path to the file just opened.
> >  > +
> >  > +   On Failure
> >  > +     A non valid file descriptor is returned. ( the return value is negitive ) 
> >  > +     FULLNAME is set to NULL.  */
> >  >  int
> >  > -open_source_file (struct symtab *s)
> >  > +find_and_open_source ( 
> >  > +  struct objfile *objfile,	
> >  > +  const char *filename,
> >  > +  const char *dirname,
> >  > +  char **fullname )
> >  >  {
> > 
> > coding standards....
> 
> Ok.
> 
> >  >    char *path = source_path;
> >  >    const char *p;
> >  >    int result;
> >  > -  char *fullname;
> >  >  
> >  >    /* Quick way out if we already know its full name */
> >  > -  if (s->fullname)
> >  > +  if (*fullname)
> >  >      {
> >  > -      result = open (s->fullname, OPEN_MODE);
> >  > +      result = open (*fullname, OPEN_MODE);
> >  >        if (result >= 0)
> >  >  	return result;
> >  >        /* Didn't work -- free old one, try again. */
> >  > -      xmfree (s->objfile->md, s->fullname);
> >  > -      s->fullname = NULL;
> >  > +      xmfree (objfile->md, *fullname);
> >  > +      *fullname = NULL;
> >  >      }
> >  >  
> >  > -  if (s->dirname != NULL)
> >  > +  if (dirname != NULL)
> >  >      {
> >  >        /* Replace a path entry of  $cdir  with the compilation directory name */
> >  >  #define	cdir_len	5
> >  > @@ -841,60 +858,102 @@
> >  >  	  int len;
> >  >  
> >  >  	  path = (char *)
> >  > -	    alloca (strlen (source_path) + 1 + strlen (s->dirname) + 1);
> >  > +	    alloca (strlen (source_path) + 1 + strlen (dirname) + 1);
> >  >  	  len = p - source_path;
> >  >  	  strncpy (path, source_path, len);	/* Before $cdir */
> >  > -	  strcpy (path + len, s->dirname);	/* new stuff */
> >  > +	  strcpy (path + len, dirname);	/* new stuff */
> >  >  	  strcat (path + len, source_path + len + cdir_len);	/* After $cdir */
> >  >  	}
> >  >      }
> >  >  
> >  > -  result = openp (path, 0, s->filename, OPEN_MODE, 0, &s->fullname);
> >  > +  result = openp (path, 0, filename, OPEN_MODE, 0, fullname);
> >  >    if (result < 0)
> >  >      {
> >  >        /* Didn't work.  Try using just the basename. */
> >  > -      p = lbasename (s->filename);
> >  > -      if (p != s->filename)
> >  > -	result = openp (path, 0, p, OPEN_MODE, 0, &s->fullname);
> >  > +      p = lbasename (filename);
> >  > +      if (p != filename)
> >  > +	result = openp (path, 0, p, OPEN_MODE, 0, fullname);
> >  >      }
> >  >  
> >  >    if (result >= 0)
> >  >      {
> >  > -      fullname = s->fullname;
> >  > -      s->fullname = mstrsave (s->objfile->md, s->fullname);
> >  > -      xfree (fullname);
> >  > +      char *tmp_fullname;
> >  > +      tmp_fullname = *fullname;
> >  > +      *fullname = mstrsave (objfile->md, *fullname);
> >  > +      xfree (tmp_fullname);
> >  >      }
> >  >    return result;
> >  >  }
> >  >  
> >  > -/* Return the path to the source file associated with symtab.  Returns NULL
> >  > -   if no symtab.  */
> >  > +/* Open a source file given a symtab S.  Returns a file descriptor or
> >  > +   negative number for error.  
> >  > +   
> >  > +   This function is a convience function to find_and_open_source. */
> >  > +
> >  > +int
> >  > +open_source_file (struct symtab *s)
> >  > +{
> >  > +    if (!s)
> >  > +      return -1;
> >  > +
> >  > +    return find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname );
> >  > +}
> >  > +
> >  > +/* Finds the fullname that a symtab represents.
> >  > +
> >  > +   If this functions finds the fullname, it will save it in ps->fullname
> >  > +   and it will also return the value.
> >  >  
> >  > +   If this function fails to find the file that this symtab represents,
> >  > +   NULL will be returned and ps->fullname will be set to NULL.  */
> >  >  char *
> >  > -symtab_to_filename (struct symtab *s)
> >  > +symtab_to_fullname (struct symtab *s)
> >  >  {
> >  > -  int fd;
> >  > +  int r;
> >  >  
> >  >    if (!s)
> >  >      return NULL;
> >  >  
> >  > -  /* If we've seen the file before, just return fullname. */
> >  > +  /* Don't check s->fullname here, the file could have been 
> >  > +     deleted/moved/..., look for it again */
> >  > +  r = find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname);
> >  >  
> >  > -  if (s->fullname)
> >  > +  if (r)
> >  > +  {
> >  > +    close (r);
> >  >      return s->fullname;
> >  > +  }
> >  >  
> >  > -  /* Try opening the file to setup fullname */
> >  > +  return NULL;
> >  > +}
> >  >  
> >  > -  fd = open_source_file (s);
> >  > -  if (fd < 0)
> >  > -    return s->filename;		/* File not found.  Just use short name */
> >  > +/* Finds the fullname that a partial_symtab represents.
> >  >  
> >  > -  /* Found the file.  Cleanup and return the full name */
> >  > +   If this functions finds the fullname, it will save it in ps->fullname
> >  > +   and it will also return the value.
> >  >  
> >  > -  close (fd);
> >  > -  return s->fullname;
> >  > +   If this function fails to find the file that this partial_symtab represents,
> >  > +   NULL will be returned and ps->fullname will be set to NULL.  */
> >  > +char *
> >  > +psymtab_to_fullname (struct partial_symtab *ps)
> >  > +{
> >  > +  int r;
> >  > +
> >  > +  if (!ps)
> >  > +    return NULL;
> >  > +
> >  > +  /* Don't check ps->fullname here, the file could have been
> >  > +     deleted/moved/..., look for it again */
> >  > +  r = find_and_open_source ( ps->objfile, ps->filename, ps->dirname, &ps->fullname);
> >  > +
> >  > +  if (r) 
> >  > +  {
> >  > +    close (r);
> >  > +    return ps->fullname;
> >  >  }
> >  >  \f
> >  > +  return NULL;
> >  > +}
> >  >  
> >  >  /* Create and initialize the table S->line_charpos that records
> >  >     the positions of the lines in the source file, which is assumed
> > 
> > 
> > 
> >  > Index: gdb/source.h
> >  > ===================================================================
> >  > Index: gdb/symtab.c
> >  > ===================================================================
> > 
> > These are obvious if the rest goes in.
> > 
> > 
> >  > Index: gdb/symtab.h
> >  > ===================================================================
> > 
> > OK.
> > 
> > 
> >  > Index: gdb/mi/mi-cmd-file.c
> >  > ===================================================================
> > 
> > 
> >  > +static const char * const FILENAME = "filename";
> >  > +static const char * const FULLNAME = "fullname";
> > 
> > I don't think these are necessary.
> 
> It just unifies the output convention I am using in the
> mi-cmd-file unit. What would you prefer to see?
> 
> >  >  
> >  >  /* Return to the client the absolute path and line number of the 
> >  >     current file being executed. */
> >  > @@ -39,7 +43,6 @@
> >  >    if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_file", argc, argv) )
> >  >      error ("mi_cmd_file_list_exec_source_file: Usage: No args");
> >  >  
> >  > -  
> >  >    /* Set the default file and line, also get them */
> >  >    set_default_source_symtab_and_line();
> >  >    st = get_current_source_symtab_and_line();
> >  > @@ -51,17 +54,67 @@
> >  >      error ("mi_cmd_file_list_exec_source_file: No symtab");
> >  >  
> >  >    /* Extract the fullname if it is not known yet */
> >  > -  if (st.symtab->fullname == NULL)
> >  > -    symtab_to_filename (st.symtab);
> >  > -
> >  > -  /* We may not be able to open the file (not available). */
> >  > -  if (st.symtab->fullname == NULL)
> >  > -    error ("mi_cmd_file_list_exec_source_file: File not found");
> > 
> > Why get rid of the error message?
> 
> Ok.
> 
> >  > +  symtab_to_fullname (st.symtab);
> >  >  
> >  >    /* Print to the user the line, filename and fullname */
> >  >    ui_out_field_int (uiout, "line", st.line);
> >  > -  ui_out_field_string (uiout, "file", st.symtab->filename);
> >  > -  ui_out_field_string (uiout, "fullname", st.symtab->fullname);
> >  > +  ui_out_field_string (uiout, FILENAME, st.symtab->filename);
> >  > +  
> >  > +  /* We may not be able to open the file (not available). */
> >  > +  if (st.symtab->fullname)
> >  > +    ui_out_field_string (uiout, FULLNAME, st.symtab->fullname);
> >  > +
> > 
> > if this test fails shouldn't some warning/error be issued?
> 
> I don't know. I am thinking that GDB should just return the absolute
> path to all of the source files it can find. If it can not find some,
> should it issue a warning? That way the front end could say, "you need
> to add a directory to the source search path".
> 
> >  > +  return MI_CMD_DONE;
> >  > +}
> >  > +
> >  > +enum mi_cmd_result
> >  > +mi_cmd_file_list_exec_source_files(char *command, char **argv, int argc)
> >  > +{
> >  > +  struct symtab *s;
> >  > +  struct partial_symtab *ps;
> >  > +  struct objfile *objfile;
> >  > +
> >  > +  if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_files", argc, argv) )
> >  > +    error ("mi_cmd_file_list_exec_source_files: Usage: No args");
> >  > +
> >  > +  /* Print the table header */
> >  > +  ui_out_begin ( uiout, ui_out_type_list, "files");
> >  > +
> >  > +  /* Look at all of the symtabs */
> >  > +  ALL_SYMTABS (objfile, s)
> >  > +  {
> >  > +    ui_out_begin ( uiout, ui_out_type_tuple, NULL);
> >  > +
> >  > +    ui_out_field_string (uiout, FILENAME, s->filename);
> >  > +
> >  > +	/* Extract the fullname if it is not known yet */
> >  > +	symtab_to_fullname (s);
> >  > +
> >  > +	if (s->fullname)
> >  > +      ui_out_field_string (uiout, FULLNAME, s->fullname);
> >  > +
> >  > +    ui_out_end ( uiout, ui_out_type_tuple );
> >  > +  }
> >  > +
> >  > +  /* Look at all of the psymtabs */
> >  > +  ALL_PSYMTABS (objfile, ps)
> >  > +  {
> >  > +    if (!ps->readin) {
> > 
> > coding standards....
> 
> Ok.
> 
> >  > +      ui_out_begin ( uiout, ui_out_type_tuple, NULL);
> >  > +
> >  > +      ui_out_field_string (uiout, FILENAME, ps->filename);
> >  > +
> >  > +      /* Extract the fullname if it is not known yet */
> >  > +	  psymtab_to_fullname (ps);
> >  > +
> >  > +	  if (ps->fullname) 
> >  > +	    ui_out_field_string (uiout, FULLNAME, ps->fullname);
> >  > +
> >  > +      ui_out_end ( uiout, ui_out_type_tuple );
> >  > +    }
> >  > +  }
> >  > +
> >  > +  ui_out_end ( uiout, ui_out_type_list );
> >  >  
> >  >    return MI_CMD_DONE;
> >  >  }
> > 
> > 
> > 
> >  > Index: gdb/mi/mi-cmds.c
> >  > ===================================================================
> > 
> >  > Index: gdb/mi/mi-cmds.h
> >  > ===================================================================
> > 
> > these changes are ok.
> 
> Great!
> 
> >  > Index: gdb/testsuite/gdb.mi/mi-file.exp
> >  > ===================================================================
> >  > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-file.exp,v
> >  > retrieving revision 1.1
> >  > diff -w -u -r1.1 mi-file.exp
> >  > --- gdb/testsuite/gdb.mi/mi-file.exp	2 Apr 2003 22:10:35 -0000	1.1
> >  > +++ gdb/testsuite/gdb.mi/mi-file.exp	25 Feb 2004 03:52:36 -0000
> >  > @@ -55,7 +55,7 @@
> >  >  
> >  >      # get the path and absolute path to the current executable
> >  >      mi_gdb_test "111-file-list-exec-source-file" \
> >  > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> >  > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> > 
> > Wouldn't this break existing MI parsers?
> 
> Yes. I figured it could be mi2. Also, for some reason, I thought no one
> would be using this function since I wrote it for CGDB, and I haven't
> used it yet. I have a larger plan in mind for MI, than just these 2
> commands (-file-list-exec-source-file and -file-list-exec-source-files).
> I would like to add the fullname to a lot of commands. However, I think
> 'filename' and 'fullname' should be standardized, so that front end
> writers immediatly understand what they are. It is awkard to have 1
> function say "file=" and another say "filename=", when those 2 words
> mean the same thing. 
> 
> However, if this changes isn't acceptable, I can change it back.
> 
> >  >                 "request path info of current source file (${srcfile})"
> >  >  }
> >  >  
> >  > Index: gdb/testsuite/gdb.mi/mi2-file.exp
> >  > ===================================================================
> >  > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi2-file.exp,v
> >  > retrieving revision 1.1
> >  > diff -w -u -r1.1 mi2-file.exp
> >  > --- gdb/testsuite/gdb.mi/mi2-file.exp	7 Aug 2003 17:47:42 -0000	1.1
> >  > +++ gdb/testsuite/gdb.mi/mi2-file.exp	25 Feb 2004 03:52:36 -0000
> >  > @@ -47,7 +47,7 @@
> >  >  mi_gdb_reinitialize_dir $srcdir/$subdir
> >  >  mi_gdb_load ${binfile}
> >  >  
> >  > -proc test_tbreak_creation_and_listing {} {
> >  > +proc test_file_list_exec_source_file {} {
> >  >      global srcfile
> >  >      global srcdir
> >  >      global subdir
> >  > @@ -55,11 +55,21 @@
> >  >  
> >  >      # get the path and absolute path to the current executable
> >  >      mi_gdb_test "111-file-list-exec-source-file" \
> >  > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> >  > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> >  >                 "request path info of current source file (${srcfile})"
> >  >  }
> >  >  
> >  > -test_tbreak_creation_and_listing
> >  > +proc test_file_list_exec_source_files {} {
> >  > +    global srcfile
> >  > +
> >  > +    # get the path and absolute path to the current executable
> >  > +    mi_gdb_test "222-file-list-exec-source-files" \
> >  > +	    "222\\\^done,files=\\\[\{filename=\".*/${srcfile}\",fullname=\"/.*/${srcfile}\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\}\\\]" \
> > 
> >  > +              "Getting a list of source files failed."
> >                                                  ^^^^^^^
> >                                                   why failed?
> 
> OOO, That isn't an error condition, it's just a comment. I see.
> 
> Thanks,
> Bob Rossi

Re: -file-list-exec-source-files

[Bob Rossi]

What do you think?

Bob Rossi

On Sat, Mar 06, 2004 at 10:57:00AM -0500, Bob Rossi wrote:
> Elena, thanks for taking the time to review my patch.
> 
> When is a good point to resubmit a patch? After every review, or after
> all the issues are ironed out?
> 
> >  > Here is an initial patch for -file-list-exec-source-files.
> >  > Some feedback would be appreciated.
> >  > 
> >  > I ran the testsuite and the results are the same before and after this
> >  > patch.
> >  > 
> >  > Index: gdb/ChangeLog
> >  > 	* dbxread.c (read_dbx_symtab): set pst->dirname when known
> > 
> > Each entry should start with capital letter and end with period.
> > 
> > I see some coding standards are not adhered to throughout the code.
> > Most noticeably "foo ( int a )" should be "foo (int a)". Similarly for
> > calls.
> 
> Ok, I will try to fix all of the coding standard errors. Is there a
> program I can run on the source files before I create the diff that
> formats the code according to the standard?
> 
> > 
> >  > 
> >  > Index: gdb/dbxread.c
> >  > ===================================================================
> >  > Index: gdb/dwarf2read.c
> >  > ===================================================================
> > 
> > These are ok
> 
> Great!
> 
> >  >  
> >  > Index: gdb/defs.h
> >  > ===================================================================
> >  > RCS file: /cvs/src/src/gdb/defs.h,v
> >  > retrieving revision 1.143
> >  > diff -w -u -r1.143 defs.h
> >  > --- gdb/defs.h	23 Feb 2004 19:26:14 -0000	1.143
> >  > +++ gdb/defs.h	25 Feb 2004 03:51:35 -0000
> >  > @@ -616,8 +616,6 @@
> >  >  
> >  >  extern void init_last_source_visited (void);
> >  >  
> >  > -extern char *symtab_to_filename (struct symtab *);
> >  > -
> >  >  /* From exec.c */
> >  >  
> >  >  extern void exec_set_section_offsets (bfd_signed_vma text_off,
> >  > Index: gdb/dwarf2read.c
> >  > ===================================================================
> >  > RCS file: /cvs/src/src/gdb/dwarf2read.c,v
> >  > retrieving revision 1.135
> >  > diff -w -u -r1.135 dwarf2read.c
> >  > --- gdb/dwarf2read.c	21 Feb 2004 02:13:35 -0000	1.135
> >  > +++ gdb/dwarf2read.c	25 Feb 2004 03:51:43 -0000
> >  > @@ -316,6 +316,7 @@
> >  >      unsigned int offset;
> >  >      unsigned int abbrev;
> >  >      char *name;
> >  > +    char *dirname;
> >  >      int has_pc_info;
> >  >      CORE_ADDR lowpc;
> >  >      CORE_ADDR highpc;
> >  > @@ -1254,6 +1255,8 @@
> >  >  				  objfile->global_psymbols.next,
> >  >  				  objfile->static_psymbols.next);
> >  >  
> >  > +      pst->dirname = xstrdup ( comp_unit_die.dirname );
> >  > +
> >  >        pst->read_symtab_private = (char *)
> >  >  	obstack_alloc (&objfile->objfile_obstack, sizeof (struct dwarf2_pinfo));
> >  >        DWARF_INFO_BUFFER (pst) = dwarf_info_buffer;
> >  > @@ -4326,6 +4329,10 @@
> >  >  	  /* Prefer DW_AT_MIPS_linkage_name over DW_AT_name.  */
> >  >  	  if (part_die->name == NULL)
> >  >  	    part_die->name = DW_STRING (&attr);
> >  > +	  break;
> >  > +	case DW_AT_comp_dir:
> >  > +	  if (part_die->dirname == NULL)
> >  > +	    part_die->dirname = DW_STRING (&attr);
> > 
> > The dwarf2 specs say that the name is in the form ":pathname" or
> > "hostname:pathname". Should we worry about the hostname? Does gcc emit
> > that?  I have looked at a few executables and didn't see the hostname
> > part.
> 
> It would probably just be best if you told me what case's you want me to
> implement here. It seems that Jason Molenda understodd most of the
> cases. I really don't know anything about what GCC emits and would would
> be practical to implement.
> 
> >  > Index: gdb/source.c
> >  > ===================================================================
> > 
> > this part I am not clear about.
> 
> Ok, Ok. I thought about this a lot. I think I made the best decision and
> can describe why.
> 
> A few assumptions are in order. In order to get the fullname (abs path) 
> to a file, GDB need's three things. The directory the file was compiled 
> in (dirname), the filename in question (filename) and a list of paths 
> to search.
> 
> > There is already a function called source_full_path_of() would it help
> > if you used it?
> 
> The function source_full_path_of does not take into account 'dirname'.
> It calls openp, which is not capable of finding the fullname of a file,
> since it doesn't understand what dirname is. Basically, I don't even
> think this function (source_full_path_of) is "truly" capable of 
> finding the fullpath to a file. However, instead of removing it, 
> I left it, since caller's of this function might be using for something 
> I know nothing about.
> 
> > What is the difference between find_and_open_source and
> > open_source_file?  I.e. why did you need to introduce it. I think it's
> > not clear just from your comments about the file possibly baing moved
> > around.
> 
> open_source_file was left around for backwards compatibility. The unit
> source.c was used to calling a function, with just passing the symtab,
> and getting back the symtab with a valid fullname. I could remove all
> occurences of this function and replace it with symtab_to_fullname.
> 
> > I am a bit worried about the substitution of symtab_to_filename with
> > symtab_to_fullname. The former returns null only if there is no
> > symtab.  The latter returns null when there is no symtab OR when it
> > cannot find the file. So the behavior is slightly different.
> 
> I basically think that the call -file-list-exec-source-files shouldn't 
> 'cache' it's results. GDB looks for each file, every time it is
> requested to get the fullname. This is because, the user could have 
> changed the path, or moved/deleted the file. I don't think GDB should
> just return the filename instead, of the fullname.
> 
> So, if find_and_open_source couldn't "find and open the source file", it
> returns NULL. Also, as a side effect, fullname in the [ps]ymtab also
> get's set to NULL.
> 
> The testsuite didn't seem to have a problem with this, and I think it
> makes sense to not trick the caller into having results when it couldn't
> find any.
> 
> If the caller really wanted this functionality,
>   return s->filename; /* File not found.  Just use short name */
> I believe it should be the caller's responsibility.
> 
> if ( symtab_to_fullname ( s ) == NULL )
>    /* use symtab->filename */ 
> else
>    /* use symtab->fullname */
> 
> It doesn't really make sense to return the filename and not state that
> it is not really the fullname. Also, if the caller tries to access
> s->fullname, it will not be successful, because the file simply isn't
> there.
> 
> >  > RCS file: /cvs/src/src/gdb/source.c,v
> >  > retrieving revision 1.49
> >  > diff -w -u -r1.49 source.c
> >  > --- gdb/source.c	27 Jan 2004 23:19:51 -0000	1.49
> >  > +++ gdb/source.c	25 Feb 2004 03:51:45 -0000
> >  > @@ -805,30 +805,47 @@
> >  >    return 1;
> >  >  }
> >  >  
> >  > -
> >  > -/* Open a source file given a symtab S.  Returns a file descriptor or
> >  > -   negative number for error.  */
> >  > -
> >  > +/* This function is capable of finding the absolute path to a
> >  > +   source file, and opening it, provided you give it an 
> >  > +   OBJFILE and FILENAME. Both the DIRNAME and FULLNAME are only
> >  > +   added suggestions on where to find the file. 
> >  > +
> >  > +   OBJFILE should be the objfile associated with a psymtab or symtab. 
> >  > +   FILENAME should be the filename to open.
> >  > +   DIRNAME is the compilation directory of a particular source file.
> >  > +           Only some debug formats provide this info.
> >  > +   FULLNAME can be the last known absolute path to the file in question.
> >  > +
> >  > +   On Success 
> >  > +     A valid file descriptor is returned. ( the return value is positive )
> >  > +     FULLNAME is set to the absolute path to the file just opened.
> >  > +
> >  > +   On Failure
> >  > +     A non valid file descriptor is returned. ( the return value is negitive ) 
> >  > +     FULLNAME is set to NULL.  */
> >  >  int
> >  > -open_source_file (struct symtab *s)
> >  > +find_and_open_source ( 
> >  > +  struct objfile *objfile,	
> >  > +  const char *filename,
> >  > +  const char *dirname,
> >  > +  char **fullname )
> >  >  {
> > 
> > coding standards....
> 
> Ok.
> 
> >  >    char *path = source_path;
> >  >    const char *p;
> >  >    int result;
> >  > -  char *fullname;
> >  >  
> >  >    /* Quick way out if we already know its full name */
> >  > -  if (s->fullname)
> >  > +  if (*fullname)
> >  >      {
> >  > -      result = open (s->fullname, OPEN_MODE);
> >  > +      result = open (*fullname, OPEN_MODE);
> >  >        if (result >= 0)
> >  >  	return result;
> >  >        /* Didn't work -- free old one, try again. */
> >  > -      xmfree (s->objfile->md, s->fullname);
> >  > -      s->fullname = NULL;
> >  > +      xmfree (objfile->md, *fullname);
> >  > +      *fullname = NULL;
> >  >      }
> >  >  
> >  > -  if (s->dirname != NULL)
> >  > +  if (dirname != NULL)
> >  >      {
> >  >        /* Replace a path entry of  $cdir  with the compilation directory name */
> >  >  #define	cdir_len	5
> >  > @@ -841,60 +858,102 @@
> >  >  	  int len;
> >  >  
> >  >  	  path = (char *)
> >  > -	    alloca (strlen (source_path) + 1 + strlen (s->dirname) + 1);
> >  > +	    alloca (strlen (source_path) + 1 + strlen (dirname) + 1);
> >  >  	  len = p - source_path;
> >  >  	  strncpy (path, source_path, len);	/* Before $cdir */
> >  > -	  strcpy (path + len, s->dirname);	/* new stuff */
> >  > +	  strcpy (path + len, dirname);	/* new stuff */
> >  >  	  strcat (path + len, source_path + len + cdir_len);	/* After $cdir */
> >  >  	}
> >  >      }
> >  >  
> >  > -  result = openp (path, 0, s->filename, OPEN_MODE, 0, &s->fullname);
> >  > +  result = openp (path, 0, filename, OPEN_MODE, 0, fullname);
> >  >    if (result < 0)
> >  >      {
> >  >        /* Didn't work.  Try using just the basename. */
> >  > -      p = lbasename (s->filename);
> >  > -      if (p != s->filename)
> >  > -	result = openp (path, 0, p, OPEN_MODE, 0, &s->fullname);
> >  > +      p = lbasename (filename);
> >  > +      if (p != filename)
> >  > +	result = openp (path, 0, p, OPEN_MODE, 0, fullname);
> >  >      }
> >  >  
> >  >    if (result >= 0)
> >  >      {
> >  > -      fullname = s->fullname;
> >  > -      s->fullname = mstrsave (s->objfile->md, s->fullname);
> >  > -      xfree (fullname);
> >  > +      char *tmp_fullname;
> >  > +      tmp_fullname = *fullname;
> >  > +      *fullname = mstrsave (objfile->md, *fullname);
> >  > +      xfree (tmp_fullname);
> >  >      }
> >  >    return result;
> >  >  }
> >  >  
> >  > -/* Return the path to the source file associated with symtab.  Returns NULL
> >  > -   if no symtab.  */
> >  > +/* Open a source file given a symtab S.  Returns a file descriptor or
> >  > +   negative number for error.  
> >  > +   
> >  > +   This function is a convience function to find_and_open_source. */
> >  > +
> >  > +int
> >  > +open_source_file (struct symtab *s)
> >  > +{
> >  > +    if (!s)
> >  > +      return -1;
> >  > +
> >  > +    return find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname );
> >  > +}
> >  > +
> >  > +/* Finds the fullname that a symtab represents.
> >  > +
> >  > +   If this functions finds the fullname, it will save it in ps->fullname
> >  > +   and it will also return the value.
> >  >  
> >  > +   If this function fails to find the file that this symtab represents,
> >  > +   NULL will be returned and ps->fullname will be set to NULL.  */
> >  >  char *
> >  > -symtab_to_filename (struct symtab *s)
> >  > +symtab_to_fullname (struct symtab *s)
> >  >  {
> >  > -  int fd;
> >  > +  int r;
> >  >  
> >  >    if (!s)
> >  >      return NULL;
> >  >  
> >  > -  /* If we've seen the file before, just return fullname. */
> >  > +  /* Don't check s->fullname here, the file could have been 
> >  > +     deleted/moved/..., look for it again */
> >  > +  r = find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname);
> >  >  
> >  > -  if (s->fullname)
> >  > +  if (r)
> >  > +  {
> >  > +    close (r);
> >  >      return s->fullname;
> >  > +  }
> >  >  
> >  > -  /* Try opening the file to setup fullname */
> >  > +  return NULL;
> >  > +}
> >  >  
> >  > -  fd = open_source_file (s);
> >  > -  if (fd < 0)
> >  > -    return s->filename;		/* File not found.  Just use short name */
> >  > +/* Finds the fullname that a partial_symtab represents.
> >  >  
> >  > -  /* Found the file.  Cleanup and return the full name */
> >  > +   If this functions finds the fullname, it will save it in ps->fullname
> >  > +   and it will also return the value.
> >  >  
> >  > -  close (fd);
> >  > -  return s->fullname;
> >  > +   If this function fails to find the file that this partial_symtab represents,
> >  > +   NULL will be returned and ps->fullname will be set to NULL.  */
> >  > +char *
> >  > +psymtab_to_fullname (struct partial_symtab *ps)
> >  > +{
> >  > +  int r;
> >  > +
> >  > +  if (!ps)
> >  > +    return NULL;
> >  > +
> >  > +  /* Don't check ps->fullname here, the file could have been
> >  > +     deleted/moved/..., look for it again */
> >  > +  r = find_and_open_source ( ps->objfile, ps->filename, ps->dirname, &ps->fullname);
> >  > +
> >  > +  if (r) 
> >  > +  {
> >  > +    close (r);
> >  > +    return ps->fullname;
> >  >  }
> >  >  \f
> >  > +  return NULL;
> >  > +}
> >  >  
> >  >  /* Create and initialize the table S->line_charpos that records
> >  >     the positions of the lines in the source file, which is assumed
> > 
> > 
> > 
> >  > Index: gdb/source.h
> >  > ===================================================================
> >  > Index: gdb/symtab.c
> >  > ===================================================================
> > 
> > These are obvious if the rest goes in.
> > 
> > 
> >  > Index: gdb/symtab.h
> >  > ===================================================================
> > 
> > OK.
> > 
> > 
> >  > Index: gdb/mi/mi-cmd-file.c
> >  > ===================================================================
> > 
> > 
> >  > +static const char * const FILENAME = "filename";
> >  > +static const char * const FULLNAME = "fullname";
> > 
> > I don't think these are necessary.
> 
> It just unifies the output convention I am using in the
> mi-cmd-file unit. What would you prefer to see?
> 
> >  >  
> >  >  /* Return to the client the absolute path and line number of the 
> >  >     current file being executed. */
> >  > @@ -39,7 +43,6 @@
> >  >    if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_file", argc, argv) )
> >  >      error ("mi_cmd_file_list_exec_source_file: Usage: No args");
> >  >  
> >  > -  
> >  >    /* Set the default file and line, also get them */
> >  >    set_default_source_symtab_and_line();
> >  >    st = get_current_source_symtab_and_line();
> >  > @@ -51,17 +54,67 @@
> >  >      error ("mi_cmd_file_list_exec_source_file: No symtab");
> >  >  
> >  >    /* Extract the fullname if it is not known yet */
> >  > -  if (st.symtab->fullname == NULL)
> >  > -    symtab_to_filename (st.symtab);
> >  > -
> >  > -  /* We may not be able to open the file (not available). */
> >  > -  if (st.symtab->fullname == NULL)
> >  > -    error ("mi_cmd_file_list_exec_source_file: File not found");
> > 
> > Why get rid of the error message?
> 
> Ok.
> 
> >  > +  symtab_to_fullname (st.symtab);
> >  >  
> >  >    /* Print to the user the line, filename and fullname */
> >  >    ui_out_field_int (uiout, "line", st.line);
> >  > -  ui_out_field_string (uiout, "file", st.symtab->filename);
> >  > -  ui_out_field_string (uiout, "fullname", st.symtab->fullname);
> >  > +  ui_out_field_string (uiout, FILENAME, st.symtab->filename);
> >  > +  
> >  > +  /* We may not be able to open the file (not available). */
> >  > +  if (st.symtab->fullname)
> >  > +    ui_out_field_string (uiout, FULLNAME, st.symtab->fullname);
> >  > +
> > 
> > if this test fails shouldn't some warning/error be issued?
> 
> I don't know. I am thinking that GDB should just return the absolute
> path to all of the source files it can find. If it can not find some,
> should it issue a warning? That way the front end could say, "you need
> to add a directory to the source search path".
> 
> >  > +  return MI_CMD_DONE;
> >  > +}
> >  > +
> >  > +enum mi_cmd_result
> >  > +mi_cmd_file_list_exec_source_files(char *command, char **argv, int argc)
> >  > +{
> >  > +  struct symtab *s;
> >  > +  struct partial_symtab *ps;
> >  > +  struct objfile *objfile;
> >  > +
> >  > +  if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_files", argc, argv) )
> >  > +    error ("mi_cmd_file_list_exec_source_files: Usage: No args");
> >  > +
> >  > +  /* Print the table header */
> >  > +  ui_out_begin ( uiout, ui_out_type_list, "files");
> >  > +
> >  > +  /* Look at all of the symtabs */
> >  > +  ALL_SYMTABS (objfile, s)
> >  > +  {
> >  > +    ui_out_begin ( uiout, ui_out_type_tuple, NULL);
> >  > +
> >  > +    ui_out_field_string (uiout, FILENAME, s->filename);
> >  > +
> >  > +	/* Extract the fullname if it is not known yet */
> >  > +	symtab_to_fullname (s);
> >  > +
> >  > +	if (s->fullname)
> >  > +      ui_out_field_string (uiout, FULLNAME, s->fullname);
> >  > +
> >  > +    ui_out_end ( uiout, ui_out_type_tuple );
> >  > +  }
> >  > +
> >  > +  /* Look at all of the psymtabs */
> >  > +  ALL_PSYMTABS (objfile, ps)
> >  > +  {
> >  > +    if (!ps->readin) {
> > 
> > coding standards....
> 
> Ok.
> 
> >  > +      ui_out_begin ( uiout, ui_out_type_tuple, NULL);
> >  > +
> >  > +      ui_out_field_string (uiout, FILENAME, ps->filename);
> >  > +
> >  > +      /* Extract the fullname if it is not known yet */
> >  > +	  psymtab_to_fullname (ps);
> >  > +
> >  > +	  if (ps->fullname) 
> >  > +	    ui_out_field_string (uiout, FULLNAME, ps->fullname);
> >  > +
> >  > +      ui_out_end ( uiout, ui_out_type_tuple );
> >  > +    }
> >  > +  }
> >  > +
> >  > +  ui_out_end ( uiout, ui_out_type_list );
> >  >  
> >  >    return MI_CMD_DONE;
> >  >  }
> > 
> > 
> > 
> >  > Index: gdb/mi/mi-cmds.c
> >  > ===================================================================
> > 
> >  > Index: gdb/mi/mi-cmds.h
> >  > ===================================================================
> > 
> > these changes are ok.
> 
> Great!
> 
> >  > Index: gdb/testsuite/gdb.mi/mi-file.exp
> >  > ===================================================================
> >  > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-file.exp,v
> >  > retrieving revision 1.1
> >  > diff -w -u -r1.1 mi-file.exp
> >  > --- gdb/testsuite/gdb.mi/mi-file.exp	2 Apr 2003 22:10:35 -0000	1.1
> >  > +++ gdb/testsuite/gdb.mi/mi-file.exp	25 Feb 2004 03:52:36 -0000
> >  > @@ -55,7 +55,7 @@
> >  >  
> >  >      # get the path and absolute path to the current executable
> >  >      mi_gdb_test "111-file-list-exec-source-file" \
> >  > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> >  > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> > 
> > Wouldn't this break existing MI parsers?
> 
> Yes. I figured it could be mi2. Also, for some reason, I thought no one
> would be using this function since I wrote it for CGDB, and I haven't
> used it yet. I have a larger plan in mind for MI, than just these 2
> commands (-file-list-exec-source-file and -file-list-exec-source-files).
> I would like to add the fullname to a lot of commands. However, I think
> 'filename' and 'fullname' should be standardized, so that front end
> writers immediatly understand what they are. It is awkard to have 1
> function say "file=" and another say "filename=", when those 2 words
> mean the same thing. 
> 
> However, if this changes isn't acceptable, I can change it back.
> 
> >  >                 "request path info of current source file (${srcfile})"
> >  >  }
> >  >  
> >  > Index: gdb/testsuite/gdb.mi/mi2-file.exp
> >  > ===================================================================
> >  > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi2-file.exp,v
> >  > retrieving revision 1.1
> >  > diff -w -u -r1.1 mi2-file.exp
> >  > --- gdb/testsuite/gdb.mi/mi2-file.exp	7 Aug 2003 17:47:42 -0000	1.1
> >  > +++ gdb/testsuite/gdb.mi/mi2-file.exp	25 Feb 2004 03:52:36 -0000
> >  > @@ -47,7 +47,7 @@
> >  >  mi_gdb_reinitialize_dir $srcdir/$subdir
> >  >  mi_gdb_load ${binfile}
> >  >  
> >  > -proc test_tbreak_creation_and_listing {} {
> >  > +proc test_file_list_exec_source_file {} {
> >  >      global srcfile
> >  >      global srcdir
> >  >      global subdir
> >  > @@ -55,11 +55,21 @@
> >  >  
> >  >      # get the path and absolute path to the current executable
> >  >      mi_gdb_test "111-file-list-exec-source-file" \
> >  > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> >  > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> >  >                 "request path info of current source file (${srcfile})"
> >  >  }
> >  >  
> >  > -test_tbreak_creation_and_listing
> >  > +proc test_file_list_exec_source_files {} {
> >  > +    global srcfile
> >  > +
> >  > +    # get the path and absolute path to the current executable
> >  > +    mi_gdb_test "222-file-list-exec-source-files" \
> >  > +	    "222\\\^done,files=\\\[\{filename=\".*/${srcfile}\",fullname=\"/.*/${srcfile}\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\}\\\]" \
> > 
> >  > +              "Getting a list of source files failed."
> >                                                  ^^^^^^^
> >                                                   why failed?
> 
> OOO, That isn't an error condition, it's just a comment. I see.
> 
> Thanks,
> Bob Rossi

A small patch case study, -file-list-exec-source-files

[Bob Rossi]

Hi All,

It has taken about 1 month to get a 500 line patch reviewed.
And the review process is not over yet.

Personally, I think we should use this patch as a case study to prove
the inherent problems that GDB has. It is obvious to me that GDB is
almost a dead project when it comes to receiving patches from the outside
world.

Here is the ridiculous time table seen for this trivial patch.

02-24: Posted
02-25
02-26: Andrew responded, passed buck to Elena, should have To:ed Elena :-(
02-27: Question about when response would be
02-28: <weekend>
02-29: <weekend>
03-01: Above post
03-01: <seven days>
03-02: I acknowledged the response.
03-03: Eli Zaretskii thinks waiting a week to ping on a patch isn't bad.
       ( I happen to think it is bad )
03-05: Patch initially reviewed by Elana Zannoni ( great job too )
03-05: Jason Molenda made some useful comments ( thanks Jason )
03-06: I respond the next day to Elena's questions, ready to move forward.
       (no response)
03-11: I respond a week later.
       (no response)
03-23: I write an Email to gdb-heads, hoping to show that there is a
real problem in the GDB community.

Now, I refuse to keep sending in an Email every week to get my patch
resolved. That gives me the impression that GDB is not competent in
receiving patches and processing them. I don't really blame this on
anyone in particular, but I blame the problem on everyone. I see that
there is an effort in the correct direction to change this, but 
what could we do to fix this particular case, since this would basically 
be fixing "the small patch" case.

Does GDB look at  patches in a

FIFO order?
Smallest Job First order?
The developer who wines and complains the most about their patch order?

I hope I have not offended anyone here, since honestly, each of the GDB
people I have talked to has done a great job helping me out. It's just the 
system on a whole that seems to be lacking.

Thanks,
Bob Rossi

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Robert Dewar]

Bob Rossi wrote:

> I hope I have not offended anyone here, since honestly, each of the GDB
> people I have talked to has done a great job helping me out. It's just the 
> system on a whole that seems to be lacking.

I don't see any fundamental problem here. This is after all a volunteer
project and people have limited time to review patches, as they have
limited time for anything they do on the project. Of course we all
understand that it is frustrating when it takes a while for a patch
to be approved, but there is no one who can order someone else to
spend more time on this. Now perhaps more people should have approval
authority, but that of course has its own draw backs in terms of
keeping the entire project under control. There is always a
fundamental trade off between reliability/stability/control and
adding nice new features.

Can you give some idea of why you feel it is so urgent to get this
patch in place. I don't see it as an urgent matter, and I don't find
this delay unreasonable, but perhaps I am missing something.

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Ian Lance Taylor]

Robert Dewar <dewar@gnat.com> writes:

> Bob Rossi wrote:
> 
> > I hope I have not offended anyone here, since honestly, each of the GDB
> > people I have talked to has done a great job helping me out. It's
> > just the system on a whole that seems to be lacking.
> 
> I don't see any fundamental problem here. This is after all a volunteer
> project and people have limited time to review patches, as they have
> limited time for anything they do on the project. Of course we all
> understand that it is frustrating when it takes a while for a patch
> to be approved, but there is no one who can order someone else to
> spend more time on this. Now perhaps more people should have approval
> authority, but that of course has its own draw backs in terms of
> keeping the entire project under control. There is always a
> fundamental trade off between reliability/stability/control and
> adding nice new features.

The fundamental problem is that in order for a volunteer project to
succeed, it is essential to pay close attention to the care and
feeding of volunteers.  Otherwise, the project eventually comes to
lack any volunteers.

I've already described my views at some length here:
    http://mail.gnu.org/archive/html/gdbheads/2004-01/msg00032.html

As I said in that message: "patch review is the most important aspect
of being a GNU maintainer."

Ian

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Bob Rossi]

On Tue, Mar 23, 2004 at 11:13:17AM -0500, Ian Lance Taylor wrote:
> Robert Dewar <dewar@gnat.com> writes:
> 
> > Bob Rossi wrote:
> > 
> > > I hope I have not offended anyone here, since honestly, each of the GDB
> > > people I have talked to has done a great job helping me out. It's
> > > just the system on a whole that seems to be lacking.
> > 
> > I don't see any fundamental problem here. This is after all a volunteer
> > project and people have limited time to review patches, as they have
> > limited time for anything they do on the project. Of course we all
> > understand that it is frustrating when it takes a while for a patch
> > to be approved, but there is no one who can order someone else to
> > spend more time on this. Now perhaps more people should have approval
> > authority, but that of course has its own draw backs in terms of
> > keeping the entire project under control. There is always a
> > fundamental trade off between reliability/stability/control and
> > adding nice new features.
> 
> The fundamental problem is that in order for a volunteer project to
> succeed, it is essential to pay close attention to the care and
> feeding of volunteers.  Otherwise, the project eventually comes to
> lack any volunteers.
> 
> I've already described my views at some length here:
>     http://mail.gnu.org/archive/html/gdbheads/2004-01/msg00032.html
> 
> As I said in that message: "patch review is the most important aspect
> of being a GNU maintainer."

I completely agree with Ian here.  So the question is, 
is patch review the most important aspect of being a GNU GDB maintainer?

How many GDB maintainers would answer yes to this?

Bob Rossi

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Joel Brobecker]

> I completely agree with Ian here.  So the question is, 
> is patch review the most important aspect of being a GNU GDB maintainer?
> 
> How many GDB maintainers would answer yes to this?

GDB is a volunteer work!

If you keep insisting that a maintainer have to review patches within a
given timeframe and that they should step down if they can't, then I
think we're going to lose a lot of maintainers. Will GDB really be
better off? I think not.

I think you're looking at the wrong solution. The real solution,
according to me, is not to push away good maintainers that have only so
much time, but to help the group of maintainers to act as a team.
When one maintainer is too busy, then the rest of the team should be
allowed to step up and help the busy maintainer by reviewing patches
and answering emails in his place. The real problem is that GDB
currently has bottlenecks, and that's the issue that needs solving,
one way or the other.

I'm only a contributor, but I have barely enough time to followup
on the review of my own patches. I have messages from some maintainers
following up on my own messages that I need to answer and have been
sitting in mail mailbox for weeks. How can I, a fairly regular
contributor, ever ask/force volunteers maintainers to do any more than
they are already doing?

-- 
Joel

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Ian Lance Taylor]

Joel Brobecker <brobecker@gnat.com> writes:

> GDB is a volunteer work!

I want to note that this is only partially true.  In fact there are a
number of people who are paid to work on gdb.  It's not clear whether
anybody is paid specifically to maintain gdb.  When I was at Cygnus I
was paid to maintain the GNU binutils, though that was certainly not
my only job.  I don't know whether Red Hat has carried that sort of
thing forward.

> If you keep insisting that a maintainer have to review patches within a
> given timeframe and that they should step down if they can't, then I
> think we're going to lose a lot of maintainers. Will GDB really be
> better off? I think not.

I would say that the issue is how to best keep gdb moving forward.

On the one hand, if we require prompt patch review, then gdb may lose
maintainers.  On the other hand, if patches are not reviewed promptly,
then gdb may lost contributors.  There is a balance between the two.
The goal is to keep the balance from tipping too far to one side or
the other.

I don't know myself whether the balance is indeed tipped too far for
gdb.  As I've said, I do think that maintainers should treat patch
review as their most important activity.

> I think you're looking at the wrong solution. The real solution,
> according to me, is not to push away good maintainers that have only so
> much time, but to help the group of maintainers to act as a team.
> When one maintainer is too busy, then the rest of the team should be
> allowed to step up and help the busy maintainer by reviewing patches
> and answering emails in his place. The real problem is that GDB
> currently has bottlenecks, and that's the issue that needs solving,
> one way or the other.

Yes, this sort of approach has been proposed by several different
people, including some gdb maintainers.

Ian

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Robert Dewar]

Ian Lance Taylor wrote:

> I want to note that this is only partially true.  In fact there are a
> number of people who are paid to work on gdb. 

Yes, but they aren't necessarily paid to work for the same goals as
FSF maintenance. If I am working for company X which wants a reliable
GDB for target Y, we may have zero interest in a patch that does not
promote this goal.

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Bob Rossi]

On Thu, Mar 25, 2004 at 01:19:16AM -0500, Robert Dewar wrote:
> Ian Lance Taylor wrote:
> 
> >I want to note that this is only partially true.  In fact there are a
> >number of people who are paid to work on gdb. 
> 
> Yes, but they aren't necessarily paid to work for the same goals as
> FSF maintenance. If I am working for company X which wants a reliable
> GDB for target Y, we may have zero interest in a patch that does not
> promote this goal.

This was basically asking my question in a sentence.

What incentive does a maintainer have in reviewing patches quickly?

Bob Rossi

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Ian Lance Taylor]

Bob Rossi <bob@brasko.net> writes:

> On Thu, Mar 25, 2004 at 01:19:16AM -0500, Robert Dewar wrote:
> > Ian Lance Taylor wrote:
> > 
> > >I want to note that this is only partially true.  In fact there are a
> > >number of people who are paid to work on gdb. 
> > 
> > Yes, but they aren't necessarily paid to work for the same goals as
> > FSF maintenance. If I am working for company X which wants a reliable
> > GDB for target Y, we may have zero interest in a patch that does not
> > promote this goal.
> 
> This was basically asking my question in a sentence.
> 
> What incentive does a maintainer have in reviewing patches quickly?

When I worked at Cygnus, part of my job was being the binutils
maintainer.  The details were unspecified by management, but the
general idea was to keep the FSF happy with Cygnus and to get as much
free work out of the community as possible.  So that was an incentive
to do effective patch review, beyond my own personal feelings.  As I
said, although Red Hat is the effective maintainer of gdb given that a
plurality of gdb maintainers work for them, I don't know whether Red
Hat is actually paying anybody to work toward these, or similar,
goals.

Robert, it's interesting to read your comments in light of the history
of the gcc/egcs split.  After all, Richard Kenner worked for GNAT at
the time, and I believe that you did too.  In my opinion, Kenner
expressed the attitude which you express--in his case, stability for
Ada was the preeminent goal.  I think that attitude was a significant
root cause of the gcc/egcs split.  I think that tends to prove my
earlier point in an extreme case: if you don't make an effort to
encourage your volunteers, you lose them.

Ian

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Robert Dewar]

Ian Lance Taylor wrote:

> Robert, it's interesting to read your comments in light of the history
> of the gcc/egcs split.  After all, Richard Kenner worked for GNAT at
> the time, and I believe that you did too.  In my opinion, Kenner
> expressed the attitude which you express--in his case, stability for
> Ada was the preeminent goal.  I think that attitude was a significant
> root cause of the gcc/egcs split.  I think that tends to prove my
> earlier point in an extreme case: if you don't make an effort to
> encourage your volunteers, you lose them.

If you want to prove your point by history, make sure you know the
history. First GNAT is a product, no one works for it. Second, the
company is AdaCore Technologies, I am CEO, Richard is Treasurer :-)
so the past tense is bizarre :-)

Third, at the time of the gcc/egcs split, Ada was simply not a factor
and had nothing whatever to do with the events.

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Ian Lance Taylor]

Robert Dewar <dewar@gnat.com> writes:

> Ian Lance Taylor wrote:
> 
> > Robert, it's interesting to read your comments in light of the history
> > of the gcc/egcs split.  After all, Richard Kenner worked for GNAT at
> > the time, and I believe that you did too.  In my opinion, Kenner
> > expressed the attitude which you express--in his case, stability for
> > Ada was the preeminent goal.  I think that attitude was a significant
> > root cause of the gcc/egcs split.  I think that tends to prove my
> > earlier point in an extreme case: if you don't make an effort to
> > encourage your volunteers, you lose them.
> 
> If you want to prove your point by history, make sure you know the
> history. First GNAT is a product, no one works for it. Second, the
> company is AdaCore Technologies, I am CEO, Richard is Treasurer :-)
> so the past tense is bizarre :-)

I apologize for the confusion of names.  I see e-mail addresses
@gnat.com, so I called the company GNAT.  I used the past tense to
make clear that I was talking about the situation at the time of the
split--I think that is clear from what I wrote.

> Third, at the time of the gcc/egcs split, Ada was simply not a factor
> and had nothing whatever to do with the events.

I was there.  I disagree.  It absolutely was a factor.  It was the
elephant in the middle of the room.  We at Cygnus were pointing it out
loudly.  Richard Kenner and Richard Stallman were ignoring it.

Ian

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Robert Dewar]

> I was there.  I disagree.  It absolutely was a factor.  It was the
> elephant in the middle of the room.  We at Cygnus were pointing it out
> loudly.  Richard Kenner and Richard Stallman were ignoring it.

Well it was an imaginary elephant. Yes, Richard Kenner was very
particular about what patches he admitted. This has nothing whatever
to do with Ada. You are just guessing that this was somehow related,
it was not.

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Ian Lance Taylor]

Robert Dewar <dewar@gnat.com> writes:

> > I was there.  I disagree.  It absolutely was a factor.  It was the
> > elephant in the middle of the room.  We at Cygnus were pointing it out
> > loudly.  Richard Kenner and Richard Stallman were ignoring it.
> 
> Well it was an imaginary elephant. Yes, Richard Kenner was very
> particular about what patches he admitted. This has nothing whatever
> to do with Ada. You are just guessing that this was somehow related,
> it was not.

I disagree.

Richard Kenner took specific actions which had every appearance of
conflict between the demands of being gcc maintainer and the demands
of being an employee of Ada Core Technologies.  You say that these
actions had nothing to do with Ada.  My response is that it sure
looked like they had everything to do with Ada.  I can't read
anybody's mind.  Perhaps you are right.  It just seems, well,
unlikely.  I think I personally always been able to clearly state the
ways in which my employer influences my actions, and the ways in which
they do not, and to acknowledge the appearance of conflict and relate
that to the extent of actual conflict.  Richard Kenner did not make
those kinds of statements.

I'll add that I'm now sorry that I brought up this ancient history.
It can't lead to anything good.

I apologize.  I'll try to stop talking about it.

I'll also add that being a GNU maintainer is an inherently political
position.  Technical skill is a big part of it, but it is not the only
part.  People with no political skills are risky choices as GNU
maintainers.

Ian

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Robert Dewar]

Ian Lance Taylor wrote:

> Richard Kenner took specific actions which had every appearance of
> conflict between the demands of being gcc maintainer and the demands
> of being an employee of Ada Core Technologies.  You say that these
> actions had nothing to do with Ada.   My response is that it sure
> looked like they had everything to do with Ada. 

I am telling you the facts, based on talking to Richard nearly
every day in the period both before and after AdaCore was founded.

> I can't read anybody's mind.

Indeed! I suggest not trying. Especially when your uninformed
attempts to do so come out as inappropriate personal attacks.

> Richard Kenner did not make those kinds of statements.

Well what are you saying? Are you saying that Richard's work on
Ada took away some time from volunteer work on maintaining GCC?
Perhaps, but all of us have day jobs! In fact Richard's main
activity at AdaCore was always to work on GCC maintenance.

Are you saying that Richard's technical decisions were influenced
inappropriately by his work on GNAT? If so, then that's what seems
to be to me in the category of inappropriate personal attacks.

It is most certainly true that Richard is *VERY* particular on
what he considers acceptable changes, both from a point of view
of technical content and documentation. Believe me, the others
at Ada Core have had to deal with this ourselves :-)

> I'll add that I'm now sorry that I brought up this ancient history.
> It can't lead to anything good.

True.

> I apologize.  I'll try to stop talking about it.

Sounds like a good idea, especially when your knowledge is limited.
> 
> I'll also add that being a GNU maintainer is an inherently political
> position.  Technical skill is a big part of it, but it is not the only
> part.  People with no political skills are risky choices as GNU
> maintainers.

You don't really mean political skills, though I note the tendency
of technical people to divide all the world up into the technical
aznd political. Really what you mean is skill in dealing with other
people, and yes, of course this is most certainly true.

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Michael Snyder]

Robert Dewar wrote:
> Ian Lance Taylor wrote:

>> I apologize.  I'll try to stop talking about it.
> 
> Sounds like a good idea, especially when your knowledge is limited.

I think we'd all appreciate it if this particular subthread went
either extinct or off list.  ;-)

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Ian Lance Taylor]

Robert Dewar <dewar@gnat.com> writes:

> > I'll also add that being a GNU maintainer is an inherently political
> > position.  Technical skill is a big part of it, but it is not the only
> > part.  People with no political skills are risky choices as GNU
> > maintainers.
> 
> You don't really mean political skills, though I note the tendency
> of technical people to divide all the world up into the technical
> aznd political. Really what you mean is skill in dealing with other
> people, and yes, of course this is most certainly true.

Robert, you can put words in my mouth when dealing with technical
matters, but please do not do it in other cases.  I understand the
distinction you are drawing, and I did mean to say "political skills."

I won't respond to the rest of your comments, since I already said
that I would try to stop talking about it.

Ian

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Christopher Faylor]

On Thu, Mar 25, 2004 at 01:19:16AM -0500, Robert Dewar wrote:
>Ian Lance Taylor wrote:
>>I want to note that this is only partially true.  In fact there are a
>>number of people who are paid to work on gdb. 
>
>Yes, but they aren't necessarily paid to work for the same goals as
>FSF maintenance. If I am working for company X which wants a reliable
>GDB for target Y, we may have zero interest in a patch that does not
>promote this goal.

If someone has allowed themselves to be listed as a maintainer of a
particular part of gdb they have a responsibility to review patches
regardless of whether they are specifically paid to do so or not.  To
act in any other way would be disingenuous.  It is true, of course, that
there may be work constraints which impact the amount of time available
for someone to review patches but if someone is not reviewing patches
because they do not coincide with their company's current interests then
they really shouldn't be professing to act as a maintainer.

IMO.

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Michael Snyder]

Ian Lance Taylor wrote:
> Joel Brobecker <brobecker@gnat.com> writes:
> 
> 
>>GDB is a volunteer work!
> 
> 
> I want to note that this is only partially true.  In fact there are a
> number of people who are paid to work on gdb.  It's not clear whether
> anybody is paid specifically to maintain gdb.  When I was at Cygnus I
> was paid to maintain the GNU binutils, though that was certainly not
> my only job.  I don't know whether Red Hat has carried that sort of
> thing forward.

Well now... there's a fine point here.  Red Hat, Monte Vista, Apple,
HP, and other organizations may pay some people to work on GDB, but
only in some limited sense do those organizations pay their employees
to review other people's patches.  And to whatever degree that is true
(eg. my job description does include spending a certain part of my
time working as an FSF maintainer), all it does is modify who's doing
the volunteering: to some degree it's me, and to some degree it's
Red Hat.  It's still donated work, the FSF isn't paying for it, and
I'm still 100 percent a volunteer.  I wouldn't lose my job if I
announced that I didn't want to serve as an FSF maintainer any more.
All that would happen would be that the work load of the other
maintainers would go up, since they would have to review all of
my work.

>>If you keep insisting that a maintainer have to review patches within a
>>given timeframe and that they should step down if they can't, then I
>>think we're going to lose a lot of maintainers. Will GDB really be
>>better off? I think not.
> 
> 
> I would say that the issue is how to best keep gdb moving forward.

That is one valid way of looking at it, Ian, but it isn't the only
way.  All of us maintainers are people too, and it's perfectly
legitimate for us to have our own agendas and our own interests
in mind, in addition to those of gdb and the FSF.  By becoming
FSF volunteers, we did not become monks -- we did not give up
the right to our own self-hood and our own egos.

To make a team work, we have to get those egos to function smoothly
together -- but that doesn't mean pretending that they don't exist,
or making decisions on the basis that the only thing that matters
is gdb.  The people working on gdb matter too.

> On the one hand, if we require prompt patch review, then gdb may lose
> maintainers.  On the other hand, if patches are not reviewed promptly,
> then gdb may lost contributors.  There is a balance between the two.
> The goal is to keep the balance from tipping too far to one side or
> the other.
> 
> I don't know myself whether the balance is indeed tipped too far for
> gdb.  As I've said, I do think that maintainers should treat patch
> review as their most important activity.
> 
> 
>>I think you're looking at the wrong solution. The real solution,
>>according to me, is not to push away good maintainers that have only so
>>much time, but to help the group of maintainers to act as a team.
>>When one maintainer is too busy, then the rest of the team should be
>>allowed to step up and help the busy maintainer by reviewing patches
>>and answering emails in his place. The real problem is that GDB
>>currently has bottlenecks, and that's the issue that needs solving,
>>one way or the other.
> 
> 
> Yes, this sort of approach has been proposed by several different
> people, including some gdb maintainers.

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Ian Lance Taylor]

Michael Snyder <msnyder@redhat.com> writes:

> Ian Lance Taylor wrote:
> > Joel Brobecker <brobecker@gnat.com> writes:
> >
> >>GDB is a volunteer work!
> > I want to note that this is only partially true.  In fact there are a
> > number of people who are paid to work on gdb.  It's not clear whether
> > anybody is paid specifically to maintain gdb.  When I was at Cygnus I
> > was paid to maintain the GNU binutils, though that was certainly not
> > my only job.  I don't know whether Red Hat has carried that sort of
> > thing forward.
> 
> Well now... there's a fine point here.  Red Hat, Monte Vista, Apple,
> HP, and other organizations may pay some people to work on GDB, but
> only in some limited sense do those organizations pay their employees
> to review other people's patches.

I'll note that I conflated two different ideas in the above quoted
paragraph, perhaps unwisely.  First, I said that it's not wholly true
that "GDB is a volunteer work:" a number of people are paid to work on
gdb.  I then segued into the separate issue of whether anybody is paid
specifically to maintain gdb, and I said that I didn't know.

> And to whatever degree that is true
> (eg. my job description does include spending a certain part of my
> time working as an FSF maintainer), all it does is modify who's doing
> the volunteering: to some degree it's me, and to some degree it's
> Red Hat.  It's still donated work, the FSF isn't paying for it, and
> I'm still 100 percent a volunteer.  I wouldn't lose my job if I
> announced that I didn't want to serve as an FSF maintainer any more.
> All that would happen would be that the work load of the other
> maintainers would go up, since they would have to review all of
> my work.

I don't agree.  When I was paid by Cygnus to be the GNU binutils
maintainer, that was part of my job.  The work was donated to the FSF,
yes, but I think it's quite a stretch to say that I was 100 percent a
volunteer.  And if part of your job is work as an FSF maintainer, then
I think it is quite a stretch to say that you are 100 percent a
volunteer.  If you are paid for doing the work, you are not a
volunteer.

The fact that Red Hat is donating the work to the FSF is irrelevant.
You considered the question of you quitting the job.  But you didn't
consider the question of Red Hat firing you because you weren't doing
the job.  Since Red Hat could, in principle, do just that, I think it
is clear that you are not yourself a volunteer.  (I know that Red Hat
would probably just reassign you if you were doing a lousy job, but
the possibility of firing you remains.)

> >>If you keep insisting that a maintainer have to review patches within a
> >>given timeframe and that they should step down if they can't, then I
> >>think we're going to lose a lot of maintainers. Will GDB really be
> >>better off? I think not.
> > I would say that the issue is how to best keep gdb moving forward.
> 
> That is one valid way of looking at it, Ian, but it isn't the only
> way.  All of us maintainers are people too, and it's perfectly
> legitimate for us to have our own agendas and our own interests
> in mind, in addition to those of gdb and the FSF.  By becoming
> FSF volunteers, we did not become monks -- we did not give up
> the right to our own self-hood and our own egos.
> 
> To make a team work, we have to get those egos to function smoothly
> together -- but that doesn't mean pretending that they don't exist,
> or making decisions on the basis that the only thing that matters
> is gdb.  The people working on gdb matter too.

Yes.  I think that is obvious, but it's worth pointing it out.
Thanks.

Now, that said, I would say that the issue is how best to keep gdb
moving forward.

gdb is not a personal project which belongs to the current set of
maintainers.  It is a project founded and managed by the FSF as,
essentially, a public trust.  As I said, the project needs to be run
in a manner which keeps an appropriate balance between maintainers and
contributors.  This must be done with an eye on the overall goal of
keeping the project moving forward.

Ian

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Eli Zaretskii]

> Date: Wed, 24 Mar 2004 21:59:25 -0800
> From: Joel Brobecker <brobecker@gnat.com>
> 
> I'm only a contributor, but I have barely enough time to followup
> on the review of my own patches. I have messages from some maintainers
> following up on my own messages that I need to answer and have been
> sitting in mail mailbox for weeks. How can I, a fairly regular
> contributor, ever ask/force volunteers maintainers to do any more than
> they are already doing?

If you feel that your contributions are reviewed in reasonable time,
_you_ don't need to complain or ask for better response times.

But other contributors felt differently.  We didn't just invent that,
there are threads in the archives that show that this did in fact
happen.  As long as any of the people who contribute code feel that
some of their contributions take too long to review, we as maintainers
need to do some soul searching to find ways to avoid such feelings.

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Joel Brobecker]

> If you feel that your contributions are reviewed in reasonable time,
> _you_ don't need to complain or ask for better response times.
> 
> But other contributors felt differently.  We didn't just invent that,
> there are threads in the archives that show that this did in fact
> happen.  As long as any of the people who contribute code feel that
> some of their contributions take too long to review, we as maintainers
> need to do some soul searching to find ways to avoid such feelings.

Right. I guess I wasn't clear in my previous message, sorry. I am not
saying that everything is fine. I am just reacting to the idea of
forcing maintainers to review within a hard timeframe each patch that
touches some code they maintain. At least that's what I understood from
Bob's message.

I also have some patches that have been sitting unreviewed for a long
time. I would sure like to see the process become better, and I think
we can improve. But I think the solution to this problem lies in better
teamwork, not in asking maintainer to review "their" patch within a
short timeframe or else quit. I say "their patch" because right now, we
have areas of code where only one or two maintainers can do reviews, and
that to me is the real problem, and probably the source of many of the
delayed patches.

That's why I was in favor of the proposal that asked that global
maintainers be allowed to review and approve patches anywhere.
GCC does it, AFAIK. I think this is going to help GDB in that
respect. Or does anybody have any evidence of the contrary?

-- 
Joel

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Bob Rossi]

On Wed, Mar 24, 2004 at 11:58:58PM -0800, Joel Brobecker wrote:
> > If you feel that your contributions are reviewed in reasonable time,
> > _you_ don't need to complain or ask for better response times.
> > 
> > But other contributors felt differently.  We didn't just invent that,
> > there are threads in the archives that show that this did in fact
> > happen.  As long as any of the people who contribute code feel that
> > some of their contributions take too long to review, we as maintainers
> > need to do some soul searching to find ways to avoid such feelings.
> 
> Right. I guess I wasn't clear in my previous message, sorry. I am not
> saying that everything is fine. I am just reacting to the idea of
> forcing maintainers to review within a hard timeframe each patch that
> touches some code they maintain. At least that's what I understood from
> Bob's message.

Please don't get me wrong. I don't think there should be a hard time
limit. I was just hoping to spark some interest in the community over
the example I am having with submitting a small patch.

Honestly, since the patch didn't make 6.1, I probably won't even start
integrating the functionality into CGDB for several months. So getting
this particular patch reviewed "quick" is not even an issue to me.
However, if I was to start contributing to GDB on a regular basis, and
patches took this long to review, I would probably find other things of
interest to work on.

> That's why I was in favor of the proposal that asked that global
> maintainers be allowed to review and approve patches anywhere.
> GCC does it, AFAIK. I think this is going to help GDB in that
> respect. Or does anybody have any evidence of the contrary?

With my limited knowledge it seems like that would be a good idea. I
wonder if anyone thinks it is a bad idea?

Bob Rossi

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Michael Snyder]

Joel Brobecker wrote:
>>I completely agree with Ian here.  So the question is, 
>>is patch review the most important aspect of being a GNU GDB maintainer?
>>
>>How many GDB maintainers would answer yes to this?
> 
> 
> GDB is a volunteer work!
> 
> If you keep insisting that a maintainer have to review patches within a
> given timeframe and that they should step down if they can't, then I
> think we're going to lose a lot of maintainers. Will GDB really be
> better off? I think not.
> 
> I think you're looking at the wrong solution. The real solution,
> according to me, is not to push away good maintainers that have only so
> much time, but to help the group of maintainers to act as a team.
> When one maintainer is too busy, then the rest of the team should be
> allowed to step up and help the busy maintainer by reviewing patches
> and answering emails in his place. The real problem is that GDB
> currently has bottlenecks, and that's the issue that needs solving,
> one way or the other.

<aol> Here here.  </aol>

> I'm only a contributor, but I have barely enough time to followup
> on the review of my own patches. I have messages from some maintainers
> following up on my own messages that I need to answer and have been
> sitting in mail mailbox for weeks. How can I, a fairly regular
> contributor, ever ask/force volunteers maintainers to do any more than
> they are already doing?
> 

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Eli Zaretskii]

> Date: Wed, 24 Mar 2004 23:36:48 -0500
> From: Bob Rossi <bob@brasko.net>
> 
> So the question is, is patch review the most important aspect of
> being a GNU GDB maintainer?
> 
> How many GDB maintainers would answer yes to this?

IMHO, it's one of the most important aspects.  The other one is to
make his/her own contributions to GDB.

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Michael Snyder]

Eli Zaretskii wrote:
>>Date: Wed, 24 Mar 2004 23:36:48 -0500
>>From: Bob Rossi <bob@brasko.net>
>>
>>So the question is, is patch review the most important aspect of
>>being a GNU GDB maintainer?
>>
>>How many GDB maintainers would answer yes to this?
> 
> 
> IMHO, it's one of the most important aspects.  The other one is to
> make his/her own contributions to GDB.

An important observation.  There may be some of us who want to do
nothing more than review patches -- but I can't think who.  For most,
we have work of our own that we want to do too.  We have to strike
a balance of priority between our own contributions, each others,
and contributions coming from outside.

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Bob Rossi]

On Tue, Mar 23, 2004 at 10:49:51AM -0500, Robert Dewar wrote:
> Bob Rossi wrote:
> 
> >I hope I have not offended anyone here, since honestly, each of the GDB
> >people I have talked to has done a great job helping me out. It's just the 
> >system on a whole that seems to be lacking.
> 
> I don't see any fundamental problem here. 

I understand that you might not see it as a problem. I do.

I am only asking that this issue be looked at. The point I am trying
to make is that if the steering committee could solve a simple problem
like, "the time it takes to review a small patch", maybe it could solve
the problem of reviewing a slightly larger patch. By induction, all
patches could be reviewed faster.

How long should it take for a 500 line patch to be reviewed?
1 week?
1 month?
3 months?
6 months?
1 year?

How about a large patch? Do you see 6 months as acceptable?

What is acceptable?

Bob Rossi

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Joel Brobecker]

> I don't see any fundamental problem here. This is after all a volunteer
> project and people have limited time to review patches, as they have
> limited time for anything they do on the project.

That's true. I am fortunate that most of my patches have been reviewed
in a timely fashion, but I understand Bob's frustration. The one thing
that has been annoying me most when patch review gets delayed is that
I tend to forget the details after a while. If the reviewer asks me some
specific questions during the review, it takes me a while to get back up
to speed. It's easier if the review occurred within a week. And there's
also the fact that the patch may no longer apply cleanly.

I agree with Eli that a one week delay for patch review is good.

-- 
Joel

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[David Carlton]

On Tue, 23 Mar 2004 08:56:33 -0800, Joel Brobecker <brobecker@gnat.com> said:

> The one thing that has been annoying me most when patch review gets
> delayed is that I tend to forget the details after a while. If the
> reviewer asks me some specific questions during the review, it takes
> me a while to get back up to speed. It's easier if the review
> occurred within a week. And there's also the fact that the patch may
> no longer apply cleanly.

This happens to me fairly often too.

David Carlton
carlton@kealia.com

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Eli Zaretskii]

> From: David Carlton <carlton@kealia.com>
> Date: Tue, 23 Mar 2004 13:27:01 -0800
> 
> On Tue, 23 Mar 2004 08:56:33 -0800, Joel Brobecker <brobecker@gnat.com> said:
> 
> > The one thing that has been annoying me most when patch review gets
> > delayed is that I tend to forget the details after a while. If the
> > reviewer asks me some specific questions during the review, it takes
> > me a while to get back up to speed. It's easier if the review
> > occurred within a week. And there's also the fact that the patch may
> > no longer apply cleanly.
> 
> This happens to me fairly often too.

I think it happens to almost everyone.

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[David Carlton]

On Tue, 23 Mar 2004 10:49:51 -0500, Robert Dewar <dewar@gnat.com> said:

> Now perhaps more people should have approval authority, but that of
> course has its own draw backs in terms of keeping the entire project
> under control. There is always a fundamental trade off between
> reliability/stability/control and adding nice new features.

This is perhaps obvious, but increasing the number of people who can
approve patches can add to reliability just as easily as it can hurt
reliability: they might be approving patches that fix bugs.

It's not entirely clear to me that stability (which I'm reading as
meaning lack of changes in the code itself) and control are inherently
good things, for that matter.  You can have too little or too much of
either, and I would imagine that projects can be successful across a
broad spectrum of stability and control.

David Carlton
carlton@kealia.com

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Eli Zaretskii]

> From: David Carlton <carlton@kealia.com>
> Date: Tue, 23 Mar 2004 13:25:52 -0800
> 
> It's not entirely clear to me that stability (which I'm reading as
> meaning lack of changes in the code itself) and control are inherently
> good things, for that matter.

IMHO, as with every issue that involves non-trivial trade-offs, the
answer is ``it depends''...

It strikes me that you and Robert don't actually disagree here; it's
just that Robert thinks about a situation where a small number of
persons who control a project manage to process important chores
quickly and timely and give the other participants a feeling that
their contributions are welcome, while you think about a situation
that is less optimal.  That is, control and stability are perceived as
good when the community members feel they are used to their benefit.

Re: [Gdbheads] A small patch case study, -file-list-exec-source-files

[Richard Stallman]

    Now perhaps more people should have approval
    authority, but that of course has its own draw backs in terms of
    keeping the entire project under control.

One option that could be considered is that a patch can be 
approved by two people jointly.  If we don't want to give
additional people individual authority to approve patches,
it might be ok to give such authority to a pair of people,
or to a few pairs.  That might help things move.

Feb's patch resolution rate

[Andrew Cagney]

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

Hello,

I think its very important that we see the full picture here as 
otherwize we'll too easily gain a false or misleading impression of the 
current state of play (bad news or rumors unfortunatly gain traction far 
quicker that positives).

To this end, I've attached a breakdown of February's patches that 
required approval (i.e., I excluded self approved patches).  Looking at 
the numbers:

- ~60 patches

- typical (median) review time is 1 day

- average review time is ~2.5 days

- pinging helps (80% of pings got resolved)

- ~12% of patches are unresolved (pinged 25%, unpinged 75%)

I think bob has drawn a really short straw straw here. Bob's posted a 
very complex patch (contrary to assertion as it modifies symtab and an 
interface) and depends on comments from a specialized reviewer.

Andrew

PS: I probably screwed up the numbers but they are in the right 
ballpark, and I'd better follow up on some of my own patches.

[-- Attachment #2: x --]
[-- Type: text/plain, Size: 6113 bytes --]

posted   ping? resolved    subject, poster
2004-02-28   2004-02-03  4 [rfa/arm] Handle bx and blx, Daniel Jacobowitz
2004-02-28   2004-03-01? 2 [rfa/mi testsuite] Handle missing inferior I/O for mi-syn-frame.exp, Daniel Jacobowitz
2004-02-28   2004-02-28  0 [rfa/binutils] distclean .cvsignore?, Andrew Cagney
2004-02-28   2004-02-28  0 [rfa] C++ testsuite fix for unsigned char, Daniel Jacobowitz
2004-02-28   2004-03-05  6 [rfa/remote] Reread symbols on 'target remote', Daniel Jacobowitz
2004-02-27   2004-02-28  1 [RFA] Detect non-timeout fails in chng-syms.exp, Fred Fish
2004-02-26   2004-02-28  2 [rfa:amd64] Fetch 32-bit thread area, Andrew Cagney
2004-02-26   2004-02-28  2 [rfa/amd64] Zero fill 32-bit registers, Andrew Cagney
2004-02-26   2004-02-26  0 [rfa] cris-tdep.c: Frame unwind and dummy call fixes, Orjan Friberg
2004-02-25   2004-02-25  0 [RFA/tui] (solaris) Fix tui.c build failure, Joel Brobecker
2004-02-24   2004-02-25  1 [RFA] Handle unsupported "-shared" in gdb1555.exp test, Fred Fish
2004-02-24 p 2004-03-12 17 [RFA/dwarf] Don't process types multiple times, Daniel Jacobowitz
2004-02-24                 -file-list-exec-source-files, Bob Rossi
2004-02-24   2004-02-26  2 [RFA/dwarf] Allocate abbrevs from a new obstack, Daniel Jacobowitz
2004-02-24   2004-02-26  2 [RFA/dwarf] Optimize partial DIE reading for uninteresting DIEs, Daniel Jacobowitz
2004-02-24                 [RFA/testsuite] Add testcase for included files, Joel Brobecker
2004-02-24                 [RFA/dwarf-2] Add support for included files, Joel Brobecker
2004-02-24   2004-02-24  0 [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada, Joel Brobecker
2004-02-25   2004-02-26  1 Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada, Joel Brobecker
2004-02-24 p               [rfa] fix for PR c++/1553, David Carlton
2004-02-24                 [patch/rfa] Delete jmisc2.exp, Andrew Cagney
2004-02-24                 [patch/rfa] Test java's "break main", Andrew Cagney
2004-02-23   2004-02-24  1 [RFA] Fix TUI build failure on AiX 4.3.2, Joel Brobecker
2004-02-23   2004-02-25  2 [RFA/RFC] (hppa/tui) Fix build failure due to missing wborder, Joel Brobecker
2004-02-23   2004-02-24  1 [rfa/doco] Update to fdl 1.2, Andrew Cagney
2004-02-22   2004-02-22  0 [RFA] Fix gdb.base/gdb1250.exp to work when abort() is in a shared library, Fred Fish
2004-02-22   2004-02-23  1 [RFA] Fix a crash in coffread.c (Was: GDB 6.1 branch 2004-02-26-gmt), Eli Zaretskii
2004-02-20   2004-02-20    [RFA/PROBLEMS] Document the QUIT problem, Joel Brobecker
2004-02-19   2004-02-25  6 [RFA] Fix PR tdep/1291, SH prologue scanning bug, Fred Fish
2004-02-25 p 2004-03-05  9 [RFA] sh-tdep.c: New patch solving gdb1291.exp (was Re: [RFA] Fix PR tdep/1291, SH prologue scanning bug), Corinna Vinschen
2004-02-19   2004-02-26  7 [RFA] Fix incorrect use of "until" command in gdb.arch/gdb1431, Fred Fish
2004-02-19   2004-02-23  4 [RFA]: pending breakpoint cosmetic change, Jeff Johnston
2004-02-19   2004-02-19  0 [RFA/dwarf-2] Fix for the null record problem, Joel Brobecker
2004-02-25   2004-02-26  1 Re: [RFA/dwarf-2] Fix for the null record problem, Joel Brobecker
2004-02-18 p 2004-03-05 16 [RFA] sh-tdep.c: Fix erroneus register skipping in sh_print_registers_info, Corinna Vinschen
2004-02-17   2004-02-17  0 -symbol-list-lines doco update, Bob Rossi
2004-02-16   2004-02-16  0 [rfa] Add SYMBOL_SET_LINKAGE_NAME, Daniel Jacobowitz
2004-02-16   2004-02-16  0 [rfa] Use SYMBOL_SET_NAMES in hpread, Daniel Jacobowitz
2004-02-16                 [rfa] Remove add_psymbol_with_dem_name_to_list and uses, Daniel Jacobowitz
2004-02-16   2004-02-16  0 [rfa/symbol readers] Clean up setting symbols' names, Daniel Jacobowitz
2004-02-16   2004-02-17  1 [RFA] sh-tdep.*: Rename DSP bank registers, Corinna Vinschen
2004-02-15   2004-02-16  1 [rfa:doco] mention gdbarch_obstack_zalloc in per-module data, Andrew Cagney
2004-02-13   2004-02-16  3 [rfa:doco] Zap mi1 reference, Andrew Cagney
2004-02-12   2004-02-16  4 [RFA] Eliminate useless test of variable before overwriting it in sh-tdep.c, Fred Fish
2004-02-12   2004-02-19  7 [RFA] Handle sh-elf-gcc scheduling code into a prologue when no debug info present, Fred Fish
2004-02-12   2004-02-13  1 [RFA] sh-sim loose ends, Michael Snyder
2004-02-12   2004-02-16  4 [patch/rfc; rfa:doco] Add -Wunused-function to -Werror list, Andrew Cagney
2004-02-12   2004-02-16  4 [RFA] sh-tdep.c: Define only the minimal register set in sh_generic_register_name, Corinna Vinschen
2004-02-11   2004-02-12  1 [RFA/doco] Format c++ name, Elena Zannoni
2004-02-11   2004-02-16  5 [RFA] sh-tdep.c: optimize fv_reg_base_num and dr_reg_base_num, Corinna Vinschen
2004-02-10   2004-02-10  0 [RFA] Fix several problems with the gdb.arch/gdb1291.exp test, Fred Fish
2004-02-10   2004-02-11  1 [RFA (revised)] sh-sim, expand the opcode table, Michael Snyder
2004-02-10   2004-02-11  1 [rfa/mips] Shared library trampoline support for mips-linux, Daniel Jacobowitz
2004-02-10   2004-02-10  0 [RFA/doco] add obstacks to gdbint.texi, Elena Zannoni
2004-02-10   2004-02-16  6 [RFA] sh-tdep.c: optimize and rename virtual register conversion functions, Corinna Vinschen
2004-02-09   2004-02-09  0 [RFA]: Patch for ia64-tdep.c to cross-compile, Jeff Johnston
2004-02-09                 [rfa/testsuite/lib] get_compiler_info: two improvements, Michael Elizabeth Chastain
2004-02-09   2004-02-09  0 [rfa/testsuite] gdb1250.exp: make 'break abort' work with new pending breakpoints, Michael Elizabeth Chastain
2004-02-06   2004-02-07  1 [RFA] sh-sim: free up some room in jump_table, Michael Snyder
2004-02-05   2004-02-06  1 [RFA] sh-sim: thislock/prevlock tweak, Michael Snyder
2004-02-05   2004-03-05  0 [RFA] use frame IDs to detect function calls while stepping, Joel Brobecker
2004-02-04   2004-02-10  6 [RFA]: patch to ia64.inc in gdb.asm testsuite, Jeff Johnston
2004-02-02   2004-02-02  0 [RFA] Fix testsuite gdb.base/bang.exp to work with remote targets, Fred Fish
2004-02-01   2004-02-01  0 [RFA] Use runto_main in testsuite for consistency, Fred Fish
2004-02-01 p 2004-02-12 11 [rfa] qSymbol in remote_wait, Daniel Jacobowitz

Re: Feb's patch resolution rate

[David Carlton]

On Tue, 23 Mar 2004 15:59:15 -0500, Andrew Cagney <cagney@gnu.org> said:

> To this end, I've attached a breakdown of February's patches that
> required approval (i.e., I excluded self approved patches).  Looking
> at the numbers:

> - ~60 patches

> - typical (median) review time is 1 day

> - average review time is ~2.5 days

I assume these only count the resolved patches?  Because:

> - pinging helps (80% of pings got resolved)

> - ~12% of patches are unresolved (pinged 25%, unpinged 75%)

If 12% of patches have been unresolved, then those alone should be
contributing about 3 days to the average review time.

Another question to ask is: how would allowing global maintainers
to approve patches have improved the situation?  Just looking at
unreviewed patches, we see:

> 2004-02-24                 -file-list-exec-source-files, Bob Rossi

I don't know if this would have been approved by now; hard to say.

> 2004-02-24                 [patch/rfa] Delete jmisc2.exp, Andrew Cagney
> 2004-02-24                 [patch/rfa] Test java's "break main", Andrew Cagney
> 2004-02-09                 [rfa/testsuite/lib] get_compiler_info: two improvements, Michael Elizabeth Chastain

These are all in areas of the testsuite without active maintainers,
where we nonetheless allow those inactive maintainers to block
approval.  These all would have gotten quickly approved otherwise.

> 2004-02-24                 [RFA/testsuite] Add testcase for included files, Joel Brobecker
> 2004-02-24                 [RFA/dwarf-2] Add support for included files, Joel Brobecker

I don't know enough about this to know how quickly it would have been
approved.

> 2004-02-16                 [rfa] Remove add_psymbol_with_dem_name_to_list and uses, Daniel Jacobowitz

I assume Daniel would have approved it himself by now.

> 2004-02-24 p               [rfa] fix for PR c++/1553, David Carlton

An extended version of this patch actually did get approved recently;
Daniel, however, favorably commented on the original patch very soon
after it was submitted, so I'm sure it would have gone in much more
quickly if he had been able to approve it.

Corinna has also been waiting for some time for approval for a patch
to minsysms.c (maybe it was from the beginning of March, instead of
February, though); there, too, Daniel quickly commented on the patch,
but he can't approve it.


So, based on this data, it seems to me that allowing global
maintainers to approve patches in all areas of GDB would have made a
significant impact on patch approval time - at least half of the
patches that have been waiting the longest for approval would have
gotten approved much more quickly.  Admittedly, the sample is somewhat
skewed: there aren't normally so many patches to dead areas of the
testsuite.

David Carlton
carlton@kealia.com

Re: Feb's patch resolution rate

[Andrew Cagney]

>>> - typical (median) review time is 1 day
> 
> 
>>> - average review time is ~2.5 days
> 
> 
> I assume these only count the resolved patches?  Because:

Obviously, hence the ~.  The median, however, would not change.

As you note:

> Admittedly, the sample is somewhat
> skewed: there aren't normally so many patches to dead areas of the
> testsuite.

And that has, in part, just been resolved.

BTW, did you ever get round to doing an analysis on who was reviewing 
the symbol table patches.

Andrew

Re: Feb's patch resolution rate

[David Carlton]

On Tue, 23 Mar 2004 16:31:52 -0500, Andrew Cagney <cagney@gnu.org> said:

> BTW, did you ever get round to doing an analysis on who was reviewing
> the symbol table patches.

I haven't done a formal analysis, no, but my impression is that Elena
usually reviews my patches and that Jim usually reviews Daniel's
patches, and that Elena also reviews patches that aren't sent by
either me or Daniel.  My impression is also that I send out more (and
larger?) symtab patches than Daniel does, so Elena does a lot more
work than Jim.  (This may change, however - my patches are largely in,
and I'm in no hurry to generate significantly many more right now,
whereas Daniel has projects still in progress.)

I'm not entirely sure why you bring this up, but just in case, let me
state once again: my complaints about patch review rate do not mean
that I'm angry at any of the current patch reviewers: quite the
contrary.  In particular, Elena always does a very conscientious job
of patch review, her comments are always to the point, I've never had
difficulties resolving issues concerning specific patches on which she
and I disagree, and I'm sure that she has far more than enough to do
outside of patch review that the amount of reviewing that she
currently does imposes a significant burden on her time.  (I assume
the same is true for Jim as well; as I said above, however, I interact
with him less frequently during patch review.)

My point is simply that, in the presence of other people who are quite
competent to review patches in that area, it seems very strange to me
to not allow them to contribute.  In particular, given that Daniel
knows the symtab code well (he's done more work on it over the last
year and a half than either symtab maintainer, and you yourself were
urging him to work on DW_OP_piece support), given that he's the C++
maintainer, given that he's a global maintainer, and given that he
always looks at my C++-related symtab patches anyways (and doesn't
just skim them - he's quite willing to complain about them when
appropriate), it seems very strange to me that he's not allowed to
approve my C++-related symtab patches.

If your or Elena feels that she is doing an unfair amount of symtab
reviewing (and I would agree with that), there's a fix available that
is both easier and more likely to be effective than nagging Jim Blandy
some more.  I'm sorry that you and Jim apparently have a fair amount
of bad blood between you, but I don't think presenting this as "Elena
good, Jim bad" is useful right now.

David Carlton
carlton@kealia.com

Re: Feb's patch resolution rate

[Eli Zaretskii]

> Date: Tue, 23 Mar 2004 16:31:52 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> >>> - typical (median) review time is 1 day
> > 
> > 
> >>> - average review time is ~2.5 days
> > 
> > 
> > I assume these only count the resolved patches?  Because:
> 
> Obviously, hence the ~.  The median, however, would not change.

Careful here: statistics are sometimes worse than a lie ;-)

Seriously, though: about my only comment to the figures that you
presented is that it is IMHO wrong in this case to use estimators,
such as the median, that are resistant to outliers.  That's because no
one, to the best of my knowledge, is claiming that GDB development is
dysfunctional.  As long as GDB maintenance as a whole works fairly
well, the average figures of any reasonable performance estimator will
be good.  IMHO, it is the (relatively rare) exceptions from the rule
that bothered and continue to bother those among us who came up with
suggestions to modify the existing practices.  And it is precisely
those exceptions that the median and its ilk give a zero weight.

In other words, to quantify the validity of complaints about the
current maintenance procedures, one needs to analyze and study the
outliers, those cases that are in the tails of the distribution, not
the average figures that are bound to be good by any measure, as GDB
is, by and large, a successful project.

These discussions grew from uneasy feelings, to put it mildly, shared
by several active maintainers.  As any good psychologist will tell
you, people are not using averages or medians when forming their
feelings, their reaction to outliers is acute and disproportional to
the actual percentiles.  If we want to solve these kinds of problems,
I think we need to summon techniques that closely follow these human
tendencies.

That said, I think it's a Good Thing that you posted those figures:
they allow us put the issue in perspective.  We just need to augment
the average figures with similarly quantitative analysis of the cases
where patch review took an exceptionally long time.  (Any takers? ;-)

Re: [Gdbheads] Re: Feb's patch resolution rate

[Richard Stallman]

      That's because no
    one, to the best of my knowledge, is claiming that GDB development is
    dysfunctional.  As long as GDB maintenance as a whole works fairly
    well, the average figures of any reasonable performance estimator will
    be good.  IMHO, it is the (relatively rare) exceptions from the rule
    that bothered and continue to bother those among us who came up with
    suggestions to modify the existing practices.

I can understand that these occasional long delays cause annoyance to
the people who wrote those particular patches.  However, I don't think
that occasional long delays indicate a fundamental problem in the way
gdb is being maintained.  It seems to be basically adequate.

That doesn't mean it couldn't be better.  I will ask the gdb
committee, whose membership I have just updated, to look into finding
a procedure to help deal with these long-delayed patches.

Re: [Gdbheads] Re: Feb's patch resolution rate

[Bob Rossi]

On Wed, Mar 24, 2004 at 09:00:31PM -0500, Richard Stallman wrote:
>       That's because no
>     one, to the best of my knowledge, is claiming that GDB development is
>     dysfunctional.  As long as GDB maintenance as a whole works fairly
>     well, the average figures of any reasonable performance estimator will
>     be good.  IMHO, it is the (relatively rare) exceptions from the rule
>     that bothered and continue to bother those among us who came up with
>     suggestions to modify the existing practices.
> 
> I can understand that these occasional long delays cause annoyance to
> the people who wrote those particular patches.  However, I don't think
> that occasional long delays indicate a fundamental problem in the way
> gdb is being maintained.  It seems to be basically adequate.

Agreed. However, IMO, Ian is correct.

   Maintainers must take responsibility for looking over patches quickly,
   and approving them, rewriting them to be acceptable, rejecting them
   with an explanation, or suggesting changes.  Maintainers who don't
   accomplish that are not effective maintainers.  That is not to say
   that they can not be effective contributors, or that they can not be
   very good at maintaining code and making technical decisions.

I think this is the bottom line. Maintainers need to review patches quickly. 
Everyone seems to agree that one week is considered quick. Is there a better 
definition of quick?

Is quick linear with the size of the patch?

To me one month is not quick. Is it to anyone else? Everyone seems to
ignore this question :)

> That doesn't mean it couldn't be better.  I will ask the gdb
> committee, whose membership I have just updated, to look into finding
> a procedure to help deal with these long-delayed patches.

I don't know much about the patches submitted to GDB and the average
review time, but Andrew seemed to make it look as if most patches are
reviewed quickly. 

What about the patches that are not reviewed quickly?

The real question is, what incentive does a maintainer have to review a
patch quickly?

Also, if the testsuite passes, and the initial patch looks good, why
would it take so long to accept the patch? Isn't the definition of
"stable" for GDB, "The testsuite works the same way after the patch as
before"?

Thanks,
Bob Rossi

Re: [Gdbheads] Re: Feb's patch resolution rate

[Robert Dewar]

Bob Rossi wrote:

> Is quick linear with the size of the patch?

To me, quick varies with the interest/importance/complexity/size of the
patch, and it is impossible to make firm rules. Probably a reasonable
rule is to try to make sure that patches just do not sit with no
response, i.e. that you at least get some feedback as to why there
is a delay.

Re: [Gdbheads] Re: Feb's patch resolution rate

[Eli Zaretskii]

> Date: Wed, 24 Mar 2004 23:13:31 -0500
> From: Bob Rossi <bob@brasko.net>
> 
> Is quick linear with the size of the patch?

No, not IMO.  A large patch takes longer to review, but it's not true
that a 20-line patch takes twice as much as a 10-line patch.  To me,
most of the reviewing time is spent looking at the current sources
and thinking about potential problems with the patch applied, or
testing the patched version.  These activities don't take time that
is proportional to the patch size.

IMHO, a patch that is too long to be reviewed in reasonable time is
too long, period.  The person who submitted such a patch should be
asked to break it down into several smaller patches.

> To me one month is not quick. Is it to anyone else? Everyone seems to
> ignore this question :)

I think one month is too long.

(There, I didn't ignore it ;-)

> The real question is, what incentive does a maintainer have to review a
> patch quickly?

None, except his/her own sense of a job well done (or not so well
done).

> Also, if the testsuite passes, and the initial patch looks good, why
> would it take so long to accept the patch?

The problem is precisely that: deciding whether the patch ``looks
good''.  It's not a trivial decision to make.  One needs to think
about possible implications of the patch, both in its immediate area
and elsewhere in GDB.  There are no automated procedures for that.
That's why we need human maintainers, and that's why maintainers
don't always agree on whether a patch should go in as is.

> Isn't the definition of "stable" for GDB, "The testsuite works the
> same way after the patch as before"?

You seem to assume that the test suite tests every possible aspect of
GDB.  That isn't true, unfortunately.

Re: [Gdbheads] Re: Feb's patch resolution rate

[Mark Kettenis]

   Date: Wed, 24 Mar 2004 23:13:31 -0500
   From: Bob Rossi <bob@brasko.net>

   Is quick linear with the size of the patch?

Defenitely not.  Even if the time I need to review a patch is linear
with the size of the patch, the result would still be that longer
patches will take significantly longer to review.  Very often I will
be able to review small patches immediately, i.e. right after I've
read the message that contains the patch.  But if the patch is longer
I'll put it on my TODO list and come back to it when I've got some
spare time that I think is enough to review the patch.  I've got many
small slots of spare time, but larger time slots are much scarcer.  I
wouldn't be surprised if this results in exponential behaviour.

   Also, if the testsuite passes, and the initial patch looks good, why
   would it take so long to accept the patch? Isn't the definition of
   "stable" for GDB, "The testsuite works the same way after the patch as
   before"?

The simple fact that the patch works, doesn't mean that it is good.
Blindly applying such patches will threaten the maintainability of
GDB.  Also, for everything but patches to target-dependent code, the
testsuite will have to be run on a fair number of targets.

Mark

Re: [Gdbheads] Re: Feb's patch resolution rate

[Andrew Cagney]

>    Date: Wed, 24 Mar 2004 23:13:31 -0500
>    From: Bob Rossi <bob@brasko.net>
> 
>    Is quick linear with the size of the patch?
> 
> Defenitely not.

As a simple example, a new architecture takes relatively little time to 
review:

- did it get put through gdb_indent.sh (coding ok)
- did it get put through gdb_ari.sh (interfaces ok)
- anthing obviously garish
- can it break core-GDB (no)
- is there an assignment

Contrast that to a single addition to the architecture vector.  Too 
often the mechanism overlaps existing functionality and hence requires 
changes far wider than the apparent one line addition.

The symbol table is identical.

Andrew

Re: -file-list-exec-source-files

[Bob Rossi]

What do you think?

On Thu, Mar 11, 2004 at 08:25:08AM -0500, Bob Rossi wrote:
> What do you think?
> 
> Bob Rossi
> 
> On Sat, Mar 06, 2004 at 10:57:00AM -0500, Bob Rossi wrote:
> > Elena, thanks for taking the time to review my patch.
> > 
> > When is a good point to resubmit a patch? After every review, or after
> > all the issues are ironed out?
> > 
> > >  > Here is an initial patch for -file-list-exec-source-files.
> > >  > Some feedback would be appreciated.
> > >  > 
> > >  > I ran the testsuite and the results are the same before and after this
> > >  > patch.
> > >  > 
> > >  > Index: gdb/ChangeLog
> > >  > 	* dbxread.c (read_dbx_symtab): set pst->dirname when known
> > > 
> > > Each entry should start with capital letter and end with period.
> > > 
> > > I see some coding standards are not adhered to throughout the code.
> > > Most noticeably "foo ( int a )" should be "foo (int a)". Similarly for
> > > calls.
> > 
> > Ok, I will try to fix all of the coding standard errors. Is there a
> > program I can run on the source files before I create the diff that
> > formats the code according to the standard?
> > 
> > > 
> > >  > 
> > >  > Index: gdb/dbxread.c
> > >  > ===================================================================
> > >  > Index: gdb/dwarf2read.c
> > >  > ===================================================================
> > > 
> > > These are ok
> > 
> > Great!
> > 
> > >  >  
> > >  > Index: gdb/defs.h
> > >  > ===================================================================
> > >  > RCS file: /cvs/src/src/gdb/defs.h,v
> > >  > retrieving revision 1.143
> > >  > diff -w -u -r1.143 defs.h
> > >  > --- gdb/defs.h	23 Feb 2004 19:26:14 -0000	1.143
> > >  > +++ gdb/defs.h	25 Feb 2004 03:51:35 -0000
> > >  > @@ -616,8 +616,6 @@
> > >  >  
> > >  >  extern void init_last_source_visited (void);
> > >  >  
> > >  > -extern char *symtab_to_filename (struct symtab *);
> > >  > -
> > >  >  /* From exec.c */
> > >  >  
> > >  >  extern void exec_set_section_offsets (bfd_signed_vma text_off,
> > >  > Index: gdb/dwarf2read.c
> > >  > ===================================================================
> > >  > RCS file: /cvs/src/src/gdb/dwarf2read.c,v
> > >  > retrieving revision 1.135
> > >  > diff -w -u -r1.135 dwarf2read.c
> > >  > --- gdb/dwarf2read.c	21 Feb 2004 02:13:35 -0000	1.135
> > >  > +++ gdb/dwarf2read.c	25 Feb 2004 03:51:43 -0000
> > >  > @@ -316,6 +316,7 @@
> > >  >      unsigned int offset;
> > >  >      unsigned int abbrev;
> > >  >      char *name;
> > >  > +    char *dirname;
> > >  >      int has_pc_info;
> > >  >      CORE_ADDR lowpc;
> > >  >      CORE_ADDR highpc;
> > >  > @@ -1254,6 +1255,8 @@
> > >  >  				  objfile->global_psymbols.next,
> > >  >  				  objfile->static_psymbols.next);
> > >  >  
> > >  > +      pst->dirname = xstrdup ( comp_unit_die.dirname );
> > >  > +
> > >  >        pst->read_symtab_private = (char *)
> > >  >  	obstack_alloc (&objfile->objfile_obstack, sizeof (struct dwarf2_pinfo));
> > >  >        DWARF_INFO_BUFFER (pst) = dwarf_info_buffer;
> > >  > @@ -4326,6 +4329,10 @@
> > >  >  	  /* Prefer DW_AT_MIPS_linkage_name over DW_AT_name.  */
> > >  >  	  if (part_die->name == NULL)
> > >  >  	    part_die->name = DW_STRING (&attr);
> > >  > +	  break;
> > >  > +	case DW_AT_comp_dir:
> > >  > +	  if (part_die->dirname == NULL)
> > >  > +	    part_die->dirname = DW_STRING (&attr);
> > > 
> > > The dwarf2 specs say that the name is in the form ":pathname" or
> > > "hostname:pathname". Should we worry about the hostname? Does gcc emit
> > > that?  I have looked at a few executables and didn't see the hostname
> > > part.
> > 
> > It would probably just be best if you told me what case's you want me to
> > implement here. It seems that Jason Molenda understodd most of the
> > cases. I really don't know anything about what GCC emits and would would
> > be practical to implement.
> > 
> > >  > Index: gdb/source.c
> > >  > ===================================================================
> > > 
> > > this part I am not clear about.
> > 
> > Ok, Ok. I thought about this a lot. I think I made the best decision and
> > can describe why.
> > 
> > A few assumptions are in order. In order to get the fullname (abs path) 
> > to a file, GDB need's three things. The directory the file was compiled 
> > in (dirname), the filename in question (filename) and a list of paths 
> > to search.
> > 
> > > There is already a function called source_full_path_of() would it help
> > > if you used it?
> > 
> > The function source_full_path_of does not take into account 'dirname'.
> > It calls openp, which is not capable of finding the fullname of a file,
> > since it doesn't understand what dirname is. Basically, I don't even
> > think this function (source_full_path_of) is "truly" capable of 
> > finding the fullpath to a file. However, instead of removing it, 
> > I left it, since caller's of this function might be using for something 
> > I know nothing about.
> > 
> > > What is the difference between find_and_open_source and
> > > open_source_file?  I.e. why did you need to introduce it. I think it's
> > > not clear just from your comments about the file possibly baing moved
> > > around.
> > 
> > open_source_file was left around for backwards compatibility. The unit
> > source.c was used to calling a function, with just passing the symtab,
> > and getting back the symtab with a valid fullname. I could remove all
> > occurences of this function and replace it with symtab_to_fullname.
> > 
> > > I am a bit worried about the substitution of symtab_to_filename with
> > > symtab_to_fullname. The former returns null only if there is no
> > > symtab.  The latter returns null when there is no symtab OR when it
> > > cannot find the file. So the behavior is slightly different.
> > 
> > I basically think that the call -file-list-exec-source-files shouldn't 
> > 'cache' it's results. GDB looks for each file, every time it is
> > requested to get the fullname. This is because, the user could have 
> > changed the path, or moved/deleted the file. I don't think GDB should
> > just return the filename instead, of the fullname.
> > 
> > So, if find_and_open_source couldn't "find and open the source file", it
> > returns NULL. Also, as a side effect, fullname in the [ps]ymtab also
> > get's set to NULL.
> > 
> > The testsuite didn't seem to have a problem with this, and I think it
> > makes sense to not trick the caller into having results when it couldn't
> > find any.
> > 
> > If the caller really wanted this functionality,
> >   return s->filename; /* File not found.  Just use short name */
> > I believe it should be the caller's responsibility.
> > 
> > if ( symtab_to_fullname ( s ) == NULL )
> >    /* use symtab->filename */ 
> > else
> >    /* use symtab->fullname */
> > 
> > It doesn't really make sense to return the filename and not state that
> > it is not really the fullname. Also, if the caller tries to access
> > s->fullname, it will not be successful, because the file simply isn't
> > there.
> > 
> > >  > RCS file: /cvs/src/src/gdb/source.c,v
> > >  > retrieving revision 1.49
> > >  > diff -w -u -r1.49 source.c
> > >  > --- gdb/source.c	27 Jan 2004 23:19:51 -0000	1.49
> > >  > +++ gdb/source.c	25 Feb 2004 03:51:45 -0000
> > >  > @@ -805,30 +805,47 @@
> > >  >    return 1;
> > >  >  }
> > >  >  
> > >  > -
> > >  > -/* Open a source file given a symtab S.  Returns a file descriptor or
> > >  > -   negative number for error.  */
> > >  > -
> > >  > +/* This function is capable of finding the absolute path to a
> > >  > +   source file, and opening it, provided you give it an 
> > >  > +   OBJFILE and FILENAME. Both the DIRNAME and FULLNAME are only
> > >  > +   added suggestions on where to find the file. 
> > >  > +
> > >  > +   OBJFILE should be the objfile associated with a psymtab or symtab. 
> > >  > +   FILENAME should be the filename to open.
> > >  > +   DIRNAME is the compilation directory of a particular source file.
> > >  > +           Only some debug formats provide this info.
> > >  > +   FULLNAME can be the last known absolute path to the file in question.
> > >  > +
> > >  > +   On Success 
> > >  > +     A valid file descriptor is returned. ( the return value is positive )
> > >  > +     FULLNAME is set to the absolute path to the file just opened.
> > >  > +
> > >  > +   On Failure
> > >  > +     A non valid file descriptor is returned. ( the return value is negitive ) 
> > >  > +     FULLNAME is set to NULL.  */
> > >  >  int
> > >  > -open_source_file (struct symtab *s)
> > >  > +find_and_open_source ( 
> > >  > +  struct objfile *objfile,	
> > >  > +  const char *filename,
> > >  > +  const char *dirname,
> > >  > +  char **fullname )
> > >  >  {
> > > 
> > > coding standards....
> > 
> > Ok.
> > 
> > >  >    char *path = source_path;
> > >  >    const char *p;
> > >  >    int result;
> > >  > -  char *fullname;
> > >  >  
> > >  >    /* Quick way out if we already know its full name */
> > >  > -  if (s->fullname)
> > >  > +  if (*fullname)
> > >  >      {
> > >  > -      result = open (s->fullname, OPEN_MODE);
> > >  > +      result = open (*fullname, OPEN_MODE);
> > >  >        if (result >= 0)
> > >  >  	return result;
> > >  >        /* Didn't work -- free old one, try again. */
> > >  > -      xmfree (s->objfile->md, s->fullname);
> > >  > -      s->fullname = NULL;
> > >  > +      xmfree (objfile->md, *fullname);
> > >  > +      *fullname = NULL;
> > >  >      }
> > >  >  
> > >  > -  if (s->dirname != NULL)
> > >  > +  if (dirname != NULL)
> > >  >      {
> > >  >        /* Replace a path entry of  $cdir  with the compilation directory name */
> > >  >  #define	cdir_len	5
> > >  > @@ -841,60 +858,102 @@
> > >  >  	  int len;
> > >  >  
> > >  >  	  path = (char *)
> > >  > -	    alloca (strlen (source_path) + 1 + strlen (s->dirname) + 1);
> > >  > +	    alloca (strlen (source_path) + 1 + strlen (dirname) + 1);
> > >  >  	  len = p - source_path;
> > >  >  	  strncpy (path, source_path, len);	/* Before $cdir */
> > >  > -	  strcpy (path + len, s->dirname);	/* new stuff */
> > >  > +	  strcpy (path + len, dirname);	/* new stuff */
> > >  >  	  strcat (path + len, source_path + len + cdir_len);	/* After $cdir */
> > >  >  	}
> > >  >      }
> > >  >  
> > >  > -  result = openp (path, 0, s->filename, OPEN_MODE, 0, &s->fullname);
> > >  > +  result = openp (path, 0, filename, OPEN_MODE, 0, fullname);
> > >  >    if (result < 0)
> > >  >      {
> > >  >        /* Didn't work.  Try using just the basename. */
> > >  > -      p = lbasename (s->filename);
> > >  > -      if (p != s->filename)
> > >  > -	result = openp (path, 0, p, OPEN_MODE, 0, &s->fullname);
> > >  > +      p = lbasename (filename);
> > >  > +      if (p != filename)
> > >  > +	result = openp (path, 0, p, OPEN_MODE, 0, fullname);
> > >  >      }
> > >  >  
> > >  >    if (result >= 0)
> > >  >      {
> > >  > -      fullname = s->fullname;
> > >  > -      s->fullname = mstrsave (s->objfile->md, s->fullname);
> > >  > -      xfree (fullname);
> > >  > +      char *tmp_fullname;
> > >  > +      tmp_fullname = *fullname;
> > >  > +      *fullname = mstrsave (objfile->md, *fullname);
> > >  > +      xfree (tmp_fullname);
> > >  >      }
> > >  >    return result;
> > >  >  }
> > >  >  
> > >  > -/* Return the path to the source file associated with symtab.  Returns NULL
> > >  > -   if no symtab.  */
> > >  > +/* Open a source file given a symtab S.  Returns a file descriptor or
> > >  > +   negative number for error.  
> > >  > +   
> > >  > +   This function is a convience function to find_and_open_source. */
> > >  > +
> > >  > +int
> > >  > +open_source_file (struct symtab *s)
> > >  > +{
> > >  > +    if (!s)
> > >  > +      return -1;
> > >  > +
> > >  > +    return find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname );
> > >  > +}
> > >  > +
> > >  > +/* Finds the fullname that a symtab represents.
> > >  > +
> > >  > +   If this functions finds the fullname, it will save it in ps->fullname
> > >  > +   and it will also return the value.
> > >  >  
> > >  > +   If this function fails to find the file that this symtab represents,
> > >  > +   NULL will be returned and ps->fullname will be set to NULL.  */
> > >  >  char *
> > >  > -symtab_to_filename (struct symtab *s)
> > >  > +symtab_to_fullname (struct symtab *s)
> > >  >  {
> > >  > -  int fd;
> > >  > +  int r;
> > >  >  
> > >  >    if (!s)
> > >  >      return NULL;
> > >  >  
> > >  > -  /* If we've seen the file before, just return fullname. */
> > >  > +  /* Don't check s->fullname here, the file could have been 
> > >  > +     deleted/moved/..., look for it again */
> > >  > +  r = find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname);
> > >  >  
> > >  > -  if (s->fullname)
> > >  > +  if (r)
> > >  > +  {
> > >  > +    close (r);
> > >  >      return s->fullname;
> > >  > +  }
> > >  >  
> > >  > -  /* Try opening the file to setup fullname */
> > >  > +  return NULL;
> > >  > +}
> > >  >  
> > >  > -  fd = open_source_file (s);
> > >  > -  if (fd < 0)
> > >  > -    return s->filename;		/* File not found.  Just use short name */
> > >  > +/* Finds the fullname that a partial_symtab represents.
> > >  >  
> > >  > -  /* Found the file.  Cleanup and return the full name */
> > >  > +   If this functions finds the fullname, it will save it in ps->fullname
> > >  > +   and it will also return the value.
> > >  >  
> > >  > -  close (fd);
> > >  > -  return s->fullname;
> > >  > +   If this function fails to find the file that this partial_symtab represents,
> > >  > +   NULL will be returned and ps->fullname will be set to NULL.  */
> > >  > +char *
> > >  > +psymtab_to_fullname (struct partial_symtab *ps)
> > >  > +{
> > >  > +  int r;
> > >  > +
> > >  > +  if (!ps)
> > >  > +    return NULL;
> > >  > +
> > >  > +  /* Don't check ps->fullname here, the file could have been
> > >  > +     deleted/moved/..., look for it again */
> > >  > +  r = find_and_open_source ( ps->objfile, ps->filename, ps->dirname, &ps->fullname);
> > >  > +
> > >  > +  if (r) 
> > >  > +  {
> > >  > +    close (r);
> > >  > +    return ps->fullname;
> > >  >  }
> > >  >  \f
> > >  > +  return NULL;
> > >  > +}
> > >  >  
> > >  >  /* Create and initialize the table S->line_charpos that records
> > >  >     the positions of the lines in the source file, which is assumed
> > > 
> > > 
> > > 
> > >  > Index: gdb/source.h
> > >  > ===================================================================
> > >  > Index: gdb/symtab.c
> > >  > ===================================================================
> > > 
> > > These are obvious if the rest goes in.
> > > 
> > > 
> > >  > Index: gdb/symtab.h
> > >  > ===================================================================
> > > 
> > > OK.
> > > 
> > > 
> > >  > Index: gdb/mi/mi-cmd-file.c
> > >  > ===================================================================
> > > 
> > > 
> > >  > +static const char * const FILENAME = "filename";
> > >  > +static const char * const FULLNAME = "fullname";
> > > 
> > > I don't think these are necessary.
> > 
> > It just unifies the output convention I am using in the
> > mi-cmd-file unit. What would you prefer to see?
> > 
> > >  >  
> > >  >  /* Return to the client the absolute path and line number of the 
> > >  >     current file being executed. */
> > >  > @@ -39,7 +43,6 @@
> > >  >    if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_file", argc, argv) )
> > >  >      error ("mi_cmd_file_list_exec_source_file: Usage: No args");
> > >  >  
> > >  > -  
> > >  >    /* Set the default file and line, also get them */
> > >  >    set_default_source_symtab_and_line();
> > >  >    st = get_current_source_symtab_and_line();
> > >  > @@ -51,17 +54,67 @@
> > >  >      error ("mi_cmd_file_list_exec_source_file: No symtab");
> > >  >  
> > >  >    /* Extract the fullname if it is not known yet */
> > >  > -  if (st.symtab->fullname == NULL)
> > >  > -    symtab_to_filename (st.symtab);
> > >  > -
> > >  > -  /* We may not be able to open the file (not available). */
> > >  > -  if (st.symtab->fullname == NULL)
> > >  > -    error ("mi_cmd_file_list_exec_source_file: File not found");
> > > 
> > > Why get rid of the error message?
> > 
> > Ok.
> > 
> > >  > +  symtab_to_fullname (st.symtab);
> > >  >  
> > >  >    /* Print to the user the line, filename and fullname */
> > >  >    ui_out_field_int (uiout, "line", st.line);
> > >  > -  ui_out_field_string (uiout, "file", st.symtab->filename);
> > >  > -  ui_out_field_string (uiout, "fullname", st.symtab->fullname);
> > >  > +  ui_out_field_string (uiout, FILENAME, st.symtab->filename);
> > >  > +  
> > >  > +  /* We may not be able to open the file (not available). */
> > >  > +  if (st.symtab->fullname)
> > >  > +    ui_out_field_string (uiout, FULLNAME, st.symtab->fullname);
> > >  > +
> > > 
> > > if this test fails shouldn't some warning/error be issued?
> > 
> > I don't know. I am thinking that GDB should just return the absolute
> > path to all of the source files it can find. If it can not find some,
> > should it issue a warning? That way the front end could say, "you need
> > to add a directory to the source search path".
> > 
> > >  > +  return MI_CMD_DONE;
> > >  > +}
> > >  > +
> > >  > +enum mi_cmd_result
> > >  > +mi_cmd_file_list_exec_source_files(char *command, char **argv, int argc)
> > >  > +{
> > >  > +  struct symtab *s;
> > >  > +  struct partial_symtab *ps;
> > >  > +  struct objfile *objfile;
> > >  > +
> > >  > +  if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_files", argc, argv) )
> > >  > +    error ("mi_cmd_file_list_exec_source_files: Usage: No args");
> > >  > +
> > >  > +  /* Print the table header */
> > >  > +  ui_out_begin ( uiout, ui_out_type_list, "files");
> > >  > +
> > >  > +  /* Look at all of the symtabs */
> > >  > +  ALL_SYMTABS (objfile, s)
> > >  > +  {
> > >  > +    ui_out_begin ( uiout, ui_out_type_tuple, NULL);
> > >  > +
> > >  > +    ui_out_field_string (uiout, FILENAME, s->filename);
> > >  > +
> > >  > +	/* Extract the fullname if it is not known yet */
> > >  > +	symtab_to_fullname (s);
> > >  > +
> > >  > +	if (s->fullname)
> > >  > +      ui_out_field_string (uiout, FULLNAME, s->fullname);
> > >  > +
> > >  > +    ui_out_end ( uiout, ui_out_type_tuple );
> > >  > +  }
> > >  > +
> > >  > +  /* Look at all of the psymtabs */
> > >  > +  ALL_PSYMTABS (objfile, ps)
> > >  > +  {
> > >  > +    if (!ps->readin) {
> > > 
> > > coding standards....
> > 
> > Ok.
> > 
> > >  > +      ui_out_begin ( uiout, ui_out_type_tuple, NULL);
> > >  > +
> > >  > +      ui_out_field_string (uiout, FILENAME, ps->filename);
> > >  > +
> > >  > +      /* Extract the fullname if it is not known yet */
> > >  > +	  psymtab_to_fullname (ps);
> > >  > +
> > >  > +	  if (ps->fullname) 
> > >  > +	    ui_out_field_string (uiout, FULLNAME, ps->fullname);
> > >  > +
> > >  > +      ui_out_end ( uiout, ui_out_type_tuple );
> > >  > +    }
> > >  > +  }
> > >  > +
> > >  > +  ui_out_end ( uiout, ui_out_type_list );
> > >  >  
> > >  >    return MI_CMD_DONE;
> > >  >  }
> > > 
> > > 
> > > 
> > >  > Index: gdb/mi/mi-cmds.c
> > >  > ===================================================================
> > > 
> > >  > Index: gdb/mi/mi-cmds.h
> > >  > ===================================================================
> > > 
> > > these changes are ok.
> > 
> > Great!
> > 
> > >  > Index: gdb/testsuite/gdb.mi/mi-file.exp
> > >  > ===================================================================
> > >  > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-file.exp,v
> > >  > retrieving revision 1.1
> > >  > diff -w -u -r1.1 mi-file.exp
> > >  > --- gdb/testsuite/gdb.mi/mi-file.exp	2 Apr 2003 22:10:35 -0000	1.1
> > >  > +++ gdb/testsuite/gdb.mi/mi-file.exp	25 Feb 2004 03:52:36 -0000
> > >  > @@ -55,7 +55,7 @@
> > >  >  
> > >  >      # get the path and absolute path to the current executable
> > >  >      mi_gdb_test "111-file-list-exec-source-file" \
> > >  > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> > >  > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> > > 
> > > Wouldn't this break existing MI parsers?
> > 
> > Yes. I figured it could be mi2. Also, for some reason, I thought no one
> > would be using this function since I wrote it for CGDB, and I haven't
> > used it yet. I have a larger plan in mind for MI, than just these 2
> > commands (-file-list-exec-source-file and -file-list-exec-source-files).
> > I would like to add the fullname to a lot of commands. However, I think
> > 'filename' and 'fullname' should be standardized, so that front end
> > writers immediatly understand what they are. It is awkard to have 1
> > function say "file=" and another say "filename=", when those 2 words
> > mean the same thing. 
> > 
> > However, if this changes isn't acceptable, I can change it back.
> > 
> > >  >                 "request path info of current source file (${srcfile})"
> > >  >  }
> > >  >  
> > >  > Index: gdb/testsuite/gdb.mi/mi2-file.exp
> > >  > ===================================================================
> > >  > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi2-file.exp,v
> > >  > retrieving revision 1.1
> > >  > diff -w -u -r1.1 mi2-file.exp
> > >  > --- gdb/testsuite/gdb.mi/mi2-file.exp	7 Aug 2003 17:47:42 -0000	1.1
> > >  > +++ gdb/testsuite/gdb.mi/mi2-file.exp	25 Feb 2004 03:52:36 -0000
> > >  > @@ -47,7 +47,7 @@
> > >  >  mi_gdb_reinitialize_dir $srcdir/$subdir
> > >  >  mi_gdb_load ${binfile}
> > >  >  
> > >  > -proc test_tbreak_creation_and_listing {} {
> > >  > +proc test_file_list_exec_source_file {} {
> > >  >      global srcfile
> > >  >      global srcdir
> > >  >      global subdir
> > >  > @@ -55,11 +55,21 @@
> > >  >  
> > >  >      # get the path and absolute path to the current executable
> > >  >      mi_gdb_test "111-file-list-exec-source-file" \
> > >  > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> > >  > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> > >  >                 "request path info of current source file (${srcfile})"
> > >  >  }
> > >  >  
> > >  > -test_tbreak_creation_and_listing
> > >  > +proc test_file_list_exec_source_files {} {
> > >  > +    global srcfile
> > >  > +
> > >  > +    # get the path and absolute path to the current executable
> > >  > +    mi_gdb_test "222-file-list-exec-source-files" \
> > >  > +	    "222\\\^done,files=\\\[\{filename=\".*/${srcfile}\",fullname=\"/.*/${srcfile}\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\}\\\]" \
> > > 
> > >  > +              "Getting a list of source files failed."
> > >                                                  ^^^^^^^
> > >                                                   why failed?
> > 
> > OOO, That isn't an error condition, it's just a comment. I see.
> > 
> > Thanks,
> > Bob Rossi

Re: -file-list-exec-source-files

[Bob Rossi]

Could someone please review this patch?

It has been 6 weeks. Pinging has not got me very far.

Bob Rossi

On Mon, Mar 29, 2004 at 03:55:46PM -0500, Bob Rossi wrote:
> What do you think?
> 
> On Thu, Mar 11, 2004 at 08:25:08AM -0500, Bob Rossi wrote:
> > What do you think?
> > 
> > Bob Rossi
> > 
> > On Sat, Mar 06, 2004 at 10:57:00AM -0500, Bob Rossi wrote:
> > > Elena, thanks for taking the time to review my patch.
> > > 
> > > When is a good point to resubmit a patch? After every review, or after
> > > all the issues are ironed out?
> > > 
> > > >  > Here is an initial patch for -file-list-exec-source-files.
> > > >  > Some feedback would be appreciated.
> > > >  > 
> > > >  > I ran the testsuite and the results are the same before and after this
> > > >  > patch.
> > > >  > 
> > > >  > Index: gdb/ChangeLog
> > > >  > 	* dbxread.c (read_dbx_symtab): set pst->dirname when known
> > > > 
> > > > Each entry should start with capital letter and end with period.
> > > > 
> > > > I see some coding standards are not adhered to throughout the code.
> > > > Most noticeably "foo ( int a )" should be "foo (int a)". Similarly for
> > > > calls.
> > > 
> > > Ok, I will try to fix all of the coding standard errors. Is there a
> > > program I can run on the source files before I create the diff that
> > > formats the code according to the standard?
> > > 
> > > > 
> > > >  > 
> > > >  > Index: gdb/dbxread.c
> > > >  > ===================================================================
> > > >  > Index: gdb/dwarf2read.c
> > > >  > ===================================================================
> > > > 
> > > > These are ok
> > > 
> > > Great!
> > > 
> > > >  >  
> > > >  > Index: gdb/defs.h
> > > >  > ===================================================================
> > > >  > RCS file: /cvs/src/src/gdb/defs.h,v
> > > >  > retrieving revision 1.143
> > > >  > diff -w -u -r1.143 defs.h
> > > >  > --- gdb/defs.h	23 Feb 2004 19:26:14 -0000	1.143
> > > >  > +++ gdb/defs.h	25 Feb 2004 03:51:35 -0000
> > > >  > @@ -616,8 +616,6 @@
> > > >  >  
> > > >  >  extern void init_last_source_visited (void);
> > > >  >  
> > > >  > -extern char *symtab_to_filename (struct symtab *);
> > > >  > -
> > > >  >  /* From exec.c */
> > > >  >  
> > > >  >  extern void exec_set_section_offsets (bfd_signed_vma text_off,
> > > >  > Index: gdb/dwarf2read.c
> > > >  > ===================================================================
> > > >  > RCS file: /cvs/src/src/gdb/dwarf2read.c,v
> > > >  > retrieving revision 1.135
> > > >  > diff -w -u -r1.135 dwarf2read.c
> > > >  > --- gdb/dwarf2read.c	21 Feb 2004 02:13:35 -0000	1.135
> > > >  > +++ gdb/dwarf2read.c	25 Feb 2004 03:51:43 -0000
> > > >  > @@ -316,6 +316,7 @@
> > > >  >      unsigned int offset;
> > > >  >      unsigned int abbrev;
> > > >  >      char *name;
> > > >  > +    char *dirname;
> > > >  >      int has_pc_info;
> > > >  >      CORE_ADDR lowpc;
> > > >  >      CORE_ADDR highpc;
> > > >  > @@ -1254,6 +1255,8 @@
> > > >  >  				  objfile->global_psymbols.next,
> > > >  >  				  objfile->static_psymbols.next);
> > > >  >  
> > > >  > +      pst->dirname = xstrdup ( comp_unit_die.dirname );
> > > >  > +
> > > >  >        pst->read_symtab_private = (char *)
> > > >  >  	obstack_alloc (&objfile->objfile_obstack, sizeof (struct dwarf2_pinfo));
> > > >  >        DWARF_INFO_BUFFER (pst) = dwarf_info_buffer;
> > > >  > @@ -4326,6 +4329,10 @@
> > > >  >  	  /* Prefer DW_AT_MIPS_linkage_name over DW_AT_name.  */
> > > >  >  	  if (part_die->name == NULL)
> > > >  >  	    part_die->name = DW_STRING (&attr);
> > > >  > +	  break;
> > > >  > +	case DW_AT_comp_dir:
> > > >  > +	  if (part_die->dirname == NULL)
> > > >  > +	    part_die->dirname = DW_STRING (&attr);
> > > > 
> > > > The dwarf2 specs say that the name is in the form ":pathname" or
> > > > "hostname:pathname". Should we worry about the hostname? Does gcc emit
> > > > that?  I have looked at a few executables and didn't see the hostname
> > > > part.
> > > 
> > > It would probably just be best if you told me what case's you want me to
> > > implement here. It seems that Jason Molenda understodd most of the
> > > cases. I really don't know anything about what GCC emits and would would
> > > be practical to implement.
> > > 
> > > >  > Index: gdb/source.c
> > > >  > ===================================================================
> > > > 
> > > > this part I am not clear about.
> > > 
> > > Ok, Ok. I thought about this a lot. I think I made the best decision and
> > > can describe why.
> > > 
> > > A few assumptions are in order. In order to get the fullname (abs path) 
> > > to a file, GDB need's three things. The directory the file was compiled 
> > > in (dirname), the filename in question (filename) and a list of paths 
> > > to search.
> > > 
> > > > There is already a function called source_full_path_of() would it help
> > > > if you used it?
> > > 
> > > The function source_full_path_of does not take into account 'dirname'.
> > > It calls openp, which is not capable of finding the fullname of a file,
> > > since it doesn't understand what dirname is. Basically, I don't even
> > > think this function (source_full_path_of) is "truly" capable of 
> > > finding the fullpath to a file. However, instead of removing it, 
> > > I left it, since caller's of this function might be using for something 
> > > I know nothing about.
> > > 
> > > > What is the difference between find_and_open_source and
> > > > open_source_file?  I.e. why did you need to introduce it. I think it's
> > > > not clear just from your comments about the file possibly baing moved
> > > > around.
> > > 
> > > open_source_file was left around for backwards compatibility. The unit
> > > source.c was used to calling a function, with just passing the symtab,
> > > and getting back the symtab with a valid fullname. I could remove all
> > > occurences of this function and replace it with symtab_to_fullname.
> > > 
> > > > I am a bit worried about the substitution of symtab_to_filename with
> > > > symtab_to_fullname. The former returns null only if there is no
> > > > symtab.  The latter returns null when there is no symtab OR when it
> > > > cannot find the file. So the behavior is slightly different.
> > > 
> > > I basically think that the call -file-list-exec-source-files shouldn't 
> > > 'cache' it's results. GDB looks for each file, every time it is
> > > requested to get the fullname. This is because, the user could have 
> > > changed the path, or moved/deleted the file. I don't think GDB should
> > > just return the filename instead, of the fullname.
> > > 
> > > So, if find_and_open_source couldn't "find and open the source file", it
> > > returns NULL. Also, as a side effect, fullname in the [ps]ymtab also
> > > get's set to NULL.
> > > 
> > > The testsuite didn't seem to have a problem with this, and I think it
> > > makes sense to not trick the caller into having results when it couldn't
> > > find any.
> > > 
> > > If the caller really wanted this functionality,
> > >   return s->filename; /* File not found.  Just use short name */
> > > I believe it should be the caller's responsibility.
> > > 
> > > if ( symtab_to_fullname ( s ) == NULL )
> > >    /* use symtab->filename */ 
> > > else
> > >    /* use symtab->fullname */
> > > 
> > > It doesn't really make sense to return the filename and not state that
> > > it is not really the fullname. Also, if the caller tries to access
> > > s->fullname, it will not be successful, because the file simply isn't
> > > there.
> > > 
> > > >  > RCS file: /cvs/src/src/gdb/source.c,v
> > > >  > retrieving revision 1.49
> > > >  > diff -w -u -r1.49 source.c
> > > >  > --- gdb/source.c	27 Jan 2004 23:19:51 -0000	1.49
> > > >  > +++ gdb/source.c	25 Feb 2004 03:51:45 -0000
> > > >  > @@ -805,30 +805,47 @@
> > > >  >    return 1;
> > > >  >  }
> > > >  >  
> > > >  > -
> > > >  > -/* Open a source file given a symtab S.  Returns a file descriptor or
> > > >  > -   negative number for error.  */
> > > >  > -
> > > >  > +/* This function is capable of finding the absolute path to a
> > > >  > +   source file, and opening it, provided you give it an 
> > > >  > +   OBJFILE and FILENAME. Both the DIRNAME and FULLNAME are only
> > > >  > +   added suggestions on where to find the file. 
> > > >  > +
> > > >  > +   OBJFILE should be the objfile associated with a psymtab or symtab. 
> > > >  > +   FILENAME should be the filename to open.
> > > >  > +   DIRNAME is the compilation directory of a particular source file.
> > > >  > +           Only some debug formats provide this info.
> > > >  > +   FULLNAME can be the last known absolute path to the file in question.
> > > >  > +
> > > >  > +   On Success 
> > > >  > +     A valid file descriptor is returned. ( the return value is positive )
> > > >  > +     FULLNAME is set to the absolute path to the file just opened.
> > > >  > +
> > > >  > +   On Failure
> > > >  > +     A non valid file descriptor is returned. ( the return value is negitive ) 
> > > >  > +     FULLNAME is set to NULL.  */
> > > >  >  int
> > > >  > -open_source_file (struct symtab *s)
> > > >  > +find_and_open_source ( 
> > > >  > +  struct objfile *objfile,	
> > > >  > +  const char *filename,
> > > >  > +  const char *dirname,
> > > >  > +  char **fullname )
> > > >  >  {
> > > > 
> > > > coding standards....
> > > 
> > > Ok.
> > > 
> > > >  >    char *path = source_path;
> > > >  >    const char *p;
> > > >  >    int result;
> > > >  > -  char *fullname;
> > > >  >  
> > > >  >    /* Quick way out if we already know its full name */
> > > >  > -  if (s->fullname)
> > > >  > +  if (*fullname)
> > > >  >      {
> > > >  > -      result = open (s->fullname, OPEN_MODE);
> > > >  > +      result = open (*fullname, OPEN_MODE);
> > > >  >        if (result >= 0)
> > > >  >  	return result;
> > > >  >        /* Didn't work -- free old one, try again. */
> > > >  > -      xmfree (s->objfile->md, s->fullname);
> > > >  > -      s->fullname = NULL;
> > > >  > +      xmfree (objfile->md, *fullname);
> > > >  > +      *fullname = NULL;
> > > >  >      }
> > > >  >  
> > > >  > -  if (s->dirname != NULL)
> > > >  > +  if (dirname != NULL)
> > > >  >      {
> > > >  >        /* Replace a path entry of  $cdir  with the compilation directory name */
> > > >  >  #define	cdir_len	5
> > > >  > @@ -841,60 +858,102 @@
> > > >  >  	  int len;
> > > >  >  
> > > >  >  	  path = (char *)
> > > >  > -	    alloca (strlen (source_path) + 1 + strlen (s->dirname) + 1);
> > > >  > +	    alloca (strlen (source_path) + 1 + strlen (dirname) + 1);
> > > >  >  	  len = p - source_path;
> > > >  >  	  strncpy (path, source_path, len);	/* Before $cdir */
> > > >  > -	  strcpy (path + len, s->dirname);	/* new stuff */
> > > >  > +	  strcpy (path + len, dirname);	/* new stuff */
> > > >  >  	  strcat (path + len, source_path + len + cdir_len);	/* After $cdir */
> > > >  >  	}
> > > >  >      }
> > > >  >  
> > > >  > -  result = openp (path, 0, s->filename, OPEN_MODE, 0, &s->fullname);
> > > >  > +  result = openp (path, 0, filename, OPEN_MODE, 0, fullname);
> > > >  >    if (result < 0)
> > > >  >      {
> > > >  >        /* Didn't work.  Try using just the basename. */
> > > >  > -      p = lbasename (s->filename);
> > > >  > -      if (p != s->filename)
> > > >  > -	result = openp (path, 0, p, OPEN_MODE, 0, &s->fullname);
> > > >  > +      p = lbasename (filename);
> > > >  > +      if (p != filename)
> > > >  > +	result = openp (path, 0, p, OPEN_MODE, 0, fullname);
> > > >  >      }
> > > >  >  
> > > >  >    if (result >= 0)
> > > >  >      {
> > > >  > -      fullname = s->fullname;
> > > >  > -      s->fullname = mstrsave (s->objfile->md, s->fullname);
> > > >  > -      xfree (fullname);
> > > >  > +      char *tmp_fullname;
> > > >  > +      tmp_fullname = *fullname;
> > > >  > +      *fullname = mstrsave (objfile->md, *fullname);
> > > >  > +      xfree (tmp_fullname);
> > > >  >      }
> > > >  >    return result;
> > > >  >  }
> > > >  >  
> > > >  > -/* Return the path to the source file associated with symtab.  Returns NULL
> > > >  > -   if no symtab.  */
> > > >  > +/* Open a source file given a symtab S.  Returns a file descriptor or
> > > >  > +   negative number for error.  
> > > >  > +   
> > > >  > +   This function is a convience function to find_and_open_source. */
> > > >  > +
> > > >  > +int
> > > >  > +open_source_file (struct symtab *s)
> > > >  > +{
> > > >  > +    if (!s)
> > > >  > +      return -1;
> > > >  > +
> > > >  > +    return find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname );
> > > >  > +}
> > > >  > +
> > > >  > +/* Finds the fullname that a symtab represents.
> > > >  > +
> > > >  > +   If this functions finds the fullname, it will save it in ps->fullname
> > > >  > +   and it will also return the value.
> > > >  >  
> > > >  > +   If this function fails to find the file that this symtab represents,
> > > >  > +   NULL will be returned and ps->fullname will be set to NULL.  */
> > > >  >  char *
> > > >  > -symtab_to_filename (struct symtab *s)
> > > >  > +symtab_to_fullname (struct symtab *s)
> > > >  >  {
> > > >  > -  int fd;
> > > >  > +  int r;
> > > >  >  
> > > >  >    if (!s)
> > > >  >      return NULL;
> > > >  >  
> > > >  > -  /* If we've seen the file before, just return fullname. */
> > > >  > +  /* Don't check s->fullname here, the file could have been 
> > > >  > +     deleted/moved/..., look for it again */
> > > >  > +  r = find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname);
> > > >  >  
> > > >  > -  if (s->fullname)
> > > >  > +  if (r)
> > > >  > +  {
> > > >  > +    close (r);
> > > >  >      return s->fullname;
> > > >  > +  }
> > > >  >  
> > > >  > -  /* Try opening the file to setup fullname */
> > > >  > +  return NULL;
> > > >  > +}
> > > >  >  
> > > >  > -  fd = open_source_file (s);
> > > >  > -  if (fd < 0)
> > > >  > -    return s->filename;		/* File not found.  Just use short name */
> > > >  > +/* Finds the fullname that a partial_symtab represents.
> > > >  >  
> > > >  > -  /* Found the file.  Cleanup and return the full name */
> > > >  > +   If this functions finds the fullname, it will save it in ps->fullname
> > > >  > +   and it will also return the value.
> > > >  >  
> > > >  > -  close (fd);
> > > >  > -  return s->fullname;
> > > >  > +   If this function fails to find the file that this partial_symtab represents,
> > > >  > +   NULL will be returned and ps->fullname will be set to NULL.  */
> > > >  > +char *
> > > >  > +psymtab_to_fullname (struct partial_symtab *ps)
> > > >  > +{
> > > >  > +  int r;
> > > >  > +
> > > >  > +  if (!ps)
> > > >  > +    return NULL;
> > > >  > +
> > > >  > +  /* Don't check ps->fullname here, the file could have been
> > > >  > +     deleted/moved/..., look for it again */
> > > >  > +  r = find_and_open_source ( ps->objfile, ps->filename, ps->dirname, &ps->fullname);
> > > >  > +
> > > >  > +  if (r) 
> > > >  > +  {
> > > >  > +    close (r);
> > > >  > +    return ps->fullname;
> > > >  >  }
> > > >  >  \f
> > > >  > +  return NULL;
> > > >  > +}
> > > >  >  
> > > >  >  /* Create and initialize the table S->line_charpos that records
> > > >  >     the positions of the lines in the source file, which is assumed
> > > > 
> > > > 
> > > > 
> > > >  > Index: gdb/source.h
> > > >  > ===================================================================
> > > >  > Index: gdb/symtab.c
> > > >  > ===================================================================
> > > > 
> > > > These are obvious if the rest goes in.
> > > > 
> > > > 
> > > >  > Index: gdb/symtab.h
> > > >  > ===================================================================
> > > > 
> > > > OK.
> > > > 
> > > > 
> > > >  > Index: gdb/mi/mi-cmd-file.c
> > > >  > ===================================================================
> > > > 
> > > > 
> > > >  > +static const char * const FILENAME = "filename";
> > > >  > +static const char * const FULLNAME = "fullname";
> > > > 
> > > > I don't think these are necessary.
> > > 
> > > It just unifies the output convention I am using in the
> > > mi-cmd-file unit. What would you prefer to see?
> > > 
> > > >  >  
> > > >  >  /* Return to the client the absolute path and line number of the 
> > > >  >     current file being executed. */
> > > >  > @@ -39,7 +43,6 @@
> > > >  >    if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_file", argc, argv) )
> > > >  >      error ("mi_cmd_file_list_exec_source_file: Usage: No args");
> > > >  >  
> > > >  > -  
> > > >  >    /* Set the default file and line, also get them */
> > > >  >    set_default_source_symtab_and_line();
> > > >  >    st = get_current_source_symtab_and_line();
> > > >  > @@ -51,17 +54,67 @@
> > > >  >      error ("mi_cmd_file_list_exec_source_file: No symtab");
> > > >  >  
> > > >  >    /* Extract the fullname if it is not known yet */
> > > >  > -  if (st.symtab->fullname == NULL)
> > > >  > -    symtab_to_filename (st.symtab);
> > > >  > -
> > > >  > -  /* We may not be able to open the file (not available). */
> > > >  > -  if (st.symtab->fullname == NULL)
> > > >  > -    error ("mi_cmd_file_list_exec_source_file: File not found");
> > > > 
> > > > Why get rid of the error message?
> > > 
> > > Ok.
> > > 
> > > >  > +  symtab_to_fullname (st.symtab);
> > > >  >  
> > > >  >    /* Print to the user the line, filename and fullname */
> > > >  >    ui_out_field_int (uiout, "line", st.line);
> > > >  > -  ui_out_field_string (uiout, "file", st.symtab->filename);
> > > >  > -  ui_out_field_string (uiout, "fullname", st.symtab->fullname);
> > > >  > +  ui_out_field_string (uiout, FILENAME, st.symtab->filename);
> > > >  > +  
> > > >  > +  /* We may not be able to open the file (not available). */
> > > >  > +  if (st.symtab->fullname)
> > > >  > +    ui_out_field_string (uiout, FULLNAME, st.symtab->fullname);
> > > >  > +
> > > > 
> > > > if this test fails shouldn't some warning/error be issued?
> > > 
> > > I don't know. I am thinking that GDB should just return the absolute
> > > path to all of the source files it can find. If it can not find some,
> > > should it issue a warning? That way the front end could say, "you need
> > > to add a directory to the source search path".
> > > 
> > > >  > +  return MI_CMD_DONE;
> > > >  > +}
> > > >  > +
> > > >  > +enum mi_cmd_result
> > > >  > +mi_cmd_file_list_exec_source_files(char *command, char **argv, int argc)
> > > >  > +{
> > > >  > +  struct symtab *s;
> > > >  > +  struct partial_symtab *ps;
> > > >  > +  struct objfile *objfile;
> > > >  > +
> > > >  > +  if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_files", argc, argv) )
> > > >  > +    error ("mi_cmd_file_list_exec_source_files: Usage: No args");
> > > >  > +
> > > >  > +  /* Print the table header */
> > > >  > +  ui_out_begin ( uiout, ui_out_type_list, "files");
> > > >  > +
> > > >  > +  /* Look at all of the symtabs */
> > > >  > +  ALL_SYMTABS (objfile, s)
> > > >  > +  {
> > > >  > +    ui_out_begin ( uiout, ui_out_type_tuple, NULL);
> > > >  > +
> > > >  > +    ui_out_field_string (uiout, FILENAME, s->filename);
> > > >  > +
> > > >  > +	/* Extract the fullname if it is not known yet */
> > > >  > +	symtab_to_fullname (s);
> > > >  > +
> > > >  > +	if (s->fullname)
> > > >  > +      ui_out_field_string (uiout, FULLNAME, s->fullname);
> > > >  > +
> > > >  > +    ui_out_end ( uiout, ui_out_type_tuple );
> > > >  > +  }
> > > >  > +
> > > >  > +  /* Look at all of the psymtabs */
> > > >  > +  ALL_PSYMTABS (objfile, ps)
> > > >  > +  {
> > > >  > +    if (!ps->readin) {
> > > > 
> > > > coding standards....
> > > 
> > > Ok.
> > > 
> > > >  > +      ui_out_begin ( uiout, ui_out_type_tuple, NULL);
> > > >  > +
> > > >  > +      ui_out_field_string (uiout, FILENAME, ps->filename);
> > > >  > +
> > > >  > +      /* Extract the fullname if it is not known yet */
> > > >  > +	  psymtab_to_fullname (ps);
> > > >  > +
> > > >  > +	  if (ps->fullname) 
> > > >  > +	    ui_out_field_string (uiout, FULLNAME, ps->fullname);
> > > >  > +
> > > >  > +      ui_out_end ( uiout, ui_out_type_tuple );
> > > >  > +    }
> > > >  > +  }
> > > >  > +
> > > >  > +  ui_out_end ( uiout, ui_out_type_list );
> > > >  >  
> > > >  >    return MI_CMD_DONE;
> > > >  >  }
> > > > 
> > > > 
> > > > 
> > > >  > Index: gdb/mi/mi-cmds.c
> > > >  > ===================================================================
> > > > 
> > > >  > Index: gdb/mi/mi-cmds.h
> > > >  > ===================================================================
> > > > 
> > > > these changes are ok.
> > > 
> > > Great!
> > > 
> > > >  > Index: gdb/testsuite/gdb.mi/mi-file.exp
> > > >  > ===================================================================
> > > >  > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-file.exp,v
> > > >  > retrieving revision 1.1
> > > >  > diff -w -u -r1.1 mi-file.exp
> > > >  > --- gdb/testsuite/gdb.mi/mi-file.exp	2 Apr 2003 22:10:35 -0000	1.1
> > > >  > +++ gdb/testsuite/gdb.mi/mi-file.exp	25 Feb 2004 03:52:36 -0000
> > > >  > @@ -55,7 +55,7 @@
> > > >  >  
> > > >  >      # get the path and absolute path to the current executable
> > > >  >      mi_gdb_test "111-file-list-exec-source-file" \
> > > >  > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> > > >  > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> > > > 
> > > > Wouldn't this break existing MI parsers?
> > > 
> > > Yes. I figured it could be mi2. Also, for some reason, I thought no one
> > > would be using this function since I wrote it for CGDB, and I haven't
> > > used it yet. I have a larger plan in mind for MI, than just these 2
> > > commands (-file-list-exec-source-file and -file-list-exec-source-files).
> > > I would like to add the fullname to a lot of commands. However, I think
> > > 'filename' and 'fullname' should be standardized, so that front end
> > > writers immediatly understand what they are. It is awkard to have 1
> > > function say "file=" and another say "filename=", when those 2 words
> > > mean the same thing. 
> > > 
> > > However, if this changes isn't acceptable, I can change it back.
> > > 
> > > >  >                 "request path info of current source file (${srcfile})"
> > > >  >  }
> > > >  >  
> > > >  > Index: gdb/testsuite/gdb.mi/mi2-file.exp
> > > >  > ===================================================================
> > > >  > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi2-file.exp,v
> > > >  > retrieving revision 1.1
> > > >  > diff -w -u -r1.1 mi2-file.exp
> > > >  > --- gdb/testsuite/gdb.mi/mi2-file.exp	7 Aug 2003 17:47:42 -0000	1.1
> > > >  > +++ gdb/testsuite/gdb.mi/mi2-file.exp	25 Feb 2004 03:52:36 -0000
> > > >  > @@ -47,7 +47,7 @@
> > > >  >  mi_gdb_reinitialize_dir $srcdir/$subdir
> > > >  >  mi_gdb_load ${binfile}
> > > >  >  
> > > >  > -proc test_tbreak_creation_and_listing {} {
> > > >  > +proc test_file_list_exec_source_file {} {
> > > >  >      global srcfile
> > > >  >      global srcdir
> > > >  >      global subdir
> > > >  > @@ -55,11 +55,21 @@
> > > >  >  
> > > >  >      # get the path and absolute path to the current executable
> > > >  >      mi_gdb_test "111-file-list-exec-source-file" \
> > > >  > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> > > >  > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> > > >  >                 "request path info of current source file (${srcfile})"
> > > >  >  }
> > > >  >  
> > > >  > -test_tbreak_creation_and_listing
> > > >  > +proc test_file_list_exec_source_files {} {
> > > >  > +    global srcfile
> > > >  > +
> > > >  > +    # get the path and absolute path to the current executable
> > > >  > +    mi_gdb_test "222-file-list-exec-source-files" \
> > > >  > +	    "222\\\^done,files=\\\[\{filename=\".*/${srcfile}\",fullname=\"/.*/${srcfile}\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\}\\\]" \
> > > > 
> > > >  > +              "Getting a list of source files failed."
> > > >                                                  ^^^^^^^
> > > >                                                   why failed?
> > > 
> > > OOO, That isn't an error condition, it's just a comment. I see.
> > > 
> > > Thanks,
> > > Bob Rossi

Re: -file-list-exec-source-files

[Bob Rossi]

haha. 7 weeks.

Could someone please review this patch.

Bob Rossi

On Mon, Apr 05, 2004 at 05:40:44PM -0400, Bob Rossi wrote:
> Could someone please review this patch?
> 
> It has been 6 weeks. Pinging has not got me very far.
> 
> Bob Rossi
> 
> On Mon, Mar 29, 2004 at 03:55:46PM -0500, Bob Rossi wrote:
> > What do you think?
> > 
> > On Thu, Mar 11, 2004 at 08:25:08AM -0500, Bob Rossi wrote:
> > > What do you think?
> > > 
> > > Bob Rossi
> > > 
> > > On Sat, Mar 06, 2004 at 10:57:00AM -0500, Bob Rossi wrote:
> > > > Elena, thanks for taking the time to review my patch.
> > > > 
> > > > When is a good point to resubmit a patch? After every review, or after
> > > > all the issues are ironed out?
> > > > 
> > > > >  > Here is an initial patch for -file-list-exec-source-files.
> > > > >  > Some feedback would be appreciated.
> > > > >  > 
> > > > >  > I ran the testsuite and the results are the same before and after this
> > > > >  > patch.
> > > > >  > 
> > > > >  > Index: gdb/ChangeLog
> > > > >  > 	* dbxread.c (read_dbx_symtab): set pst->dirname when known
> > > > > 
> > > > > Each entry should start with capital letter and end with period.
> > > > > 
> > > > > I see some coding standards are not adhered to throughout the code.
> > > > > Most noticeably "foo ( int a )" should be "foo (int a)". Similarly for
> > > > > calls.
> > > > 
> > > > Ok, I will try to fix all of the coding standard errors. Is there a
> > > > program I can run on the source files before I create the diff that
> > > > formats the code according to the standard?
> > > > 
> > > > > 
> > > > >  > 
> > > > >  > Index: gdb/dbxread.c
> > > > >  > ===================================================================
> > > > >  > Index: gdb/dwarf2read.c
> > > > >  > ===================================================================
> > > > > 
> > > > > These are ok
> > > > 
> > > > Great!
> > > > 
> > > > >  >  
> > > > >  > Index: gdb/defs.h
> > > > >  > ===================================================================
> > > > >  > RCS file: /cvs/src/src/gdb/defs.h,v
> > > > >  > retrieving revision 1.143
> > > > >  > diff -w -u -r1.143 defs.h
> > > > >  > --- gdb/defs.h	23 Feb 2004 19:26:14 -0000	1.143
> > > > >  > +++ gdb/defs.h	25 Feb 2004 03:51:35 -0000
> > > > >  > @@ -616,8 +616,6 @@
> > > > >  >  
> > > > >  >  extern void init_last_source_visited (void);
> > > > >  >  
> > > > >  > -extern char *symtab_to_filename (struct symtab *);
> > > > >  > -
> > > > >  >  /* From exec.c */
> > > > >  >  
> > > > >  >  extern void exec_set_section_offsets (bfd_signed_vma text_off,
> > > > >  > Index: gdb/dwarf2read.c
> > > > >  > ===================================================================
> > > > >  > RCS file: /cvs/src/src/gdb/dwarf2read.c,v
> > > > >  > retrieving revision 1.135
> > > > >  > diff -w -u -r1.135 dwarf2read.c
> > > > >  > --- gdb/dwarf2read.c	21 Feb 2004 02:13:35 -0000	1.135
> > > > >  > +++ gdb/dwarf2read.c	25 Feb 2004 03:51:43 -0000
> > > > >  > @@ -316,6 +316,7 @@
> > > > >  >      unsigned int offset;
> > > > >  >      unsigned int abbrev;
> > > > >  >      char *name;
> > > > >  > +    char *dirname;
> > > > >  >      int has_pc_info;
> > > > >  >      CORE_ADDR lowpc;
> > > > >  >      CORE_ADDR highpc;
> > > > >  > @@ -1254,6 +1255,8 @@
> > > > >  >  				  objfile->global_psymbols.next,
> > > > >  >  				  objfile->static_psymbols.next);
> > > > >  >  
> > > > >  > +      pst->dirname = xstrdup ( comp_unit_die.dirname );
> > > > >  > +
> > > > >  >        pst->read_symtab_private = (char *)
> > > > >  >  	obstack_alloc (&objfile->objfile_obstack, sizeof (struct dwarf2_pinfo));
> > > > >  >        DWARF_INFO_BUFFER (pst) = dwarf_info_buffer;
> > > > >  > @@ -4326,6 +4329,10 @@
> > > > >  >  	  /* Prefer DW_AT_MIPS_linkage_name over DW_AT_name.  */
> > > > >  >  	  if (part_die->name == NULL)
> > > > >  >  	    part_die->name = DW_STRING (&attr);
> > > > >  > +	  break;
> > > > >  > +	case DW_AT_comp_dir:
> > > > >  > +	  if (part_die->dirname == NULL)
> > > > >  > +	    part_die->dirname = DW_STRING (&attr);
> > > > > 
> > > > > The dwarf2 specs say that the name is in the form ":pathname" or
> > > > > "hostname:pathname". Should we worry about the hostname? Does gcc emit
> > > > > that?  I have looked at a few executables and didn't see the hostname
> > > > > part.
> > > > 
> > > > It would probably just be best if you told me what case's you want me to
> > > > implement here. It seems that Jason Molenda understodd most of the
> > > > cases. I really don't know anything about what GCC emits and would would
> > > > be practical to implement.
> > > > 
> > > > >  > Index: gdb/source.c
> > > > >  > ===================================================================
> > > > > 
> > > > > this part I am not clear about.
> > > > 
> > > > Ok, Ok. I thought about this a lot. I think I made the best decision and
> > > > can describe why.
> > > > 
> > > > A few assumptions are in order. In order to get the fullname (abs path) 
> > > > to a file, GDB need's three things. The directory the file was compiled 
> > > > in (dirname), the filename in question (filename) and a list of paths 
> > > > to search.
> > > > 
> > > > > There is already a function called source_full_path_of() would it help
> > > > > if you used it?
> > > > 
> > > > The function source_full_path_of does not take into account 'dirname'.
> > > > It calls openp, which is not capable of finding the fullname of a file,
> > > > since it doesn't understand what dirname is. Basically, I don't even
> > > > think this function (source_full_path_of) is "truly" capable of 
> > > > finding the fullpath to a file. However, instead of removing it, 
> > > > I left it, since caller's of this function might be using for something 
> > > > I know nothing about.
> > > > 
> > > > > What is the difference between find_and_open_source and
> > > > > open_source_file?  I.e. why did you need to introduce it. I think it's
> > > > > not clear just from your comments about the file possibly baing moved
> > > > > around.
> > > > 
> > > > open_source_file was left around for backwards compatibility. The unit
> > > > source.c was used to calling a function, with just passing the symtab,
> > > > and getting back the symtab with a valid fullname. I could remove all
> > > > occurences of this function and replace it with symtab_to_fullname.
> > > > 
> > > > > I am a bit worried about the substitution of symtab_to_filename with
> > > > > symtab_to_fullname. The former returns null only if there is no
> > > > > symtab.  The latter returns null when there is no symtab OR when it
> > > > > cannot find the file. So the behavior is slightly different.
> > > > 
> > > > I basically think that the call -file-list-exec-source-files shouldn't 
> > > > 'cache' it's results. GDB looks for each file, every time it is
> > > > requested to get the fullname. This is because, the user could have 
> > > > changed the path, or moved/deleted the file. I don't think GDB should
> > > > just return the filename instead, of the fullname.
> > > > 
> > > > So, if find_and_open_source couldn't "find and open the source file", it
> > > > returns NULL. Also, as a side effect, fullname in the [ps]ymtab also
> > > > get's set to NULL.
> > > > 
> > > > The testsuite didn't seem to have a problem with this, and I think it
> > > > makes sense to not trick the caller into having results when it couldn't
> > > > find any.
> > > > 
> > > > If the caller really wanted this functionality,
> > > >   return s->filename; /* File not found.  Just use short name */
> > > > I believe it should be the caller's responsibility.
> > > > 
> > > > if ( symtab_to_fullname ( s ) == NULL )
> > > >    /* use symtab->filename */ 
> > > > else
> > > >    /* use symtab->fullname */
> > > > 
> > > > It doesn't really make sense to return the filename and not state that
> > > > it is not really the fullname. Also, if the caller tries to access
> > > > s->fullname, it will not be successful, because the file simply isn't
> > > > there.
> > > > 
> > > > >  > RCS file: /cvs/src/src/gdb/source.c,v
> > > > >  > retrieving revision 1.49
> > > > >  > diff -w -u -r1.49 source.c
> > > > >  > --- gdb/source.c	27 Jan 2004 23:19:51 -0000	1.49
> > > > >  > +++ gdb/source.c	25 Feb 2004 03:51:45 -0000
> > > > >  > @@ -805,30 +805,47 @@
> > > > >  >    return 1;
> > > > >  >  }
> > > > >  >  
> > > > >  > -
> > > > >  > -/* Open a source file given a symtab S.  Returns a file descriptor or
> > > > >  > -   negative number for error.  */
> > > > >  > -
> > > > >  > +/* This function is capable of finding the absolute path to a
> > > > >  > +   source file, and opening it, provided you give it an 
> > > > >  > +   OBJFILE and FILENAME. Both the DIRNAME and FULLNAME are only
> > > > >  > +   added suggestions on where to find the file. 
> > > > >  > +
> > > > >  > +   OBJFILE should be the objfile associated with a psymtab or symtab. 
> > > > >  > +   FILENAME should be the filename to open.
> > > > >  > +   DIRNAME is the compilation directory of a particular source file.
> > > > >  > +           Only some debug formats provide this info.
> > > > >  > +   FULLNAME can be the last known absolute path to the file in question.
> > > > >  > +
> > > > >  > +   On Success 
> > > > >  > +     A valid file descriptor is returned. ( the return value is positive )
> > > > >  > +     FULLNAME is set to the absolute path to the file just opened.
> > > > >  > +
> > > > >  > +   On Failure
> > > > >  > +     A non valid file descriptor is returned. ( the return value is negitive ) 
> > > > >  > +     FULLNAME is set to NULL.  */
> > > > >  >  int
> > > > >  > -open_source_file (struct symtab *s)
> > > > >  > +find_and_open_source ( 
> > > > >  > +  struct objfile *objfile,	
> > > > >  > +  const char *filename,
> > > > >  > +  const char *dirname,
> > > > >  > +  char **fullname )
> > > > >  >  {
> > > > > 
> > > > > coding standards....
> > > > 
> > > > Ok.
> > > > 
> > > > >  >    char *path = source_path;
> > > > >  >    const char *p;
> > > > >  >    int result;
> > > > >  > -  char *fullname;
> > > > >  >  
> > > > >  >    /* Quick way out if we already know its full name */
> > > > >  > -  if (s->fullname)
> > > > >  > +  if (*fullname)
> > > > >  >      {
> > > > >  > -      result = open (s->fullname, OPEN_MODE);
> > > > >  > +      result = open (*fullname, OPEN_MODE);
> > > > >  >        if (result >= 0)
> > > > >  >  	return result;
> > > > >  >        /* Didn't work -- free old one, try again. */
> > > > >  > -      xmfree (s->objfile->md, s->fullname);
> > > > >  > -      s->fullname = NULL;
> > > > >  > +      xmfree (objfile->md, *fullname);
> > > > >  > +      *fullname = NULL;
> > > > >  >      }
> > > > >  >  
> > > > >  > -  if (s->dirname != NULL)
> > > > >  > +  if (dirname != NULL)
> > > > >  >      {
> > > > >  >        /* Replace a path entry of  $cdir  with the compilation directory name */
> > > > >  >  #define	cdir_len	5
> > > > >  > @@ -841,60 +858,102 @@
> > > > >  >  	  int len;
> > > > >  >  
> > > > >  >  	  path = (char *)
> > > > >  > -	    alloca (strlen (source_path) + 1 + strlen (s->dirname) + 1);
> > > > >  > +	    alloca (strlen (source_path) + 1 + strlen (dirname) + 1);
> > > > >  >  	  len = p - source_path;
> > > > >  >  	  strncpy (path, source_path, len);	/* Before $cdir */
> > > > >  > -	  strcpy (path + len, s->dirname);	/* new stuff */
> > > > >  > +	  strcpy (path + len, dirname);	/* new stuff */
> > > > >  >  	  strcat (path + len, source_path + len + cdir_len);	/* After $cdir */
> > > > >  >  	}
> > > > >  >      }
> > > > >  >  
> > > > >  > -  result = openp (path, 0, s->filename, OPEN_MODE, 0, &s->fullname);
> > > > >  > +  result = openp (path, 0, filename, OPEN_MODE, 0, fullname);
> > > > >  >    if (result < 0)
> > > > >  >      {
> > > > >  >        /* Didn't work.  Try using just the basename. */
> > > > >  > -      p = lbasename (s->filename);
> > > > >  > -      if (p != s->filename)
> > > > >  > -	result = openp (path, 0, p, OPEN_MODE, 0, &s->fullname);
> > > > >  > +      p = lbasename (filename);
> > > > >  > +      if (p != filename)
> > > > >  > +	result = openp (path, 0, p, OPEN_MODE, 0, fullname);
> > > > >  >      }
> > > > >  >  
> > > > >  >    if (result >= 0)
> > > > >  >      {
> > > > >  > -      fullname = s->fullname;
> > > > >  > -      s->fullname = mstrsave (s->objfile->md, s->fullname);
> > > > >  > -      xfree (fullname);
> > > > >  > +      char *tmp_fullname;
> > > > >  > +      tmp_fullname = *fullname;
> > > > >  > +      *fullname = mstrsave (objfile->md, *fullname);
> > > > >  > +      xfree (tmp_fullname);
> > > > >  >      }
> > > > >  >    return result;
> > > > >  >  }
> > > > >  >  
> > > > >  > -/* Return the path to the source file associated with symtab.  Returns NULL
> > > > >  > -   if no symtab.  */
> > > > >  > +/* Open a source file given a symtab S.  Returns a file descriptor or
> > > > >  > +   negative number for error.  
> > > > >  > +   
> > > > >  > +   This function is a convience function to find_and_open_source. */
> > > > >  > +
> > > > >  > +int
> > > > >  > +open_source_file (struct symtab *s)
> > > > >  > +{
> > > > >  > +    if (!s)
> > > > >  > +      return -1;
> > > > >  > +
> > > > >  > +    return find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname );
> > > > >  > +}
> > > > >  > +
> > > > >  > +/* Finds the fullname that a symtab represents.
> > > > >  > +
> > > > >  > +   If this functions finds the fullname, it will save it in ps->fullname
> > > > >  > +   and it will also return the value.
> > > > >  >  
> > > > >  > +   If this function fails to find the file that this symtab represents,
> > > > >  > +   NULL will be returned and ps->fullname will be set to NULL.  */
> > > > >  >  char *
> > > > >  > -symtab_to_filename (struct symtab *s)
> > > > >  > +symtab_to_fullname (struct symtab *s)
> > > > >  >  {
> > > > >  > -  int fd;
> > > > >  > +  int r;
> > > > >  >  
> > > > >  >    if (!s)
> > > > >  >      return NULL;
> > > > >  >  
> > > > >  > -  /* If we've seen the file before, just return fullname. */
> > > > >  > +  /* Don't check s->fullname here, the file could have been 
> > > > >  > +     deleted/moved/..., look for it again */
> > > > >  > +  r = find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname);
> > > > >  >  
> > > > >  > -  if (s->fullname)
> > > > >  > +  if (r)
> > > > >  > +  {
> > > > >  > +    close (r);
> > > > >  >      return s->fullname;
> > > > >  > +  }
> > > > >  >  
> > > > >  > -  /* Try opening the file to setup fullname */
> > > > >  > +  return NULL;
> > > > >  > +}
> > > > >  >  
> > > > >  > -  fd = open_source_file (s);
> > > > >  > -  if (fd < 0)
> > > > >  > -    return s->filename;		/* File not found.  Just use short name */
> > > > >  > +/* Finds the fullname that a partial_symtab represents.
> > > > >  >  
> > > > >  > -  /* Found the file.  Cleanup and return the full name */
> > > > >  > +   If this functions finds the fullname, it will save it in ps->fullname
> > > > >  > +   and it will also return the value.
> > > > >  >  
> > > > >  > -  close (fd);
> > > > >  > -  return s->fullname;
> > > > >  > +   If this function fails to find the file that this partial_symtab represents,
> > > > >  > +   NULL will be returned and ps->fullname will be set to NULL.  */
> > > > >  > +char *
> > > > >  > +psymtab_to_fullname (struct partial_symtab *ps)
> > > > >  > +{
> > > > >  > +  int r;
> > > > >  > +
> > > > >  > +  if (!ps)
> > > > >  > +    return NULL;
> > > > >  > +
> > > > >  > +  /* Don't check ps->fullname here, the file could have been
> > > > >  > +     deleted/moved/..., look for it again */
> > > > >  > +  r = find_and_open_source ( ps->objfile, ps->filename, ps->dirname, &ps->fullname);
> > > > >  > +
> > > > >  > +  if (r) 
> > > > >  > +  {
> > > > >  > +    close (r);
> > > > >  > +    return ps->fullname;
> > > > >  >  }
> > > > >  >  \f
> > > > >  > +  return NULL;
> > > > >  > +}
> > > > >  >  
> > > > >  >  /* Create and initialize the table S->line_charpos that records
> > > > >  >     the positions of the lines in the source file, which is assumed
> > > > > 
> > > > > 
> > > > > 
> > > > >  > Index: gdb/source.h
> > > > >  > ===================================================================
> > > > >  > Index: gdb/symtab.c
> > > > >  > ===================================================================
> > > > > 
> > > > > These are obvious if the rest goes in.
> > > > > 
> > > > > 
> > > > >  > Index: gdb/symtab.h
> > > > >  > ===================================================================
> > > > > 
> > > > > OK.
> > > > > 
> > > > > 
> > > > >  > Index: gdb/mi/mi-cmd-file.c
> > > > >  > ===================================================================
> > > > > 
> > > > > 
> > > > >  > +static const char * const FILENAME = "filename";
> > > > >  > +static const char * const FULLNAME = "fullname";
> > > > > 
> > > > > I don't think these are necessary.
> > > > 
> > > > It just unifies the output convention I am using in the
> > > > mi-cmd-file unit. What would you prefer to see?
> > > > 
> > > > >  >  
> > > > >  >  /* Return to the client the absolute path and line number of the 
> > > > >  >     current file being executed. */
> > > > >  > @@ -39,7 +43,6 @@
> > > > >  >    if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_file", argc, argv) )
> > > > >  >      error ("mi_cmd_file_list_exec_source_file: Usage: No args");
> > > > >  >  
> > > > >  > -  
> > > > >  >    /* Set the default file and line, also get them */
> > > > >  >    set_default_source_symtab_and_line();
> > > > >  >    st = get_current_source_symtab_and_line();
> > > > >  > @@ -51,17 +54,67 @@
> > > > >  >      error ("mi_cmd_file_list_exec_source_file: No symtab");
> > > > >  >  
> > > > >  >    /* Extract the fullname if it is not known yet */
> > > > >  > -  if (st.symtab->fullname == NULL)
> > > > >  > -    symtab_to_filename (st.symtab);
> > > > >  > -
> > > > >  > -  /* We may not be able to open the file (not available). */
> > > > >  > -  if (st.symtab->fullname == NULL)
> > > > >  > -    error ("mi_cmd_file_list_exec_source_file: File not found");
> > > > > 
> > > > > Why get rid of the error message?
> > > > 
> > > > Ok.
> > > > 
> > > > >  > +  symtab_to_fullname (st.symtab);
> > > > >  >  
> > > > >  >    /* Print to the user the line, filename and fullname */
> > > > >  >    ui_out_field_int (uiout, "line", st.line);
> > > > >  > -  ui_out_field_string (uiout, "file", st.symtab->filename);
> > > > >  > -  ui_out_field_string (uiout, "fullname", st.symtab->fullname);
> > > > >  > +  ui_out_field_string (uiout, FILENAME, st.symtab->filename);
> > > > >  > +  
> > > > >  > +  /* We may not be able to open the file (not available). */
> > > > >  > +  if (st.symtab->fullname)
> > > > >  > +    ui_out_field_string (uiout, FULLNAME, st.symtab->fullname);
> > > > >  > +
> > > > > 
> > > > > if this test fails shouldn't some warning/error be issued?
> > > > 
> > > > I don't know. I am thinking that GDB should just return the absolute
> > > > path to all of the source files it can find. If it can not find some,
> > > > should it issue a warning? That way the front end could say, "you need
> > > > to add a directory to the source search path".
> > > > 
> > > > >  > +  return MI_CMD_DONE;
> > > > >  > +}
> > > > >  > +
> > > > >  > +enum mi_cmd_result
> > > > >  > +mi_cmd_file_list_exec_source_files(char *command, char **argv, int argc)
> > > > >  > +{
> > > > >  > +  struct symtab *s;
> > > > >  > +  struct partial_symtab *ps;
> > > > >  > +  struct objfile *objfile;
> > > > >  > +
> > > > >  > +  if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_files", argc, argv) )
> > > > >  > +    error ("mi_cmd_file_list_exec_source_files: Usage: No args");
> > > > >  > +
> > > > >  > +  /* Print the table header */
> > > > >  > +  ui_out_begin ( uiout, ui_out_type_list, "files");
> > > > >  > +
> > > > >  > +  /* Look at all of the symtabs */
> > > > >  > +  ALL_SYMTABS (objfile, s)
> > > > >  > +  {
> > > > >  > +    ui_out_begin ( uiout, ui_out_type_tuple, NULL);
> > > > >  > +
> > > > >  > +    ui_out_field_string (uiout, FILENAME, s->filename);
> > > > >  > +
> > > > >  > +	/* Extract the fullname if it is not known yet */
> > > > >  > +	symtab_to_fullname (s);
> > > > >  > +
> > > > >  > +	if (s->fullname)
> > > > >  > +      ui_out_field_string (uiout, FULLNAME, s->fullname);
> > > > >  > +
> > > > >  > +    ui_out_end ( uiout, ui_out_type_tuple );
> > > > >  > +  }
> > > > >  > +
> > > > >  > +  /* Look at all of the psymtabs */
> > > > >  > +  ALL_PSYMTABS (objfile, ps)
> > > > >  > +  {
> > > > >  > +    if (!ps->readin) {
> > > > > 
> > > > > coding standards....
> > > > 
> > > > Ok.
> > > > 
> > > > >  > +      ui_out_begin ( uiout, ui_out_type_tuple, NULL);
> > > > >  > +
> > > > >  > +      ui_out_field_string (uiout, FILENAME, ps->filename);
> > > > >  > +
> > > > >  > +      /* Extract the fullname if it is not known yet */
> > > > >  > +	  psymtab_to_fullname (ps);
> > > > >  > +
> > > > >  > +	  if (ps->fullname) 
> > > > >  > +	    ui_out_field_string (uiout, FULLNAME, ps->fullname);
> > > > >  > +
> > > > >  > +      ui_out_end ( uiout, ui_out_type_tuple );
> > > > >  > +    }
> > > > >  > +  }
> > > > >  > +
> > > > >  > +  ui_out_end ( uiout, ui_out_type_list );
> > > > >  >  
> > > > >  >    return MI_CMD_DONE;
> > > > >  >  }
> > > > > 
> > > > > 
> > > > > 
> > > > >  > Index: gdb/mi/mi-cmds.c
> > > > >  > ===================================================================
> > > > > 
> > > > >  > Index: gdb/mi/mi-cmds.h
> > > > >  > ===================================================================
> > > > > 
> > > > > these changes are ok.
> > > > 
> > > > Great!
> > > > 
> > > > >  > Index: gdb/testsuite/gdb.mi/mi-file.exp
> > > > >  > ===================================================================
> > > > >  > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-file.exp,v
> > > > >  > retrieving revision 1.1
> > > > >  > diff -w -u -r1.1 mi-file.exp
> > > > >  > --- gdb/testsuite/gdb.mi/mi-file.exp	2 Apr 2003 22:10:35 -0000	1.1
> > > > >  > +++ gdb/testsuite/gdb.mi/mi-file.exp	25 Feb 2004 03:52:36 -0000
> > > > >  > @@ -55,7 +55,7 @@
> > > > >  >  
> > > > >  >      # get the path and absolute path to the current executable
> > > > >  >      mi_gdb_test "111-file-list-exec-source-file" \
> > > > >  > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> > > > >  > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> > > > > 
> > > > > Wouldn't this break existing MI parsers?
> > > > 
> > > > Yes. I figured it could be mi2. Also, for some reason, I thought no one
> > > > would be using this function since I wrote it for CGDB, and I haven't
> > > > used it yet. I have a larger plan in mind for MI, than just these 2
> > > > commands (-file-list-exec-source-file and -file-list-exec-source-files).
> > > > I would like to add the fullname to a lot of commands. However, I think
> > > > 'filename' and 'fullname' should be standardized, so that front end
> > > > writers immediatly understand what they are. It is awkard to have 1
> > > > function say "file=" and another say "filename=", when those 2 words
> > > > mean the same thing. 
> > > > 
> > > > However, if this changes isn't acceptable, I can change it back.
> > > > 
> > > > >  >                 "request path info of current source file (${srcfile})"
> > > > >  >  }
> > > > >  >  
> > > > >  > Index: gdb/testsuite/gdb.mi/mi2-file.exp
> > > > >  > ===================================================================
> > > > >  > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi2-file.exp,v
> > > > >  > retrieving revision 1.1
> > > > >  > diff -w -u -r1.1 mi2-file.exp
> > > > >  > --- gdb/testsuite/gdb.mi/mi2-file.exp	7 Aug 2003 17:47:42 -0000	1.1
> > > > >  > +++ gdb/testsuite/gdb.mi/mi2-file.exp	25 Feb 2004 03:52:36 -0000
> > > > >  > @@ -47,7 +47,7 @@
> > > > >  >  mi_gdb_reinitialize_dir $srcdir/$subdir
> > > > >  >  mi_gdb_load ${binfile}
> > > > >  >  
> > > > >  > -proc test_tbreak_creation_and_listing {} {
> > > > >  > +proc test_file_list_exec_source_file {} {
> > > > >  >      global srcfile
> > > > >  >      global srcdir
> > > > >  >      global subdir
> > > > >  > @@ -55,11 +55,21 @@
> > > > >  >  
> > > > >  >      # get the path and absolute path to the current executable
> > > > >  >      mi_gdb_test "111-file-list-exec-source-file" \
> > > > >  > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> > > > >  > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> > > > >  >                 "request path info of current source file (${srcfile})"
> > > > >  >  }
> > > > >  >  
> > > > >  > -test_tbreak_creation_and_listing
> > > > >  > +proc test_file_list_exec_source_files {} {
> > > > >  > +    global srcfile
> > > > >  > +
> > > > >  > +    # get the path and absolute path to the current executable
> > > > >  > +    mi_gdb_test "222-file-list-exec-source-files" \
> > > > >  > +	    "222\\\^done,files=\\\[\{filename=\".*/${srcfile}\",fullname=\"/.*/${srcfile}\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\}\\\]" \
> > > > > 
> > > > >  > +              "Getting a list of source files failed."
> > > > >                                                  ^^^^^^^
> > > > >                                                   why failed?
> > > > 
> > > > OOO, That isn't an error condition, it's just a comment. I see.
> > > > 
> > > > Thanks,
> > > > Bob Rossi

Re: -file-list-exec-source-files

[Bob Rossi]

Honestly, will someone please review this patch.

Seriously, why is no one looking at this patch? 
It's been over 2 months now! 

Bob Rossi


On Mon, Apr 12, 2004 at 11:06:20AM -0400, Bob Rossi wrote:
> haha. 7 weeks.
> 
> Could someone please review this patch.
> 
> Bob Rossi
> 
> On Mon, Apr 05, 2004 at 05:40:44PM -0400, Bob Rossi wrote:
> > Could someone please review this patch?
> > 
> > It has been 6 weeks. Pinging has not got me very far.
> > 
> > Bob Rossi
> > 
> > On Mon, Mar 29, 2004 at 03:55:46PM -0500, Bob Rossi wrote:
> > > What do you think?
> > > 
> > > On Thu, Mar 11, 2004 at 08:25:08AM -0500, Bob Rossi wrote:
> > > > What do you think?
> > > > 
> > > > Bob Rossi
> > > > 
> > > > On Sat, Mar 06, 2004 at 10:57:00AM -0500, Bob Rossi wrote:
> > > > > Elena, thanks for taking the time to review my patch.
> > > > > 
> > > > > When is a good point to resubmit a patch? After every review, or after
> > > > > all the issues are ironed out?
> > > > > 
> > > > > >  > Here is an initial patch for -file-list-exec-source-files.
> > > > > >  > Some feedback would be appreciated.
> > > > > >  > 
> > > > > >  > I ran the testsuite and the results are the same before and after this
> > > > > >  > patch.
> > > > > >  > 
> > > > > >  > Index: gdb/ChangeLog
> > > > > >  > 	* dbxread.c (read_dbx_symtab): set pst->dirname when known
> > > > > > 
> > > > > > Each entry should start with capital letter and end with period.
> > > > > > 
> > > > > > I see some coding standards are not adhered to throughout the code.
> > > > > > Most noticeably "foo ( int a )" should be "foo (int a)". Similarly for
> > > > > > calls.
> > > > > 
> > > > > Ok, I will try to fix all of the coding standard errors. Is there a
> > > > > program I can run on the source files before I create the diff that
> > > > > formats the code according to the standard?
> > > > > 
> > > > > > 
> > > > > >  > 
> > > > > >  > Index: gdb/dbxread.c
> > > > > >  > ===================================================================
> > > > > >  > Index: gdb/dwarf2read.c
> > > > > >  > ===================================================================
> > > > > > 
> > > > > > These are ok
> > > > > 
> > > > > Great!
> > > > > 
> > > > > >  >  
> > > > > >  > Index: gdb/defs.h
> > > > > >  > ===================================================================
> > > > > >  > RCS file: /cvs/src/src/gdb/defs.h,v
> > > > > >  > retrieving revision 1.143
> > > > > >  > diff -w -u -r1.143 defs.h
> > > > > >  > --- gdb/defs.h	23 Feb 2004 19:26:14 -0000	1.143
> > > > > >  > +++ gdb/defs.h	25 Feb 2004 03:51:35 -0000
> > > > > >  > @@ -616,8 +616,6 @@
> > > > > >  >  
> > > > > >  >  extern void init_last_source_visited (void);
> > > > > >  >  
> > > > > >  > -extern char *symtab_to_filename (struct symtab *);
> > > > > >  > -
> > > > > >  >  /* From exec.c */
> > > > > >  >  
> > > > > >  >  extern void exec_set_section_offsets (bfd_signed_vma text_off,
> > > > > >  > Index: gdb/dwarf2read.c
> > > > > >  > ===================================================================
> > > > > >  > RCS file: /cvs/src/src/gdb/dwarf2read.c,v
> > > > > >  > retrieving revision 1.135
> > > > > >  > diff -w -u -r1.135 dwarf2read.c
> > > > > >  > --- gdb/dwarf2read.c	21 Feb 2004 02:13:35 -0000	1.135
> > > > > >  > +++ gdb/dwarf2read.c	25 Feb 2004 03:51:43 -0000
> > > > > >  > @@ -316,6 +316,7 @@
> > > > > >  >      unsigned int offset;
> > > > > >  >      unsigned int abbrev;
> > > > > >  >      char *name;
> > > > > >  > +    char *dirname;
> > > > > >  >      int has_pc_info;
> > > > > >  >      CORE_ADDR lowpc;
> > > > > >  >      CORE_ADDR highpc;
> > > > > >  > @@ -1254,6 +1255,8 @@
> > > > > >  >  				  objfile->global_psymbols.next,
> > > > > >  >  				  objfile->static_psymbols.next);
> > > > > >  >  
> > > > > >  > +      pst->dirname = xstrdup ( comp_unit_die.dirname );
> > > > > >  > +
> > > > > >  >        pst->read_symtab_private = (char *)
> > > > > >  >  	obstack_alloc (&objfile->objfile_obstack, sizeof (struct dwarf2_pinfo));
> > > > > >  >        DWARF_INFO_BUFFER (pst) = dwarf_info_buffer;
> > > > > >  > @@ -4326,6 +4329,10 @@
> > > > > >  >  	  /* Prefer DW_AT_MIPS_linkage_name over DW_AT_name.  */
> > > > > >  >  	  if (part_die->name == NULL)
> > > > > >  >  	    part_die->name = DW_STRING (&attr);
> > > > > >  > +	  break;
> > > > > >  > +	case DW_AT_comp_dir:
> > > > > >  > +	  if (part_die->dirname == NULL)
> > > > > >  > +	    part_die->dirname = DW_STRING (&attr);
> > > > > > 
> > > > > > The dwarf2 specs say that the name is in the form ":pathname" or
> > > > > > "hostname:pathname". Should we worry about the hostname? Does gcc emit
> > > > > > that?  I have looked at a few executables and didn't see the hostname
> > > > > > part.
> > > > > 
> > > > > It would probably just be best if you told me what case's you want me to
> > > > > implement here. It seems that Jason Molenda understodd most of the
> > > > > cases. I really don't know anything about what GCC emits and would would
> > > > > be practical to implement.
> > > > > 
> > > > > >  > Index: gdb/source.c
> > > > > >  > ===================================================================
> > > > > > 
> > > > > > this part I am not clear about.
> > > > > 
> > > > > Ok, Ok. I thought about this a lot. I think I made the best decision and
> > > > > can describe why.
> > > > > 
> > > > > A few assumptions are in order. In order to get the fullname (abs path) 
> > > > > to a file, GDB need's three things. The directory the file was compiled 
> > > > > in (dirname), the filename in question (filename) and a list of paths 
> > > > > to search.
> > > > > 
> > > > > > There is already a function called source_full_path_of() would it help
> > > > > > if you used it?
> > > > > 
> > > > > The function source_full_path_of does not take into account 'dirname'.
> > > > > It calls openp, which is not capable of finding the fullname of a file,
> > > > > since it doesn't understand what dirname is. Basically, I don't even
> > > > > think this function (source_full_path_of) is "truly" capable of 
> > > > > finding the fullpath to a file. However, instead of removing it, 
> > > > > I left it, since caller's of this function might be using for something 
> > > > > I know nothing about.
> > > > > 
> > > > > > What is the difference between find_and_open_source and
> > > > > > open_source_file?  I.e. why did you need to introduce it. I think it's
> > > > > > not clear just from your comments about the file possibly baing moved
> > > > > > around.
> > > > > 
> > > > > open_source_file was left around for backwards compatibility. The unit
> > > > > source.c was used to calling a function, with just passing the symtab,
> > > > > and getting back the symtab with a valid fullname. I could remove all
> > > > > occurences of this function and replace it with symtab_to_fullname.
> > > > > 
> > > > > > I am a bit worried about the substitution of symtab_to_filename with
> > > > > > symtab_to_fullname. The former returns null only if there is no
> > > > > > symtab.  The latter returns null when there is no symtab OR when it
> > > > > > cannot find the file. So the behavior is slightly different.
> > > > > 
> > > > > I basically think that the call -file-list-exec-source-files shouldn't 
> > > > > 'cache' it's results. GDB looks for each file, every time it is
> > > > > requested to get the fullname. This is because, the user could have 
> > > > > changed the path, or moved/deleted the file. I don't think GDB should
> > > > > just return the filename instead, of the fullname.
> > > > > 
> > > > > So, if find_and_open_source couldn't "find and open the source file", it
> > > > > returns NULL. Also, as a side effect, fullname in the [ps]ymtab also
> > > > > get's set to NULL.
> > > > > 
> > > > > The testsuite didn't seem to have a problem with this, and I think it
> > > > > makes sense to not trick the caller into having results when it couldn't
> > > > > find any.
> > > > > 
> > > > > If the caller really wanted this functionality,
> > > > >   return s->filename; /* File not found.  Just use short name */
> > > > > I believe it should be the caller's responsibility.
> > > > > 
> > > > > if ( symtab_to_fullname ( s ) == NULL )
> > > > >    /* use symtab->filename */ 
> > > > > else
> > > > >    /* use symtab->fullname */
> > > > > 
> > > > > It doesn't really make sense to return the filename and not state that
> > > > > it is not really the fullname. Also, if the caller tries to access
> > > > > s->fullname, it will not be successful, because the file simply isn't
> > > > > there.
> > > > > 
> > > > > >  > RCS file: /cvs/src/src/gdb/source.c,v
> > > > > >  > retrieving revision 1.49
> > > > > >  > diff -w -u -r1.49 source.c
> > > > > >  > --- gdb/source.c	27 Jan 2004 23:19:51 -0000	1.49
> > > > > >  > +++ gdb/source.c	25 Feb 2004 03:51:45 -0000
> > > > > >  > @@ -805,30 +805,47 @@
> > > > > >  >    return 1;
> > > > > >  >  }
> > > > > >  >  
> > > > > >  > -
> > > > > >  > -/* Open a source file given a symtab S.  Returns a file descriptor or
> > > > > >  > -   negative number for error.  */
> > > > > >  > -
> > > > > >  > +/* This function is capable of finding the absolute path to a
> > > > > >  > +   source file, and opening it, provided you give it an 
> > > > > >  > +   OBJFILE and FILENAME. Both the DIRNAME and FULLNAME are only
> > > > > >  > +   added suggestions on where to find the file. 
> > > > > >  > +
> > > > > >  > +   OBJFILE should be the objfile associated with a psymtab or symtab. 
> > > > > >  > +   FILENAME should be the filename to open.
> > > > > >  > +   DIRNAME is the compilation directory of a particular source file.
> > > > > >  > +           Only some debug formats provide this info.
> > > > > >  > +   FULLNAME can be the last known absolute path to the file in question.
> > > > > >  > +
> > > > > >  > +   On Success 
> > > > > >  > +     A valid file descriptor is returned. ( the return value is positive )
> > > > > >  > +     FULLNAME is set to the absolute path to the file just opened.
> > > > > >  > +
> > > > > >  > +   On Failure
> > > > > >  > +     A non valid file descriptor is returned. ( the return value is negitive ) 
> > > > > >  > +     FULLNAME is set to NULL.  */
> > > > > >  >  int
> > > > > >  > -open_source_file (struct symtab *s)
> > > > > >  > +find_and_open_source ( 
> > > > > >  > +  struct objfile *objfile,	
> > > > > >  > +  const char *filename,
> > > > > >  > +  const char *dirname,
> > > > > >  > +  char **fullname )
> > > > > >  >  {
> > > > > > 
> > > > > > coding standards....
> > > > > 
> > > > > Ok.
> > > > > 
> > > > > >  >    char *path = source_path;
> > > > > >  >    const char *p;
> > > > > >  >    int result;
> > > > > >  > -  char *fullname;
> > > > > >  >  
> > > > > >  >    /* Quick way out if we already know its full name */
> > > > > >  > -  if (s->fullname)
> > > > > >  > +  if (*fullname)
> > > > > >  >      {
> > > > > >  > -      result = open (s->fullname, OPEN_MODE);
> > > > > >  > +      result = open (*fullname, OPEN_MODE);
> > > > > >  >        if (result >= 0)
> > > > > >  >  	return result;
> > > > > >  >        /* Didn't work -- free old one, try again. */
> > > > > >  > -      xmfree (s->objfile->md, s->fullname);
> > > > > >  > -      s->fullname = NULL;
> > > > > >  > +      xmfree (objfile->md, *fullname);
> > > > > >  > +      *fullname = NULL;
> > > > > >  >      }
> > > > > >  >  
> > > > > >  > -  if (s->dirname != NULL)
> > > > > >  > +  if (dirname != NULL)
> > > > > >  >      {
> > > > > >  >        /* Replace a path entry of  $cdir  with the compilation directory name */
> > > > > >  >  #define	cdir_len	5
> > > > > >  > @@ -841,60 +858,102 @@
> > > > > >  >  	  int len;
> > > > > >  >  
> > > > > >  >  	  path = (char *)
> > > > > >  > -	    alloca (strlen (source_path) + 1 + strlen (s->dirname) + 1);
> > > > > >  > +	    alloca (strlen (source_path) + 1 + strlen (dirname) + 1);
> > > > > >  >  	  len = p - source_path;
> > > > > >  >  	  strncpy (path, source_path, len);	/* Before $cdir */
> > > > > >  > -	  strcpy (path + len, s->dirname);	/* new stuff */
> > > > > >  > +	  strcpy (path + len, dirname);	/* new stuff */
> > > > > >  >  	  strcat (path + len, source_path + len + cdir_len);	/* After $cdir */
> > > > > >  >  	}
> > > > > >  >      }
> > > > > >  >  
> > > > > >  > -  result = openp (path, 0, s->filename, OPEN_MODE, 0, &s->fullname);
> > > > > >  > +  result = openp (path, 0, filename, OPEN_MODE, 0, fullname);
> > > > > >  >    if (result < 0)
> > > > > >  >      {
> > > > > >  >        /* Didn't work.  Try using just the basename. */
> > > > > >  > -      p = lbasename (s->filename);
> > > > > >  > -      if (p != s->filename)
> > > > > >  > -	result = openp (path, 0, p, OPEN_MODE, 0, &s->fullname);
> > > > > >  > +      p = lbasename (filename);
> > > > > >  > +      if (p != filename)
> > > > > >  > +	result = openp (path, 0, p, OPEN_MODE, 0, fullname);
> > > > > >  >      }
> > > > > >  >  
> > > > > >  >    if (result >= 0)
> > > > > >  >      {
> > > > > >  > -      fullname = s->fullname;
> > > > > >  > -      s->fullname = mstrsave (s->objfile->md, s->fullname);
> > > > > >  > -      xfree (fullname);
> > > > > >  > +      char *tmp_fullname;
> > > > > >  > +      tmp_fullname = *fullname;
> > > > > >  > +      *fullname = mstrsave (objfile->md, *fullname);
> > > > > >  > +      xfree (tmp_fullname);
> > > > > >  >      }
> > > > > >  >    return result;
> > > > > >  >  }
> > > > > >  >  
> > > > > >  > -/* Return the path to the source file associated with symtab.  Returns NULL
> > > > > >  > -   if no symtab.  */
> > > > > >  > +/* Open a source file given a symtab S.  Returns a file descriptor or
> > > > > >  > +   negative number for error.  
> > > > > >  > +   
> > > > > >  > +   This function is a convience function to find_and_open_source. */
> > > > > >  > +
> > > > > >  > +int
> > > > > >  > +open_source_file (struct symtab *s)
> > > > > >  > +{
> > > > > >  > +    if (!s)
> > > > > >  > +      return -1;
> > > > > >  > +
> > > > > >  > +    return find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname );
> > > > > >  > +}
> > > > > >  > +
> > > > > >  > +/* Finds the fullname that a symtab represents.
> > > > > >  > +
> > > > > >  > +   If this functions finds the fullname, it will save it in ps->fullname
> > > > > >  > +   and it will also return the value.
> > > > > >  >  
> > > > > >  > +   If this function fails to find the file that this symtab represents,
> > > > > >  > +   NULL will be returned and ps->fullname will be set to NULL.  */
> > > > > >  >  char *
> > > > > >  > -symtab_to_filename (struct symtab *s)
> > > > > >  > +symtab_to_fullname (struct symtab *s)
> > > > > >  >  {
> > > > > >  > -  int fd;
> > > > > >  > +  int r;
> > > > > >  >  
> > > > > >  >    if (!s)
> > > > > >  >      return NULL;
> > > > > >  >  
> > > > > >  > -  /* If we've seen the file before, just return fullname. */
> > > > > >  > +  /* Don't check s->fullname here, the file could have been 
> > > > > >  > +     deleted/moved/..., look for it again */
> > > > > >  > +  r = find_and_open_source ( s->objfile, s->filename, s->dirname, &s->fullname);
> > > > > >  >  
> > > > > >  > -  if (s->fullname)
> > > > > >  > +  if (r)
> > > > > >  > +  {
> > > > > >  > +    close (r);
> > > > > >  >      return s->fullname;
> > > > > >  > +  }
> > > > > >  >  
> > > > > >  > -  /* Try opening the file to setup fullname */
> > > > > >  > +  return NULL;
> > > > > >  > +}
> > > > > >  >  
> > > > > >  > -  fd = open_source_file (s);
> > > > > >  > -  if (fd < 0)
> > > > > >  > -    return s->filename;		/* File not found.  Just use short name */
> > > > > >  > +/* Finds the fullname that a partial_symtab represents.
> > > > > >  >  
> > > > > >  > -  /* Found the file.  Cleanup and return the full name */
> > > > > >  > +   If this functions finds the fullname, it will save it in ps->fullname
> > > > > >  > +   and it will also return the value.
> > > > > >  >  
> > > > > >  > -  close (fd);
> > > > > >  > -  return s->fullname;
> > > > > >  > +   If this function fails to find the file that this partial_symtab represents,
> > > > > >  > +   NULL will be returned and ps->fullname will be set to NULL.  */
> > > > > >  > +char *
> > > > > >  > +psymtab_to_fullname (struct partial_symtab *ps)
> > > > > >  > +{
> > > > > >  > +  int r;
> > > > > >  > +
> > > > > >  > +  if (!ps)
> > > > > >  > +    return NULL;
> > > > > >  > +
> > > > > >  > +  /* Don't check ps->fullname here, the file could have been
> > > > > >  > +     deleted/moved/..., look for it again */
> > > > > >  > +  r = find_and_open_source ( ps->objfile, ps->filename, ps->dirname, &ps->fullname);
> > > > > >  > +
> > > > > >  > +  if (r) 
> > > > > >  > +  {
> > > > > >  > +    close (r);
> > > > > >  > +    return ps->fullname;
> > > > > >  >  }
> > > > > >  >  \f
> > > > > >  > +  return NULL;
> > > > > >  > +}
> > > > > >  >  
> > > > > >  >  /* Create and initialize the table S->line_charpos that records
> > > > > >  >     the positions of the lines in the source file, which is assumed
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >  > Index: gdb/source.h
> > > > > >  > ===================================================================
> > > > > >  > Index: gdb/symtab.c
> > > > > >  > ===================================================================
> > > > > > 
> > > > > > These are obvious if the rest goes in.
> > > > > > 
> > > > > > 
> > > > > >  > Index: gdb/symtab.h
> > > > > >  > ===================================================================
> > > > > > 
> > > > > > OK.
> > > > > > 
> > > > > > 
> > > > > >  > Index: gdb/mi/mi-cmd-file.c
> > > > > >  > ===================================================================
> > > > > > 
> > > > > > 
> > > > > >  > +static const char * const FILENAME = "filename";
> > > > > >  > +static const char * const FULLNAME = "fullname";
> > > > > > 
> > > > > > I don't think these are necessary.
> > > > > 
> > > > > It just unifies the output convention I am using in the
> > > > > mi-cmd-file unit. What would you prefer to see?
> > > > > 
> > > > > >  >  
> > > > > >  >  /* Return to the client the absolute path and line number of the 
> > > > > >  >     current file being executed. */
> > > > > >  > @@ -39,7 +43,6 @@
> > > > > >  >    if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_file", argc, argv) )
> > > > > >  >      error ("mi_cmd_file_list_exec_source_file: Usage: No args");
> > > > > >  >  
> > > > > >  > -  
> > > > > >  >    /* Set the default file and line, also get them */
> > > > > >  >    set_default_source_symtab_and_line();
> > > > > >  >    st = get_current_source_symtab_and_line();
> > > > > >  > @@ -51,17 +54,67 @@
> > > > > >  >      error ("mi_cmd_file_list_exec_source_file: No symtab");
> > > > > >  >  
> > > > > >  >    /* Extract the fullname if it is not known yet */
> > > > > >  > -  if (st.symtab->fullname == NULL)
> > > > > >  > -    symtab_to_filename (st.symtab);
> > > > > >  > -
> > > > > >  > -  /* We may not be able to open the file (not available). */
> > > > > >  > -  if (st.symtab->fullname == NULL)
> > > > > >  > -    error ("mi_cmd_file_list_exec_source_file: File not found");
> > > > > > 
> > > > > > Why get rid of the error message?
> > > > > 
> > > > > Ok.
> > > > > 
> > > > > >  > +  symtab_to_fullname (st.symtab);
> > > > > >  >  
> > > > > >  >    /* Print to the user the line, filename and fullname */
> > > > > >  >    ui_out_field_int (uiout, "line", st.line);
> > > > > >  > -  ui_out_field_string (uiout, "file", st.symtab->filename);
> > > > > >  > -  ui_out_field_string (uiout, "fullname", st.symtab->fullname);
> > > > > >  > +  ui_out_field_string (uiout, FILENAME, st.symtab->filename);
> > > > > >  > +  
> > > > > >  > +  /* We may not be able to open the file (not available). */
> > > > > >  > +  if (st.symtab->fullname)
> > > > > >  > +    ui_out_field_string (uiout, FULLNAME, st.symtab->fullname);
> > > > > >  > +
> > > > > > 
> > > > > > if this test fails shouldn't some warning/error be issued?
> > > > > 
> > > > > I don't know. I am thinking that GDB should just return the absolute
> > > > > path to all of the source files it can find. If it can not find some,
> > > > > should it issue a warning? That way the front end could say, "you need
> > > > > to add a directory to the source search path".
> > > > > 
> > > > > >  > +  return MI_CMD_DONE;
> > > > > >  > +}
> > > > > >  > +
> > > > > >  > +enum mi_cmd_result
> > > > > >  > +mi_cmd_file_list_exec_source_files(char *command, char **argv, int argc)
> > > > > >  > +{
> > > > > >  > +  struct symtab *s;
> > > > > >  > +  struct partial_symtab *ps;
> > > > > >  > +  struct objfile *objfile;
> > > > > >  > +
> > > > > >  > +  if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_files", argc, argv) )
> > > > > >  > +    error ("mi_cmd_file_list_exec_source_files: Usage: No args");
> > > > > >  > +
> > > > > >  > +  /* Print the table header */
> > > > > >  > +  ui_out_begin ( uiout, ui_out_type_list, "files");
> > > > > >  > +
> > > > > >  > +  /* Look at all of the symtabs */
> > > > > >  > +  ALL_SYMTABS (objfile, s)
> > > > > >  > +  {
> > > > > >  > +    ui_out_begin ( uiout, ui_out_type_tuple, NULL);
> > > > > >  > +
> > > > > >  > +    ui_out_field_string (uiout, FILENAME, s->filename);
> > > > > >  > +
> > > > > >  > +	/* Extract the fullname if it is not known yet */
> > > > > >  > +	symtab_to_fullname (s);
> > > > > >  > +
> > > > > >  > +	if (s->fullname)
> > > > > >  > +      ui_out_field_string (uiout, FULLNAME, s->fullname);
> > > > > >  > +
> > > > > >  > +    ui_out_end ( uiout, ui_out_type_tuple );
> > > > > >  > +  }
> > > > > >  > +
> > > > > >  > +  /* Look at all of the psymtabs */
> > > > > >  > +  ALL_PSYMTABS (objfile, ps)
> > > > > >  > +  {
> > > > > >  > +    if (!ps->readin) {
> > > > > > 
> > > > > > coding standards....
> > > > > 
> > > > > Ok.
> > > > > 
> > > > > >  > +      ui_out_begin ( uiout, ui_out_type_tuple, NULL);
> > > > > >  > +
> > > > > >  > +      ui_out_field_string (uiout, FILENAME, ps->filename);
> > > > > >  > +
> > > > > >  > +      /* Extract the fullname if it is not known yet */
> > > > > >  > +	  psymtab_to_fullname (ps);
> > > > > >  > +
> > > > > >  > +	  if (ps->fullname) 
> > > > > >  > +	    ui_out_field_string (uiout, FULLNAME, ps->fullname);
> > > > > >  > +
> > > > > >  > +      ui_out_end ( uiout, ui_out_type_tuple );
> > > > > >  > +    }
> > > > > >  > +  }
> > > > > >  > +
> > > > > >  > +  ui_out_end ( uiout, ui_out_type_list );
> > > > > >  >  
> > > > > >  >    return MI_CMD_DONE;
> > > > > >  >  }
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >  > Index: gdb/mi/mi-cmds.c
> > > > > >  > ===================================================================
> > > > > > 
> > > > > >  > Index: gdb/mi/mi-cmds.h
> > > > > >  > ===================================================================
> > > > > > 
> > > > > > these changes are ok.
> > > > > 
> > > > > Great!
> > > > > 
> > > > > >  > Index: gdb/testsuite/gdb.mi/mi-file.exp
> > > > > >  > ===================================================================
> > > > > >  > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-file.exp,v
> > > > > >  > retrieving revision 1.1
> > > > > >  > diff -w -u -r1.1 mi-file.exp
> > > > > >  > --- gdb/testsuite/gdb.mi/mi-file.exp	2 Apr 2003 22:10:35 -0000	1.1
> > > > > >  > +++ gdb/testsuite/gdb.mi/mi-file.exp	25 Feb 2004 03:52:36 -0000
> > > > > >  > @@ -55,7 +55,7 @@
> > > > > >  >  
> > > > > >  >      # get the path and absolute path to the current executable
> > > > > >  >      mi_gdb_test "111-file-list-exec-source-file" \
> > > > > >  > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> > > > > >  > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> > > > > > 
> > > > > > Wouldn't this break existing MI parsers?
> > > > > 
> > > > > Yes. I figured it could be mi2. Also, for some reason, I thought no one
> > > > > would be using this function since I wrote it for CGDB, and I haven't
> > > > > used it yet. I have a larger plan in mind for MI, than just these 2
> > > > > commands (-file-list-exec-source-file and -file-list-exec-source-files).
> > > > > I would like to add the fullname to a lot of commands. However, I think
> > > > > 'filename' and 'fullname' should be standardized, so that front end
> > > > > writers immediatly understand what they are. It is awkard to have 1
> > > > > function say "file=" and another say "filename=", when those 2 words
> > > > > mean the same thing. 
> > > > > 
> > > > > However, if this changes isn't acceptable, I can change it back.
> > > > > 
> > > > > >  >                 "request path info of current source file (${srcfile})"
> > > > > >  >  }
> > > > > >  >  
> > > > > >  > Index: gdb/testsuite/gdb.mi/mi2-file.exp
> > > > > >  > ===================================================================
> > > > > >  > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi2-file.exp,v
> > > > > >  > retrieving revision 1.1
> > > > > >  > diff -w -u -r1.1 mi2-file.exp
> > > > > >  > --- gdb/testsuite/gdb.mi/mi2-file.exp	7 Aug 2003 17:47:42 -0000	1.1
> > > > > >  > +++ gdb/testsuite/gdb.mi/mi2-file.exp	25 Feb 2004 03:52:36 -0000
> > > > > >  > @@ -47,7 +47,7 @@
> > > > > >  >  mi_gdb_reinitialize_dir $srcdir/$subdir
> > > > > >  >  mi_gdb_load ${binfile}
> > > > > >  >  
> > > > > >  > -proc test_tbreak_creation_and_listing {} {
> > > > > >  > +proc test_file_list_exec_source_file {} {
> > > > > >  >      global srcfile
> > > > > >  >      global srcdir
> > > > > >  >      global subdir
> > > > > >  > @@ -55,11 +55,21 @@
> > > > > >  >  
> > > > > >  >      # get the path and absolute path to the current executable
> > > > > >  >      mi_gdb_test "111-file-list-exec-source-file" \
> > > > > >  > -	    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> > > > > >  > +	    "111\\\^done,line=\"23\",filename=\"${srcfilepath}\",fullname=\"/.*/${srcfile}\"" \
> > > > > >  >                 "request path info of current source file (${srcfile})"
> > > > > >  >  }
> > > > > >  >  
> > > > > >  > -test_tbreak_creation_and_listing
> > > > > >  > +proc test_file_list_exec_source_files {} {
> > > > > >  > +    global srcfile
> > > > > >  > +
> > > > > >  > +    # get the path and absolute path to the current executable
> > > > > >  > +    mi_gdb_test "222-file-list-exec-source-files" \
> > > > > >  > +	    "222\\\^done,files=\\\[\{filename=\".*/${srcfile}\",fullname=\"/.*/${srcfile}\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\},\{filename=\".*\"\}\\\]" \
> > > > > > 
> > > > > >  > +              "Getting a list of source files failed."
> > > > > >                                                  ^^^^^^^
> > > > > >                                                   why failed?
> > > > > 
> > > > > OOO, That isn't an error condition, it's just a comment. I see.
> > > > > 
> > > > > Thanks,
> > > > > Bob Rossi

Re: -file-list-exec-source-files

[Eli Zaretskii]

> Date: Tue, 20 Apr 2004 10:10:01 -0400
> From: Bob Rossi <bob@brasko.net>
> 
> Honestly, will someone please review this patch.
> 
> Seriously, why is no one looking at this patch? 
> It's been over 2 months now! 

Bob, I suggest that you submit another patch that takes into account
all the comments, mainly by Elena and Jason, that still stand after
the discussions back then.  Right now, your followups are just
reiterations of Elena's comments and your counter-comments; it's hard
to look at the patch whose many parts are invalidated by discussions.

If I missed a newer patch you've already sent, please tell me its URL
in the archives, and I will look at it.

In any case, I think Elena should have the final word, since she is
both responsible for gdb/mi and was the original reviewer of your
submission.  But I will try to help her by taking another look at your
code.

Thanks.

Re: -file-list-exec-source-files

[Bob Rossi]

On Wed, Apr 21, 2004 at 07:52:44AM +0200, Eli Zaretskii wrote:
> > Date: Tue, 20 Apr 2004 10:10:01 -0400
> > From: Bob Rossi <bob@brasko.net>
> > 
> > Honestly, will someone please review this patch.
> > 
> > Seriously, why is no one looking at this patch? 
> > It's been over 2 months now! 
> 
> Bob, I suggest that you submit another patch that takes into account
> all the comments, mainly by Elena and Jason, that still stand after
> the discussions back then.  Right now, your followups are just
> reiterations of Elena's comments and your counter-comments; it's hard
> to look at the patch whose many parts are invalidated by discussions.
> 
> If I missed a newer patch you've already sent, please tell me its URL
> in the archives, and I will look at it.
> 
> In any case, I think Elena should have the final word, since she is
> both responsible for gdb/mi and was the original reviewer of your
> submission.  But I will try to help her by taking another look at your
> code.

Thanks, I will do so right away. BTW, is there a program I can run on
the patch, to gnuify it?

If so, where do I get it?

Bob Rossi

Re: -file-list-exec-source-files

[Eli Zaretskii]

> Date: Tue, 20 Apr 2004 21:20:15 -0400
> From: Bob Rossi <bob@brasko.net>
> 
> BTW, is there a program I can run on the patch, to gnuify it?

The canonical answer to that is "GNU Indent".  You can find it on the
GNU FTP site, I think, if not on your machine.

Re: -file-list-exec-source-files

[Elena Zannoni]

Eli Zaretskii writes:
 > > Date: Tue, 20 Apr 2004 10:10:01 -0400
 > > From: Bob Rossi <bob@brasko.net>
 > > 
 > > Honestly, will someone please review this patch.
 > > 
 > > Seriously, why is no one looking at this patch? 
 > > It's been over 2 months now! 
 > 
 > Bob, I suggest that you submit another patch that takes into account
 > all the comments, mainly by Elena and Jason, that still stand after
 > the discussions back then.  Right now, your followups are just
 > reiterations of Elena's comments and your counter-comments; it's hard
 > to look at the patch whose many parts are invalidated by discussions.
 > 
 > If I missed a newer patch you've already sent, please tell me its URL
 > in the archives, and I will look at it.
 > 
 > In any case, I think Elena should have the final word, since she is
 > both responsible for gdb/mi and was the original reviewer of your
 > submission.  But I will try to help her by taking another look at your
 > code.
 > 

Thank you Eli for helping in this, I appreciate the help.  Bob, please
run gdb_indent.sh (found in the gdb source directory) on your code to
make it conform to gnu standards. Also address the issues you feel
comfortable fixing. Once that's done we can have another look.


 > Thanks.

Re: -file-list-exec-source-files

[Bob Rossi]

On Thu, Apr 22, 2004 at 11:40:31AM -0400, Elena Zannoni wrote:
> Eli Zaretskii writes:
>  > > Date: Tue, 20 Apr 2004 10:10:01 -0400
>  > > From: Bob Rossi <bob@brasko.net>
>  > > 
>  > > Honestly, will someone please review this patch.
>  > > 
>  > > Seriously, why is no one looking at this patch? 
>  > > It's been over 2 months now! 
>  > 
>  > Bob, I suggest that you submit another patch that takes into account
>  > all the comments, mainly by Elena and Jason, that still stand after
>  > the discussions back then.  Right now, your followups are just
>  > reiterations of Elena's comments and your counter-comments; it's hard
>  > to look at the patch whose many parts are invalidated by discussions.
>  > 
>  > If I missed a newer patch you've already sent, please tell me its URL
>  > in the archives, and I will look at it.
>  > 
>  > In any case, I think Elena should have the final word, since she is
>  > both responsible for gdb/mi and was the original reviewer of your
>  > submission.  But I will try to help her by taking another look at your
>  > code.
>  > 
> 
> Thank you Eli for helping in this, I appreciate the help.  Bob, please
> run gdb_indent.sh (found in the gdb source directory) on your code to
> make it conform to gnu standards. Also address the issues you feel
> comfortable fixing. Once that's done we can have another look.

Thanks, here is a new patch. The testsuite is still passing with this
change.

I hopefully fixed the formatting problems and most of the other issues
you brought up. The only 2 known issues are the 
   1. dwarf2 specs about :pathname or hostname:pathname
   2. comments about source.c

   Here were your comments with my respone,
   
> this part I am not clear about.

Ok, Ok. I thought about this a lot. I think I made the best decision and
can describe why.

A few assumptions are in order. In order to get the fullname (abs path)
to a file, GDB need's three things. The directory the file was compiled
in (dirname), the filename in question (filename) and a list of paths
to search.

> There is already a function called source_full_path_of() would it help
> if you used it?

The function source_full_path_of does not take into account 'dirname'.
It calls openp, which is not capable of finding the fullname of a file,
since it doesn't understand what dirname is. Basically, I don't even
think this function (source_full_path_of) is "truly" capable of
finding the fullpath to a file. However, instead of removing it,
I left it, since caller's of this function might be using for something
I know nothing about.

> What is the difference between find_and_open_source and
> open_source_file?  I.e. why did you need to introduce it. I think it's
> not clear just from your comments about the file possibly baing moved
> around.

open_source_file was left around for backwards compatibility. The unit
source.c was used to calling a function, with just passing the symtab,
and getting back the symtab with a valid fullname. I could remove all
occurences of this function and replace it with symtab_to_fullname.

> I am a bit worried about the substitution of symtab_to_filename with
> symtab_to_fullname. The former returns null only if there is no
> symtab.  The latter returns null when there is no symtab OR when it
> cannot find the file. So the behavior is slightly different.

I basically think that the call -file-list-exec-source-files shouldn't
'cache' it's results. GDB looks for each file, every time it is
requested to get the fullname. This is because, the user could have
changed the path, or moved/deleted the file. I don't think GDB should
just return the filename instead, of the fullname.

So, if find_and_open_source couldn't "find and open the source file", it
returns NULL. Also, as a side effect, fullname in the [ps]ymtab also
get's set to NULL.

The testsuite didn't seem to have a problem with this, and I think it
makes sense to not trick the caller into having results when it couldn't
find any.

If the caller really wanted this functionality,
  return s->filename; /* File not found.  Just use short name */
I believe it should be the caller's responsibility.

if ( symtab_to_fullname ( s ) == NULL )
   /* use symtab->filename */ 
else
   /* use symtab->fullname */

It doesn't really make sense to return the filename and not state that
it is not really the fullname. Also, if the caller tries to access
s->fullname, it will not be successful, because the file simply isn't
there.

Bob Rossi

Index: gdb/dbxread.c
===================================================================
RCS file: /cvs/src/src/gdb/dbxread.c,v
retrieving revision 1.64
diff -w -u -r1.64 dbxread.c
--- gdb/dbxread.c	14 Feb 2004 15:46:32 -0000	1.64
+++ gdb/dbxread.c	26 Apr 2004 23:54:42 -0000
@@ -1463,6 +1463,7 @@
 	    static int prev_so_symnum = -10;
 	    static int first_so_symnum;
 	    char *p;
+	    static char *dirname_nso;
 	    int prev_textlow_not_set;
 
 	    valu = nlist.n_value + ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile));
@@ -1520,18 +1521,27 @@
 
 	    p = strrchr (namestring, '/');
 	    if (p && *(p + 1) == '\000')
-	      continue;		/* Simply ignore directory name SOs */
+	      {
+		/* Save the directory name SOs locally, then save it into
+		   the psymtab when it's created below. */
+	        dirname_nso = namestring;
+	        continue;		
+	      }
 
 	    /* Some other compilers (C++ ones in particular) emit useless
 	       SOs for non-existant .c files.  We ignore all subsequent SOs that
 	       immediately follow the first.  */
 
 	    if (!pst)
+	      {
 	      pst = start_psymtab (objfile,
 				   namestring, valu,
 				   first_so_symnum * symbol_size,
 				   objfile->global_psymbols.next,
 				   objfile->static_psymbols.next);
+		pst->dirname = dirname_nso;
+		dirname_nso = NULL;
+	      }
 	    continue;
 	  }
 
Index: gdb/defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.144
diff -w -u -r1.144 defs.h
--- gdb/defs.h	21 Apr 2004 23:52:20 -0000	1.144
+++ gdb/defs.h	26 Apr 2004 23:54:44 -0000
@@ -616,8 +616,6 @@
 
 extern void init_last_source_visited (void);
 
-extern char *symtab_to_filename (struct symtab *);
-
 /* From exec.c */
 
 extern void exec_set_section_offsets (bfd_signed_vma text_off,
Index: gdb/dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.148
diff -w -u -r1.148 dwarf2read.c
--- gdb/dwarf2read.c	19 Apr 2004 18:20:50 -0000	1.148
+++ gdb/dwarf2read.c	26 Apr 2004 23:54:52 -0000
@@ -378,6 +378,7 @@
        sometimes DW_TAG_MIPS_linkage_name or a string computed in some
        other fashion.  */
     char *name;
+    char *dirname;
 
     /* The scope to prepend to our children.  This is generally
        allocated on the comp_unit_obstack, so will disappear
@@ -1272,6 +1273,8 @@
 				  objfile->global_psymbols.next,
 				  objfile->static_psymbols.next);
 
+      pst->dirname = xstrdup ( comp_unit_die.dirname );
+
       pst->read_symtab_private = (char *)
 	obstack_alloc (&objfile->objfile_obstack, sizeof (struct dwarf2_pinfo));
       DWARF_INFO_OFFSET (pst) = beg_of_comp_unit - dwarf2_per_objfile->info_buffer;
@@ -4771,6 +4774,10 @@
 	  /* Prefer DW_AT_MIPS_linkage_name over DW_AT_name.  */
 	  if (part_die->name == NULL)
 	    part_die->name = DW_STRING (&attr);
+	  break;
+	case DW_AT_comp_dir:
+	  if (part_die->dirname == NULL)
+	    part_die->dirname = DW_STRING (&attr);
 	  break;
 	case DW_AT_MIPS_linkage_name:
 	  part_die->name = DW_STRING (&attr);
Index: gdb/source.c
===================================================================
RCS file: /cvs/src/src/gdb/source.c,v
retrieving revision 1.50
diff -w -u -r1.50 source.c
--- gdb/source.c	28 Feb 2004 18:04:37 -0000	1.50
+++ gdb/source.c	26 Apr 2004 23:54:54 -0000
@@ -805,30 +805,45 @@
   return 1;
 }
 
-
-/* Open a source file given a symtab S.  Returns a file descriptor or
-   negative number for error.  */
-
+/* This function is capable of finding the absolute path to a
+   source file, and opening it, provided you give it an 
+   OBJFILE and FILENAME. Both the DIRNAME and FULLNAME are only
+   added suggestions on where to find the file. 
+
+   OBJFILE should be the objfile associated with a psymtab or symtab. 
+   FILENAME should be the filename to open.
+   DIRNAME is the compilation directory of a particular source file.
+           Only some debug formats provide this info.
+   FULLNAME can be the last known absolute path to the file in question.
+
+   On Success 
+     A valid file descriptor is returned. ( the return value is positive )
+     FULLNAME is set to the absolute path to the file just opened.
+
+   On Failure
+     A non valid file descriptor is returned. ( the return value is negitive ) 
+     FULLNAME is set to NULL.  */
 int
-open_source_file (struct symtab *s)
+find_and_open_source (struct objfile *objfile,
+  const char *filename,
+  const char *dirname, char **fullname)
 {
   char *path = source_path;
   const char *p;
   int result;
-  char *fullname;
 
   /* Quick way out if we already know its full name */
-  if (s->fullname)
+  if (*fullname)
     {
-      result = open (s->fullname, OPEN_MODE);
+      result = open (*fullname, OPEN_MODE);
       if (result >= 0)
 	return result;
       /* Didn't work -- free old one, try again. */
-      xmfree (s->objfile->md, s->fullname);
-      s->fullname = NULL;
+      xmfree (objfile->md, *fullname);
+      *fullname = NULL;
     }
 
-  if (s->dirname != NULL)
+  if (dirname != NULL)
     {
       /* Replace a path entry of  $cdir  with the compilation directory name */
 #define	cdir_len	5
@@ -841,60 +856,106 @@
 	  int len;
 
 	  path = (char *)
-	    alloca (strlen (source_path) + 1 + strlen (s->dirname) + 1);
+	    alloca (strlen (source_path) + 1 + strlen (dirname) + 1);
 	  len = p - source_path;
 	  strncpy (path, source_path, len);	/* Before $cdir */
-	  strcpy (path + len, s->dirname);	/* new stuff */
+	  strcpy (path + len, dirname);	/* new stuff */
 	  strcat (path + len, source_path + len + cdir_len);	/* After $cdir */
 	}
     }
 
-  result = openp (path, 0, s->filename, OPEN_MODE, 0, &s->fullname);
+  result = openp (path, 0, filename, OPEN_MODE, 0, fullname);
   if (result < 0)
     {
       /* Didn't work.  Try using just the basename. */
-      p = lbasename (s->filename);
-      if (p != s->filename)
-	result = openp (path, 0, p, OPEN_MODE, 0, &s->fullname);
+      p = lbasename (filename);
+      if (p != filename)
+	result = openp (path, 0, p, OPEN_MODE, 0, fullname);
     }
 
   if (result >= 0)
     {
-      fullname = s->fullname;
-      s->fullname = mstrsave (s->objfile->md, s->fullname);
-      xfree (fullname);
+      char *tmp_fullname;
+      tmp_fullname = *fullname;
+      *fullname = mstrsave (objfile->md, *fullname);
+      xfree (tmp_fullname);
     }
   return result;
 }
 
-/* Return the path to the source file associated with symtab.  Returns NULL
-   if no symtab.  */
+/* Open a source file given a symtab S.  Returns a file descriptor or
+   negative number for error.  
+   
+   This function is a convience function to find_and_open_source. */
+
+int
+open_source_file (struct symtab *s)
+{
+    if (!s)
+      return -1;
+
+  return find_and_open_source (s->objfile, s->filename, s->dirname, 
+		  		 &s->fullname);
+}
+
+/* Finds the fullname that a symtab represents.
+
+   If this functions finds the fullname, it will save it in ps->fullname
+   and it will also return the value.
 
+   If this function fails to find the file that this symtab represents,
+   NULL will be returned and ps->fullname will be set to NULL.  */
 char *
-symtab_to_filename (struct symtab *s)
+symtab_to_fullname (struct symtab *s)
 {
-  int fd;
+  int r;
 
   if (!s)
     return NULL;
 
-  /* If we've seen the file before, just return fullname. */
+  /* Don't check s->fullname here, the file could have been 
+     deleted/moved/..., look for it again */
+  r =
+    find_and_open_source (s->objfile, s->filename, s->dirname, &s->fullname);
 
-  if (s->fullname)
+  if (r)
+  {
+    close (r);
     return s->fullname;
+  }
 
-  /* Try opening the file to setup fullname */
+  return NULL;
+}
 
-  fd = open_source_file (s);
-  if (fd < 0)
-    return s->filename;		/* File not found.  Just use short name */
+/* Finds the fullname that a partial_symtab represents.
 
-  /* Found the file.  Cleanup and return the full name */
+   If this functions finds the fullname, it will save it in ps->fullname
+   and it will also return the value.
 
-  close (fd);
-  return s->fullname;
+   If this function fails to find the file that this partial_symtab represents,
+   NULL will be returned and ps->fullname will be set to NULL.  */
+char *
+psymtab_to_fullname (struct partial_symtab *ps)
+{
+  int r;
+
+  if (!ps)
+    return NULL;
+
+  /* Don't check ps->fullname here, the file could have been
+     deleted/moved/..., look for it again */
+  r =
+    find_and_open_source (ps->objfile, ps->filename, ps->dirname,
+			  &ps->fullname);
+
+  if (r) 
+  {
+    close (r);
+    return ps->fullname;
 }
 \f
+  return NULL;
+}
 
 /* Create and initialize the table S->line_charpos that records
    the positions of the lines in the source file, which is assumed
Index: gdb/source.h
===================================================================
RCS file: /cvs/src/src/gdb/source.h,v
retrieving revision 1.4
diff -w -u -r1.4 source.h
--- gdb/source.h	12 Apr 2003 17:41:25 -0000	1.4
+++ gdb/source.h	26 Apr 2004 23:54:54 -0000
@@ -27,6 +27,9 @@
    negative number for error.  */
 extern int open_source_file (struct symtab *s);
 
+extern char* psymtab_to_fullname ( struct partial_symtab *ps );
+extern char* symtab_to_fullname ( struct symtab *s );
+
 /* Create and initialize the table S->line_charpos that records the
    positions of the lines in the source file, which is assumed to be
    open on descriptor DESC.  All set S->nlines to the number of such
Index: gdb/symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.129
diff -w -u -r1.129 symtab.c
--- gdb/symtab.c	8 Apr 2004 21:18:13 -0000	1.129
+++ gdb/symtab.c	26 Apr 2004 23:54:58 -0000
@@ -181,7 +181,7 @@
     
     if (full_path != NULL)
       {
-	const char *fp = symtab_to_filename (s);
+	const char *fp = symtab_to_fullname (s);
 	if (FILENAME_CMP (full_path, fp) == 0)
 	  {
 	    return s;
@@ -190,7 +190,7 @@
 
     if (real_path != NULL)
       {
-	char *rp = gdb_realpath (symtab_to_filename (s));
+	char *rp = gdb_realpath (symtab_to_fullname (s));
         make_cleanup (xfree, rp);
 	if (FILENAME_CMP (real_path, rp) == 0)
 	  {
Index: gdb/symtab.h
===================================================================
RCS file: /cvs/src/src/gdb/symtab.h,v
retrieving revision 1.90
diff -w -u -r1.90 symtab.h
--- gdb/symtab.h	8 Apr 2004 21:18:13 -0000	1.90
+++ gdb/symtab.h	26 Apr 2004 23:55:01 -0000
@@ -877,6 +877,10 @@
 
   char *fullname;
 
+  /* Directory in which it was compiled, or NULL if we don't know.  */
+
+  char *dirname;
+
   /* Information about the object file from which symbols should be read.  */
 
   struct objfile *objfile;
Index: gdb/doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.202
diff -w -u -r1.202 gdb.texinfo
--- gdb/doc/gdb.texinfo	28 Mar 2004 12:22:55 -0000	1.202
+++ gdb/doc/gdb.texinfo	26 Apr 2004 23:55:26 -0000
@@ -16805,14 +16805,24 @@
 
 List the source files for the current executable.
 
+It will always output the filename, but only when GDB can find the absolute
+path to a source file, will it output the fullname.
+
 @subsubheading @value{GDBN} Command
 
 There's no @value{GDBN} command which directly corresponds to this one.
 @code{gdbtk} has an analogous command @samp{gdb_listfiles}.
 
 @subsubheading Example
-N.A.
-
+@smallexample
+(@value{GDBP})
+-file-list-exec-source-files
+^done,files=[
+@{file=foo.c,fullname=/home/foo.c@},
+@{file=/home/bar.c,fullname=/home/bar.c@},
+@{file=gdb_could_not_find_fullpath.c@}]
+(@value{GDBP})
+@end smallexample
 
 @subheading The @code{-file-list-shared-libraries} Command
 @findex -file-list-shared-libraries
Index: gdb/mi/mi-cmd-file.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmd-file.c,v
retrieving revision 1.1
diff -w -u -r1.1 mi-cmd-file.c
--- gdb/mi/mi-cmd-file.c	2 Apr 2003 22:10:35 -0000	1.1
+++ gdb/mi/mi-cmd-file.c	26 Apr 2004 23:55:26 -0000
@@ -25,6 +25,7 @@
 #include "ui-out.h"
 #include "symtab.h"
 #include "source.h"
+#include "objfiles.h"
 
 /* Return to the client the absolute path and line number of the 
    current file being executed. */
@@ -39,7 +40,6 @@
   if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_file", argc, argv) )
     error ("mi_cmd_file_list_exec_source_file: Usage: No args");
 
-  
   /* Set the default file and line, also get them */
   set_default_source_symtab_and_line();
   st = get_current_source_symtab_and_line();
@@ -51,17 +51,68 @@
     error ("mi_cmd_file_list_exec_source_file: No symtab");
 
   /* Extract the fullname if it is not known yet */
-  if (st.symtab->fullname == NULL)
-    symtab_to_filename (st.symtab);
-
-  /* We may not be able to open the file (not available). */
-  if (st.symtab->fullname == NULL)
-    error ("mi_cmd_file_list_exec_source_file: File not found");
+  symtab_to_fullname (st.symtab);
 
   /* Print to the user the line, filename and fullname */
   ui_out_field_int (uiout, "line", st.line);
   ui_out_field_string (uiout, "file", st.symtab->filename);
+
+  /* We may not be able to open the file (not available). */
+  if (st.symtab->fullname)
   ui_out_field_string (uiout, "fullname", st.symtab->fullname);
+
+  return MI_CMD_DONE;
+}
+
+enum mi_cmd_result
+mi_cmd_file_list_exec_source_files (char *command, char **argv, int argc)
+{
+  struct symtab *s;
+  struct partial_symtab *ps;
+  struct objfile *objfile;
+
+  if (!mi_valid_noargs ("mi_cmd_file_list_exec_source_files", argc, argv))
+    error ("mi_cmd_file_list_exec_source_files: Usage: No args");
+
+  /* Print the table header */
+  ui_out_begin (uiout, ui_out_type_list, "files");
+
+  /* Look at all of the symtabs */
+  ALL_SYMTABS (objfile, s)
+  {
+    ui_out_begin (uiout, ui_out_type_tuple, NULL);
+
+    ui_out_field_string (uiout, "file", s->filename);
+
+    /* Extract the fullname if it is not known yet */
+    symtab_to_fullname (s);
+
+    if (s->fullname)
+      ui_out_field_string (uiout, "fullname", s->fullname);
+
+    ui_out_end (uiout, ui_out_type_tuple);
+  }
+
+  /* Look at all of the psymtabs */
+  ALL_PSYMTABS (objfile, ps)
+  {
+    if (!ps->readin)
+      {
+	ui_out_begin (uiout, ui_out_type_tuple, NULL);
+
+	ui_out_field_string (uiout, "file", ps->filename);
+
+	/* Extract the fullname if it is not known yet */
+	psymtab_to_fullname (ps);
+
+	if (ps->fullname)
+	  ui_out_field_string (uiout, "fullname", ps->fullname);
+
+	ui_out_end (uiout, ui_out_type_tuple);
+      }
+  }
+
+  ui_out_end (uiout, ui_out_type_list);
 
   return MI_CMD_DONE;
 }
Index: gdb/mi/mi-cmds.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmds.c,v
retrieving revision 1.14
diff -w -u -r1.14 mi-cmds.c
--- gdb/mi/mi-cmds.c	4 Aug 2003 23:18:50 -0000	1.14
+++ gdb/mi/mi-cmds.c	26 Apr 2004 23:55:26 -0000
@@ -81,7 +81,7 @@
   { "file-exec-file", { "exec-file", 1 }, NULL, NULL },
   { "file-list-exec-sections", { NULL, 0 }, NULL, NULL },
   { "file-list-exec-source-file", { NULL, 0 }, 0, mi_cmd_file_list_exec_source_file},
-  { "file-list-exec-source-files", { NULL, 0 }, NULL, NULL },
+  { "file-list-exec-source-files", { NULL, 0 }, NULL, mi_cmd_file_list_exec_source_files },
   { "file-list-shared-libraries", { NULL, 0 }, NULL, NULL },
   { "file-list-symbol-files", { NULL, 0 }, NULL, NULL },
   { "file-symbol-file", { "symbol-file", 1 }, NULL, NULL },
Index: gdb/mi/mi-cmds.h
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmds.h,v
retrieving revision 1.12
diff -w -u -r1.12 mi-cmds.h
--- gdb/mi/mi-cmds.h	24 Jan 2004 04:21:43 -0000	1.12
+++ gdb/mi/mi-cmds.h	26 Apr 2004 23:55:26 -0000
@@ -87,6 +87,7 @@
 extern mi_cmd_args_ftype mi_cmd_exec_until;
 extern mi_cmd_args_ftype mi_cmd_exec_interrupt;
 extern mi_cmd_argv_ftype mi_cmd_file_list_exec_source_file;
+extern mi_cmd_argv_ftype mi_cmd_file_list_exec_source_files;
 extern mi_cmd_argv_ftype mi_cmd_gdb_exit;
 extern mi_cmd_argv_ftype mi_cmd_interpreter_exec;
 extern mi_cmd_argv_ftype mi_cmd_stack_info_depth;
Index: gdb/testsuite/gdb.mi/mi2-file.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi2-file.exp,v
retrieving revision 1.1
diff -w -u -r1.1 mi2-file.exp
--- gdb/testsuite/gdb.mi/mi2-file.exp	7 Aug 2003 17:47:42 -0000	1.1
+++ gdb/testsuite/gdb.mi/mi2-file.exp	26 Apr 2004 23:55:27 -0000
@@ -47,7 +47,7 @@
 mi_gdb_reinitialize_dir $srcdir/$subdir
 mi_gdb_load ${binfile}
 
-proc test_tbreak_creation_and_listing {} {
+proc test_file_list_exec_source_file {} {
     global srcfile
     global srcdir
     global subdir
@@ -59,7 +59,17 @@
                "request path info of current source file (${srcfile})"
 }
 
-test_tbreak_creation_and_listing
+proc test_file_list_exec_source_files {} {
+    global srcfile
+
+    # get the path and absolute path to the current executable
+    mi_gdb_test "222-file-list-exec-source-files" \
+	    "222\\\^done,files=\\\[\{file=\".*/${srcfile}\",fullname=\"/.*/${srcfile}\"\},\{file=\".*\"\},\{file=\".*\"\},\{file=\".*\"\},\{file=\".*\"\}\\\]" \
+              "Getting a list of source files."
+}
+
+test_file_list_exec_source_file
+test_file_list_exec_source_files
 
 mi_gdb_exit
 return 0

Re: -file-list-exec-source-files

[Bob Rossi]

Any comments?

Bob Rossi

On Mon, Apr 26, 2004 at 09:05:30AM -0400, Bob Rossi wrote:
> On Thu, Apr 22, 2004 at 11:40:31AM -0400, Elena Zannoni wrote:
> > Eli Zaretskii writes:
> >  > > Date: Tue, 20 Apr 2004 10:10:01 -0400
> >  > > From: Bob Rossi <bob@brasko.net>
> >  > > 
> >  > > Honestly, will someone please review this patch.
> >  > > 
> >  > > Seriously, why is no one looking at this patch? 
> >  > > It's been over 2 months now! 
> >  > 
> >  > Bob, I suggest that you submit another patch that takes into account
> >  > all the comments, mainly by Elena and Jason, that still stand after
> >  > the discussions back then.  Right now, your followups are just
> >  > reiterations of Elena's comments and your counter-comments; it's hard
> >  > to look at the patch whose many parts are invalidated by discussions.
> >  > 
> >  > If I missed a newer patch you've already sent, please tell me its URL
> >  > in the archives, and I will look at it.
> >  > 
> >  > In any case, I think Elena should have the final word, since she is
> >  > both responsible for gdb/mi and was the original reviewer of your
> >  > submission.  But I will try to help her by taking another look at your
> >  > code.
> >  > 
> > 
> > Thank you Eli for helping in this, I appreciate the help.  Bob, please
> > run gdb_indent.sh (found in the gdb source directory) on your code to
> > make it conform to gnu standards. Also address the issues you feel
> > comfortable fixing. Once that's done we can have another look.
> 
> Thanks, here is a new patch. The testsuite is still passing with this
> change.
> 
> I hopefully fixed the formatting problems and most of the other issues
> you brought up. The only 2 known issues are the 
>    1. dwarf2 specs about :pathname or hostname:pathname
>    2. comments about source.c
> 
>    Here were your comments with my respone,
>    
> > this part I am not clear about.
> 
> Ok, Ok. I thought about this a lot. I think I made the best decision and
> can describe why.
> 
> A few assumptions are in order. In order to get the fullname (abs path)
> to a file, GDB need's three things. The directory the file was compiled
> in (dirname), the filename in question (filename) and a list of paths
> to search.
> 
> > There is already a function called source_full_path_of() would it help
> > if you used it?
> 
> The function source_full_path_of does not take into account 'dirname'.
> It calls openp, which is not capable of finding the fullname of a file,
> since it doesn't understand what dirname is. Basically, I don't even
> think this function (source_full_path_of) is "truly" capable of
> finding the fullpath to a file. However, instead of removing it,
> I left it, since caller's of this function might be using for something
> I know nothing about.
> 
> > What is the difference between find_and_open_source and
> > open_source_file?  I.e. why did you need to introduce it. I think it's
> > not clear just from your comments about the file possibly baing moved
> > around.
> 
> open_source_file was left around for backwards compatibility. The unit
> source.c was used to calling a function, with just passing the symtab,
> and getting back the symtab with a valid fullname. I could remove all
> occurences of this function and replace it with symtab_to_fullname.
> 
> > I am a bit worried about the substitution of symtab_to_filename with
> > symtab_to_fullname. The former returns null only if there is no
> > symtab.  The latter returns null when there is no symtab OR when it
> > cannot find the file. So the behavior is slightly different.
> 
> I basically think that the call -file-list-exec-source-files shouldn't
> 'cache' it's results. GDB looks for each file, every time it is
> requested to get the fullname. This is because, the user could have
> changed the path, or moved/deleted the file. I don't think GDB should
> just return the filename instead, of the fullname.
> 
> So, if find_and_open_source couldn't "find and open the source file", it
> returns NULL. Also, as a side effect, fullname in the [ps]ymtab also
> get's set to NULL.
> 
> The testsuite didn't seem to have a problem with this, and I think it
> makes sense to not trick the caller into having results when it couldn't
> find any.
> 
> If the caller really wanted this functionality,
>   return s->filename; /* File not found.  Just use short name */
> I believe it should be the caller's responsibility.
> 
> if ( symtab_to_fullname ( s ) == NULL )
>    /* use symtab->filename */ 
> else
>    /* use symtab->fullname */
> 
> It doesn't really make sense to return the filename and not state that
> it is not really the fullname. Also, if the caller tries to access
> s->fullname, it will not be successful, because the file simply isn't
> there.
> 
> Bob Rossi
> 
> Index: gdb/dbxread.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/dbxread.c,v
> retrieving revision 1.64
> diff -w -u -r1.64 dbxread.c
> --- gdb/dbxread.c	14 Feb 2004 15:46:32 -0000	1.64
> +++ gdb/dbxread.c	26 Apr 2004 23:54:42 -0000
> @@ -1463,6 +1463,7 @@
>  	    static int prev_so_symnum = -10;
>  	    static int first_so_symnum;
>  	    char *p;
> +	    static char *dirname_nso;
>  	    int prev_textlow_not_set;
>  
>  	    valu = nlist.n_value + ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile));
> @@ -1520,18 +1521,27 @@
>  
>  	    p = strrchr (namestring, '/');
>  	    if (p && *(p + 1) == '\000')
> -	      continue;		/* Simply ignore directory name SOs */
> +	      {
> +		/* Save the directory name SOs locally, then save it into
> +		   the psymtab when it's created below. */
> +	        dirname_nso = namestring;
> +	        continue;		
> +	      }
>  
>  	    /* Some other compilers (C++ ones in particular) emit useless
>  	       SOs for non-existant .c files.  We ignore all subsequent SOs that
>  	       immediately follow the first.  */
>  
>  	    if (!pst)
> +	      {
>  	      pst = start_psymtab (objfile,
>  				   namestring, valu,
>  				   first_so_symnum * symbol_size,
>  				   objfile->global_psymbols.next,
>  				   objfile->static_psymbols.next);
> +		pst->dirname = dirname_nso;
> +		dirname_nso = NULL;
> +	      }
>  	    continue;
>  	  }
>  
> Index: gdb/defs.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/defs.h,v
> retrieving revision 1.144
> diff -w -u -r1.144 defs.h
> --- gdb/defs.h	21 Apr 2004 23:52:20 -0000	1.144
> +++ gdb/defs.h	26 Apr 2004 23:54:44 -0000
> @@ -616,8 +616,6 @@
>  
>  extern void init_last_source_visited (void);
>  
> -extern char *symtab_to_filename (struct symtab *);
> -
>  /* From exec.c */
>  
>  extern void exec_set_section_offsets (bfd_signed_vma text_off,
> Index: gdb/dwarf2read.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/dwarf2read.c,v
> retrieving revision 1.148
> diff -w -u -r1.148 dwarf2read.c
> --- gdb/dwarf2read.c	19 Apr 2004 18:20:50 -0000	1.148
> +++ gdb/dwarf2read.c	26 Apr 2004 23:54:52 -0000
> @@ -378,6 +378,7 @@
>         sometimes DW_TAG_MIPS_linkage_name or a string computed in some
>         other fashion.  */
>      char *name;
> +    char *dirname;
>  
>      /* The scope to prepend to our children.  This is generally
>         allocated on the comp_unit_obstack, so will disappear
> @@ -1272,6 +1273,8 @@
>  				  objfile->global_psymbols.next,
>  				  objfile->static_psymbols.next);
>  
> +      pst->dirname = xstrdup ( comp_unit_die.dirname );
> +
>        pst->read_symtab_private = (char *)
>  	obstack_alloc (&objfile->objfile_obstack, sizeof (struct dwarf2_pinfo));
>        DWARF_INFO_OFFSET (pst) = beg_of_comp_unit - dwarf2_per_objfile->info_buffer;
> @@ -4771,6 +4774,10 @@
>  	  /* Prefer DW_AT_MIPS_linkage_name over DW_AT_name.  */
>  	  if (part_die->name == NULL)
>  	    part_die->name = DW_STRING (&attr);
> +	  break;
> +	case DW_AT_comp_dir:
> +	  if (part_die->dirname == NULL)
> +	    part_die->dirname = DW_STRING (&attr);
>  	  break;
>  	case DW_AT_MIPS_linkage_name:
>  	  part_die->name = DW_STRING (&attr);
> Index: gdb/source.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/source.c,v
> retrieving revision 1.50
> diff -w -u -r1.50 source.c
> --- gdb/source.c	28 Feb 2004 18:04:37 -0000	1.50
> +++ gdb/source.c	26 Apr 2004 23:54:54 -0000
> @@ -805,30 +805,45 @@
>    return 1;
>  }
>  
> -
> -/* Open a source file given a symtab S.  Returns a file descriptor or
> -   negative number for error.  */
> -
> +/* This function is capable of finding the absolute path to a
> +   source file, and opening it, provided you give it an 
> +   OBJFILE and FILENAME. Both the DIRNAME and FULLNAME are only
> +   added suggestions on where to find the file. 
> +
> +   OBJFILE should be the objfile associated with a psymtab or symtab. 
> +   FILENAME should be the filename to open.
> +   DIRNAME is the compilation directory of a particular source file.
> +           Only some debug formats provide this info.
> +   FULLNAME can be the last known absolute path to the file in question.
> +
> +   On Success 
> +     A valid file descriptor is returned. ( the return value is positive )
> +     FULLNAME is set to the absolute path to the file just opened.
> +
> +   On Failure
> +     A non valid file descriptor is returned. ( the return value is negitive ) 
> +     FULLNAME is set to NULL.  */
>  int
> -open_source_file (struct symtab *s)
> +find_and_open_source (struct objfile *objfile,
> +  const char *filename,
> +  const char *dirname, char **fullname)
>  {
>    char *path = source_path;
>    const char *p;
>    int result;
> -  char *fullname;
>  
>    /* Quick way out if we already know its full name */
> -  if (s->fullname)
> +  if (*fullname)
>      {
> -      result = open (s->fullname, OPEN_MODE);
> +      result = open (*fullname, OPEN_MODE);
>        if (result >= 0)
>  	return result;
>        /* Didn't work -- free old one, try again. */
> -      xmfree (s->objfile->md, s->fullname);
> -      s->fullname = NULL;
> +      xmfree (objfile->md, *fullname);
> +      *fullname = NULL;
>      }
>  
> -  if (s->dirname != NULL)
> +  if (dirname != NULL)
>      {
>        /* Replace a path entry of  $cdir  with the compilation directory name */
>  #define	cdir_len	5
> @@ -841,60 +856,106 @@
>  	  int len;
>  
>  	  path = (char *)
> -	    alloca (strlen (source_path) + 1 + strlen (s->dirname) + 1);
> +	    alloca (strlen (source_path) + 1 + strlen (dirname) + 1);
>  	  len = p - source_path;
>  	  strncpy (path, source_path, len);	/* Before $cdir */
> -	  strcpy (path + len, s->dirname);	/* new stuff */
> +	  strcpy (path + len, dirname);	/* new stuff */
>  	  strcat (path + len, source_path + len + cdir_len);	/* After $cdir */
>  	}
>      }
>  
> -  result = openp (path, 0, s->filename, OPEN_MODE, 0, &s->fullname);
> +  result = openp (path, 0, filename, OPEN_MODE, 0, fullname);
>    if (result < 0)
>      {
>        /* Didn't work.  Try using just the basename. */
> -      p = lbasename (s->filename);
> -      if (p != s->filename)
> -	result = openp (path, 0, p, OPEN_MODE, 0, &s->fullname);
> +      p = lbasename (filename);
> +      if (p != filename)
> +	result = openp (path, 0, p, OPEN_MODE, 0, fullname);
>      }
>  
>    if (result >= 0)
>      {
> -      fullname = s->fullname;
> -      s->fullname = mstrsave (s->objfile->md, s->fullname);
> -      xfree (fullname);
> +      char *tmp_fullname;
> +      tmp_fullname = *fullname;
> +      *fullname = mstrsave (objfile->md, *fullname);
> +      xfree (tmp_fullname);
>      }
>    return result;
>  }
>  
> -/* Return the path to the source file associated with symtab.  Returns NULL
> -   if no symtab.  */
> +/* Open a source file given a symtab S.  Returns a file descriptor or
> +   negative number for error.  
> +   
> +   This function is a convience function to find_and_open_source. */
> +
> +int
> +open_source_file (struct symtab *s)
> +{
> +    if (!s)
> +      return -1;
> +
> +  return find_and_open_source (s->objfile, s->filename, s->dirname, 
> +		  		 &s->fullname);
> +}
> +
> +/* Finds the fullname that a symtab represents.
> +
> +   If this functions finds the fullname, it will save it in ps->fullname
> +   and it will also return the value.
>  
> +   If this function fails to find the file that this symtab represents,
> +   NULL will be returned and ps->fullname will be set to NULL.  */
>  char *
> -symtab_to_filename (struct symtab *s)
> +symtab_to_fullname (struct symtab *s)
>  {
> -  int fd;
> +  int r;
>  
>    if (!s)
>      return NULL;
>  
> -  /* If we've seen the file before, just return fullname. */
> +  /* Don't check s->fullname here, the file could have been 
> +     deleted/moved/..., look for it again */
> +  r =
> +    find_and_open_source (s->objfile, s->filename, s->dirname, &s->fullname);
>  
> -  if (s->fullname)
> +  if (r)
> +  {
> +    close (r);
>      return s->fullname;
> +  }
>  
> -  /* Try opening the file to setup fullname */
> +  return NULL;
> +}
>  
> -  fd = open_source_file (s);
> -  if (fd < 0)
> -    return s->filename;		/* File not found.  Just use short name */
> +/* Finds the fullname that a partial_symtab represents.
>  
> -  /* Found the file.  Cleanup and return the full name */
> +   If this functions finds the fullname, it will save it in ps->fullname
> +   and it will also return the value.
>  
> -  close (fd);
> -  return s->fullname;
> +   If this function fails to find the file that this partial_symtab represents,
> +   NULL will be returned and ps->fullname will be set to NULL.  */
> +char *
> +psymtab_to_fullname (struct partial_symtab *ps)
> +{
> +  int r;
> +
> +  if (!ps)
> +    return NULL;
> +
> +  /* Don't check ps->fullname here, the file could have been
> +     deleted/moved/..., look for it again */
> +  r =
> +    find_and_open_source (ps->objfile, ps->filename, ps->dirname,
> +			  &ps->fullname);
> +
> +  if (r) 
> +  {
> +    close (r);
> +    return ps->fullname;
>  }
>  \f
> +  return NULL;
> +}
>  
>  /* Create and initialize the table S->line_charpos that records
>     the positions of the lines in the source file, which is assumed
> Index: gdb/source.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/source.h,v
> retrieving revision 1.4
> diff -w -u -r1.4 source.h
> --- gdb/source.h	12 Apr 2003 17:41:25 -0000	1.4
> +++ gdb/source.h	26 Apr 2004 23:54:54 -0000
> @@ -27,6 +27,9 @@
>     negative number for error.  */
>  extern int open_source_file (struct symtab *s);
>  
> +extern char* psymtab_to_fullname ( struct partial_symtab *ps );
> +extern char* symtab_to_fullname ( struct symtab *s );
> +
>  /* Create and initialize the table S->line_charpos that records the
>     positions of the lines in the source file, which is assumed to be
>     open on descriptor DESC.  All set S->nlines to the number of such
> Index: gdb/symtab.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/symtab.c,v
> retrieving revision 1.129
> diff -w -u -r1.129 symtab.c
> --- gdb/symtab.c	8 Apr 2004 21:18:13 -0000	1.129
> +++ gdb/symtab.c	26 Apr 2004 23:54:58 -0000
> @@ -181,7 +181,7 @@
>      
>      if (full_path != NULL)
>        {
> -	const char *fp = symtab_to_filename (s);
> +	const char *fp = symtab_to_fullname (s);
>  	if (FILENAME_CMP (full_path, fp) == 0)
>  	  {
>  	    return s;
> @@ -190,7 +190,7 @@
>  
>      if (real_path != NULL)
>        {
> -	char *rp = gdb_realpath (symtab_to_filename (s));
> +	char *rp = gdb_realpath (symtab_to_fullname (s));
>          make_cleanup (xfree, rp);
>  	if (FILENAME_CMP (real_path, rp) == 0)
>  	  {
> Index: gdb/symtab.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/symtab.h,v
> retrieving revision 1.90
> diff -w -u -r1.90 symtab.h
> --- gdb/symtab.h	8 Apr 2004 21:18:13 -0000	1.90
> +++ gdb/symtab.h	26 Apr 2004 23:55:01 -0000
> @@ -877,6 +877,10 @@
>  
>    char *fullname;
>  
> +  /* Directory in which it was compiled, or NULL if we don't know.  */
> +
> +  char *dirname;
> +
>    /* Information about the object file from which symbols should be read.  */
>  
>    struct objfile *objfile;
> Index: gdb/doc/gdb.texinfo
> ===================================================================
> RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
> retrieving revision 1.202
> diff -w -u -r1.202 gdb.texinfo
> --- gdb/doc/gdb.texinfo	28 Mar 2004 12:22:55 -0000	1.202
> +++ gdb/doc/gdb.texinfo	26 Apr 2004 23:55:26 -0000
> @@ -16805,14 +16805,24 @@
>  
>  List the source files for the current executable.
>  
> +It will always output the filename, but only when GDB can find the absolute
> +path to a source file, will it output the fullname.
> +
>  @subsubheading @value{GDBN} Command
>  
>  There's no @value{GDBN} command which directly corresponds to this one.
>  @code{gdbtk} has an analogous command @samp{gdb_listfiles}.
>  
>  @subsubheading Example
> -N.A.
> -
> +@smallexample
> +(@value{GDBP})
> +-file-list-exec-source-files
> +^done,files=[
> +@{file=foo.c,fullname=/home/foo.c@},
> +@{file=/home/bar.c,fullname=/home/bar.c@},
> +@{file=gdb_could_not_find_fullpath.c@}]
> +(@value{GDBP})
> +@end smallexample
>  
>  @subheading The @code{-file-list-shared-libraries} Command
>  @findex -file-list-shared-libraries
> Index: gdb/mi/mi-cmd-file.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/mi/mi-cmd-file.c,v
> retrieving revision 1.1
> diff -w -u -r1.1 mi-cmd-file.c
> --- gdb/mi/mi-cmd-file.c	2 Apr 2003 22:10:35 -0000	1.1
> +++ gdb/mi/mi-cmd-file.c	26 Apr 2004 23:55:26 -0000
> @@ -25,6 +25,7 @@
>  #include "ui-out.h"
>  #include "symtab.h"
>  #include "source.h"
> +#include "objfiles.h"
>  
>  /* Return to the client the absolute path and line number of the 
>     current file being executed. */
> @@ -39,7 +40,6 @@
>    if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_file", argc, argv) )
>      error ("mi_cmd_file_list_exec_source_file: Usage: No args");
>  
> -  
>    /* Set the default file and line, also get them */
>    set_default_source_symtab_and_line();
>    st = get_current_source_symtab_and_line();
> @@ -51,17 +51,68 @@
>      error ("mi_cmd_file_list_exec_source_file: No symtab");
>  
>    /* Extract the fullname if it is not known yet */
> -  if (st.symtab->fullname == NULL)
> -    symtab_to_filename (st.symtab);
> -
> -  /* We may not be able to open the file (not available). */
> -  if (st.symtab->fullname == NULL)
> -    error ("mi_cmd_file_list_exec_source_file: File not found");
> +  symtab_to_fullname (st.symtab);
>  
>    /* Print to the user the line, filename and fullname */
>    ui_out_field_int (uiout, "line", st.line);
>    ui_out_field_string (uiout, "file", st.symtab->filename);
> +
> +  /* We may not be able to open the file (not available). */
> +  if (st.symtab->fullname)
>    ui_out_field_string (uiout, "fullname", st.symtab->fullname);
> +
> +  return MI_CMD_DONE;
> +}
> +
> +enum mi_cmd_result
> +mi_cmd_file_list_exec_source_files (char *command, char **argv, int argc)
> +{
> +  struct symtab *s;
> +  struct partial_symtab *ps;
> +  struct objfile *objfile;
> +
> +  if (!mi_valid_noargs ("mi_cmd_file_list_exec_source_files", argc, argv))
> +    error ("mi_cmd_file_list_exec_source_files: Usage: No args");
> +
> +  /* Print the table header */
> +  ui_out_begin (uiout, ui_out_type_list, "files");
> +
> +  /* Look at all of the symtabs */
> +  ALL_SYMTABS (objfile, s)
> +  {
> +    ui_out_begin (uiout, ui_out_type_tuple, NULL);
> +
> +    ui_out_field_string (uiout, "file", s->filename);
> +
> +    /* Extract the fullname if it is not known yet */
> +    symtab_to_fullname (s);
> +
> +    if (s->fullname)
> +      ui_out_field_string (uiout, "fullname", s->fullname);
> +
> +    ui_out_end (uiout, ui_out_type_tuple);
> +  }
> +
> +  /* Look at all of the psymtabs */
> +  ALL_PSYMTABS (objfile, ps)
> +  {
> +    if (!ps->readin)
> +      {
> +	ui_out_begin (uiout, ui_out_type_tuple, NULL);
> +
> +	ui_out_field_string (uiout, "file", ps->filename);
> +
> +	/* Extract the fullname if it is not known yet */
> +	psymtab_to_fullname (ps);
> +
> +	if (ps->fullname)
> +	  ui_out_field_string (uiout, "fullname", ps->fullname);
> +
> +	ui_out_end (uiout, ui_out_type_tuple);
> +      }
> +  }
> +
> +  ui_out_end (uiout, ui_out_type_list);
>  
>    return MI_CMD_DONE;
>  }
> Index: gdb/mi/mi-cmds.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/mi/mi-cmds.c,v
> retrieving revision 1.14
> diff -w -u -r1.14 mi-cmds.c
> --- gdb/mi/mi-cmds.c	4 Aug 2003 23:18:50 -0000	1.14
> +++ gdb/mi/mi-cmds.c	26 Apr 2004 23:55:26 -0000
> @@ -81,7 +81,7 @@
>    { "file-exec-file", { "exec-file", 1 }, NULL, NULL },
>    { "file-list-exec-sections", { NULL, 0 }, NULL, NULL },
>    { "file-list-exec-source-file", { NULL, 0 }, 0, mi_cmd_file_list_exec_source_file},
> -  { "file-list-exec-source-files", { NULL, 0 }, NULL, NULL },
> +  { "file-list-exec-source-files", { NULL, 0 }, NULL, mi_cmd_file_list_exec_source_files },
>    { "file-list-shared-libraries", { NULL, 0 }, NULL, NULL },
>    { "file-list-symbol-files", { NULL, 0 }, NULL, NULL },
>    { "file-symbol-file", { "symbol-file", 1 }, NULL, NULL },
> Index: gdb/mi/mi-cmds.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/mi/mi-cmds.h,v
> retrieving revision 1.12
> diff -w -u -r1.12 mi-cmds.h
> --- gdb/mi/mi-cmds.h	24 Jan 2004 04:21:43 -0000	1.12
> +++ gdb/mi/mi-cmds.h	26 Apr 2004 23:55:26 -0000
> @@ -87,6 +87,7 @@
>  extern mi_cmd_args_ftype mi_cmd_exec_until;
>  extern mi_cmd_args_ftype mi_cmd_exec_interrupt;
>  extern mi_cmd_argv_ftype mi_cmd_file_list_exec_source_file;
> +extern mi_cmd_argv_ftype mi_cmd_file_list_exec_source_files;
>  extern mi_cmd_argv_ftype mi_cmd_gdb_exit;
>  extern mi_cmd_argv_ftype mi_cmd_interpreter_exec;
>  extern mi_cmd_argv_ftype mi_cmd_stack_info_depth;
> Index: gdb/testsuite/gdb.mi/mi2-file.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi2-file.exp,v
> retrieving revision 1.1
> diff -w -u -r1.1 mi2-file.exp
> --- gdb/testsuite/gdb.mi/mi2-file.exp	7 Aug 2003 17:47:42 -0000	1.1
> +++ gdb/testsuite/gdb.mi/mi2-file.exp	26 Apr 2004 23:55:27 -0000
> @@ -47,7 +47,7 @@
>  mi_gdb_reinitialize_dir $srcdir/$subdir
>  mi_gdb_load ${binfile}
>  
> -proc test_tbreak_creation_and_listing {} {
> +proc test_file_list_exec_source_file {} {
>      global srcfile
>      global srcdir
>      global subdir
> @@ -59,7 +59,17 @@
>                 "request path info of current source file (${srcfile})"
>  }
>  
> -test_tbreak_creation_and_listing
> +proc test_file_list_exec_source_files {} {
> +    global srcfile
> +
> +    # get the path and absolute path to the current executable
> +    mi_gdb_test "222-file-list-exec-source-files" \
> +	    "222\\\^done,files=\\\[\{file=\".*/${srcfile}\",fullname=\"/.*/${srcfile}\"\},\{file=\".*\"\},\{file=\".*\"\},\{file=\".*\"\},\{file=\".*\"\}\\\]" \
> +              "Getting a list of source files."
> +}
> +
> +test_file_list_exec_source_file
> +test_file_list_exec_source_files
>  
>  mi_gdb_exit
>  return 0

Re: -file-list-exec-source-files

[Eli Zaretskii]

> Date: Thu, 6 May 2004 18:12:59 -0400
> From: Bob Rossi <bob@brasko.net>
> 
> Any comments?

I hope to look at this VSN.

Re: -file-list-exec-source-files

[Bob Rossi]

On Sat, May 08, 2004 at 01:29:30PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 6 May 2004 18:12:59 -0400
> > From: Bob Rossi <bob@brasko.net>
> > 
> > Any comments?
> 
> The patch looks fine to me.  Elena, could you please look at it and
> give your blessing?

Elena, I guess your the one I should nag to look at this patch. Is there
any incentive I could send your way? A box of chocolates perhaps?

> > --- gdb/doc/gdb.texinfo	28 Mar 2004 12:22:55 -0000	1.202
> > +++ gdb/doc/gdb.texinfo	26 Apr 2004 23:55:26 -0000
> > @@ -16805,14 +16805,24 @@
> >  
> >  List the source files for the current executable.
> >  
> > +It will always output the filename, but only when GDB can find the absolute
> > +path to a source file, will it output the fullname.
> 
> Please say ``can find the absolute file name of a source file''.  The
> word ``path'' is used in the GNU project's documentation for lists of
> directories used for file-searching, like the one in $PATH.
> Otherwise, the patch for documentation is approved.

Thanks, I changed the doc in my sandbox, next time I post the patch it
should be reflected.

Bob Rossi

Re: -file-list-exec-source-files

[Bob Rossi]

OK, I just finished ripping down the ceiling and walls in my kitchen.
Is there any chance my patch got reviewed in that time? There's an
outstanding bet between my wife and I that I will be able to completely
renovate my kitchen before this patch gets reviewed.

What does that say about the GDB patch review process?!?

Can I *even* get a response from someone capable of committing this
patch? 

Someone with authority, pleeeaaassseeeee help me. 

Thanks,
Bob Rossi

On Thu, May 06, 2004 at 06:12:59PM -0400, Bob Rossi wrote:
> Any comments?
> 
> Bob Rossi
> 
> On Mon, Apr 26, 2004 at 09:05:30AM -0400, Bob Rossi wrote:
> > On Thu, Apr 22, 2004 at 11:40:31AM -0400, Elena Zannoni wrote:
> > > Eli Zaretskii writes:
> > >  > > Date: Tue, 20 Apr 2004 10:10:01 -0400
> > >  > > From: Bob Rossi <bob@brasko.net>
> > >  > > 
> > >  > > Honestly, will someone please review this patch.
> > >  > > 
> > >  > > Seriously, why is no one looking at this patch? 
> > >  > > It's been over 2 months now! 
> > >  > 
> > >  > Bob, I suggest that you submit another patch that takes into account
> > >  > all the comments, mainly by Elena and Jason, that still stand after
> > >  > the discussions back then.  Right now, your followups are just
> > >  > reiterations of Elena's comments and your counter-comments; it's hard
> > >  > to look at the patch whose many parts are invalidated by discussions.
> > >  > 
> > >  > If I missed a newer patch you've already sent, please tell me its URL
> > >  > in the archives, and I will look at it.
> > >  > 
> > >  > In any case, I think Elena should have the final word, since she is
> > >  > both responsible for gdb/mi and was the original reviewer of your
> > >  > submission.  But I will try to help her by taking another look at your
> > >  > code.
> > >  > 
> > > 
> > > Thank you Eli for helping in this, I appreciate the help.  Bob, please
> > > run gdb_indent.sh (found in the gdb source directory) on your code to
> > > make it conform to gnu standards. Also address the issues you feel
> > > comfortable fixing. Once that's done we can have another look.
> > 
> > Thanks, here is a new patch. The testsuite is still passing with this
> > change.
> > 
> > I hopefully fixed the formatting problems and most of the other issues
> > you brought up. The only 2 known issues are the 
> >    1. dwarf2 specs about :pathname or hostname:pathname
> >    2. comments about source.c
> > 
> >    Here were your comments with my respone,
> >    
> > > this part I am not clear about.
> > 
> > Ok, Ok. I thought about this a lot. I think I made the best decision and
> > can describe why.
> > 
> > A few assumptions are in order. In order to get the fullname (abs path)
> > to a file, GDB need's three things. The directory the file was compiled
> > in (dirname), the filename in question (filename) and a list of paths
> > to search.
> > 
> > > There is already a function called source_full_path_of() would it help
> > > if you used it?
> > 
> > The function source_full_path_of does not take into account 'dirname'.
> > It calls openp, which is not capable of finding the fullname of a file,
> > since it doesn't understand what dirname is. Basically, I don't even
> > think this function (source_full_path_of) is "truly" capable of
> > finding the fullpath to a file. However, instead of removing it,
> > I left it, since caller's of this function might be using for something
> > I know nothing about.
> > 
> > > What is the difference between find_and_open_source and
> > > open_source_file?  I.e. why did you need to introduce it. I think it's
> > > not clear just from your comments about the file possibly baing moved
> > > around.
> > 
> > open_source_file was left around for backwards compatibility. The unit
> > source.c was used to calling a function, with just passing the symtab,
> > and getting back the symtab with a valid fullname. I could remove all
> > occurences of this function and replace it with symtab_to_fullname.
> > 
> > > I am a bit worried about the substitution of symtab_to_filename with
> > > symtab_to_fullname. The former returns null only if there is no
> > > symtab.  The latter returns null when there is no symtab OR when it
> > > cannot find the file. So the behavior is slightly different.
> > 
> > I basically think that the call -file-list-exec-source-files shouldn't
> > 'cache' it's results. GDB looks for each file, every time it is
> > requested to get the fullname. This is because, the user could have
> > changed the path, or moved/deleted the file. I don't think GDB should
> > just return the filename instead, of the fullname.
> > 
> > So, if find_and_open_source couldn't "find and open the source file", it
> > returns NULL. Also, as a side effect, fullname in the [ps]ymtab also
> > get's set to NULL.
> > 
> > The testsuite didn't seem to have a problem with this, and I think it
> > makes sense to not trick the caller into having results when it couldn't
> > find any.
> > 
> > If the caller really wanted this functionality,
> >   return s->filename; /* File not found.  Just use short name */
> > I believe it should be the caller's responsibility.
> > 
> > if ( symtab_to_fullname ( s ) == NULL )
> >    /* use symtab->filename */ 
> > else
> >    /* use symtab->fullname */
> > 
> > It doesn't really make sense to return the filename and not state that
> > it is not really the fullname. Also, if the caller tries to access
> > s->fullname, it will not be successful, because the file simply isn't
> > there.
> > 
> > Bob Rossi
> > 
> > Index: gdb/dbxread.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/dbxread.c,v
> > retrieving revision 1.64
> > diff -w -u -r1.64 dbxread.c
> > --- gdb/dbxread.c	14 Feb 2004 15:46:32 -0000	1.64
> > +++ gdb/dbxread.c	26 Apr 2004 23:54:42 -0000
> > @@ -1463,6 +1463,7 @@
> >  	    static int prev_so_symnum = -10;
> >  	    static int first_so_symnum;
> >  	    char *p;
> > +	    static char *dirname_nso;
> >  	    int prev_textlow_not_set;
> >  
> >  	    valu = nlist.n_value + ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile));
> > @@ -1520,18 +1521,27 @@
> >  
> >  	    p = strrchr (namestring, '/');
> >  	    if (p && *(p + 1) == '\000')
> > -	      continue;		/* Simply ignore directory name SOs */
> > +	      {
> > +		/* Save the directory name SOs locally, then save it into
> > +		   the psymtab when it's created below. */
> > +	        dirname_nso = namestring;
> > +	        continue;		
> > +	      }
> >  
> >  	    /* Some other compilers (C++ ones in particular) emit useless
> >  	       SOs for non-existant .c files.  We ignore all subsequent SOs that
> >  	       immediately follow the first.  */
> >  
> >  	    if (!pst)
> > +	      {
> >  	      pst = start_psymtab (objfile,
> >  				   namestring, valu,
> >  				   first_so_symnum * symbol_size,
> >  				   objfile->global_psymbols.next,
> >  				   objfile->static_psymbols.next);
> > +		pst->dirname = dirname_nso;
> > +		dirname_nso = NULL;
> > +	      }
> >  	    continue;
> >  	  }
> >  
> > Index: gdb/defs.h
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/defs.h,v
> > retrieving revision 1.144
> > diff -w -u -r1.144 defs.h
> > --- gdb/defs.h	21 Apr 2004 23:52:20 -0000	1.144
> > +++ gdb/defs.h	26 Apr 2004 23:54:44 -0000
> > @@ -616,8 +616,6 @@
> >  
> >  extern void init_last_source_visited (void);
> >  
> > -extern char *symtab_to_filename (struct symtab *);
> > -
> >  /* From exec.c */
> >  
> >  extern void exec_set_section_offsets (bfd_signed_vma text_off,
> > Index: gdb/dwarf2read.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/dwarf2read.c,v
> > retrieving revision 1.148
> > diff -w -u -r1.148 dwarf2read.c
> > --- gdb/dwarf2read.c	19 Apr 2004 18:20:50 -0000	1.148
> > +++ gdb/dwarf2read.c	26 Apr 2004 23:54:52 -0000
> > @@ -378,6 +378,7 @@
> >         sometimes DW_TAG_MIPS_linkage_name or a string computed in some
> >         other fashion.  */
> >      char *name;
> > +    char *dirname;
> >  
> >      /* The scope to prepend to our children.  This is generally
> >         allocated on the comp_unit_obstack, so will disappear
> > @@ -1272,6 +1273,8 @@
> >  				  objfile->global_psymbols.next,
> >  				  objfile->static_psymbols.next);
> >  
> > +      pst->dirname = xstrdup ( comp_unit_die.dirname );
> > +
> >        pst->read_symtab_private = (char *)
> >  	obstack_alloc (&objfile->objfile_obstack, sizeof (struct dwarf2_pinfo));
> >        DWARF_INFO_OFFSET (pst) = beg_of_comp_unit - dwarf2_per_objfile->info_buffer;
> > @@ -4771,6 +4774,10 @@
> >  	  /* Prefer DW_AT_MIPS_linkage_name over DW_AT_name.  */
> >  	  if (part_die->name == NULL)
> >  	    part_die->name = DW_STRING (&attr);
> > +	  break;
> > +	case DW_AT_comp_dir:
> > +	  if (part_die->dirname == NULL)
> > +	    part_die->dirname = DW_STRING (&attr);
> >  	  break;
> >  	case DW_AT_MIPS_linkage_name:
> >  	  part_die->name = DW_STRING (&attr);
> > Index: gdb/source.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/source.c,v
> > retrieving revision 1.50
> > diff -w -u -r1.50 source.c
> > --- gdb/source.c	28 Feb 2004 18:04:37 -0000	1.50
> > +++ gdb/source.c	26 Apr 2004 23:54:54 -0000
> > @@ -805,30 +805,45 @@
> >    return 1;
> >  }
> >  
> > -
> > -/* Open a source file given a symtab S.  Returns a file descriptor or
> > -   negative number for error.  */
> > -
> > +/* This function is capable of finding the absolute path to a
> > +   source file, and opening it, provided you give it an 
> > +   OBJFILE and FILENAME. Both the DIRNAME and FULLNAME are only
> > +   added suggestions on where to find the file. 
> > +
> > +   OBJFILE should be the objfile associated with a psymtab or symtab. 
> > +   FILENAME should be the filename to open.
> > +   DIRNAME is the compilation directory of a particular source file.
> > +           Only some debug formats provide this info.
> > +   FULLNAME can be the last known absolute path to the file in question.
> > +
> > +   On Success 
> > +     A valid file descriptor is returned. ( the return value is positive )
> > +     FULLNAME is set to the absolute path to the file just opened.
> > +
> > +   On Failure
> > +     A non valid file descriptor is returned. ( the return value is negitive ) 
> > +     FULLNAME is set to NULL.  */
> >  int
> > -open_source_file (struct symtab *s)
> > +find_and_open_source (struct objfile *objfile,
> > +  const char *filename,
> > +  const char *dirname, char **fullname)
> >  {
> >    char *path = source_path;
> >    const char *p;
> >    int result;
> > -  char *fullname;
> >  
> >    /* Quick way out if we already know its full name */
> > -  if (s->fullname)
> > +  if (*fullname)
> >      {
> > -      result = open (s->fullname, OPEN_MODE);
> > +      result = open (*fullname, OPEN_MODE);
> >        if (result >= 0)
> >  	return result;
> >        /* Didn't work -- free old one, try again. */
> > -      xmfree (s->objfile->md, s->fullname);
> > -      s->fullname = NULL;
> > +      xmfree (objfile->md, *fullname);
> > +      *fullname = NULL;
> >      }
> >  
> > -  if (s->dirname != NULL)
> > +  if (dirname != NULL)
> >      {
> >        /* Replace a path entry of  $cdir  with the compilation directory name */
> >  #define	cdir_len	5
> > @@ -841,60 +856,106 @@
> >  	  int len;
> >  
> >  	  path = (char *)
> > -	    alloca (strlen (source_path) + 1 + strlen (s->dirname) + 1);
> > +	    alloca (strlen (source_path) + 1 + strlen (dirname) + 1);
> >  	  len = p - source_path;
> >  	  strncpy (path, source_path, len);	/* Before $cdir */
> > -	  strcpy (path + len, s->dirname);	/* new stuff */
> > +	  strcpy (path + len, dirname);	/* new stuff */
> >  	  strcat (path + len, source_path + len + cdir_len);	/* After $cdir */
> >  	}
> >      }
> >  
> > -  result = openp (path, 0, s->filename, OPEN_MODE, 0, &s->fullname);
> > +  result = openp (path, 0, filename, OPEN_MODE, 0, fullname);
> >    if (result < 0)
> >      {
> >        /* Didn't work.  Try using just the basename. */
> > -      p = lbasename (s->filename);
> > -      if (p != s->filename)
> > -	result = openp (path, 0, p, OPEN_MODE, 0, &s->fullname);
> > +      p = lbasename (filename);
> > +      if (p != filename)
> > +	result = openp (path, 0, p, OPEN_MODE, 0, fullname);
> >      }
> >  
> >    if (result >= 0)
> >      {
> > -      fullname = s->fullname;
> > -      s->fullname = mstrsave (s->objfile->md, s->fullname);
> > -      xfree (fullname);
> > +      char *tmp_fullname;
> > +      tmp_fullname = *fullname;
> > +      *fullname = mstrsave (objfile->md, *fullname);
> > +      xfree (tmp_fullname);
> >      }
> >    return result;
> >  }
> >  
> > -/* Return the path to the source file associated with symtab.  Returns NULL
> > -   if no symtab.  */
> > +/* Open a source file given a symtab S.  Returns a file descriptor or
> > +   negative number for error.  
> > +   
> > +   This function is a convience function to find_and_open_source. */
> > +
> > +int
> > +open_source_file (struct symtab *s)
> > +{
> > +    if (!s)
> > +      return -1;
> > +
> > +  return find_and_open_source (s->objfile, s->filename, s->dirname, 
> > +		  		 &s->fullname);
> > +}
> > +
> > +/* Finds the fullname that a symtab represents.
> > +
> > +   If this functions finds the fullname, it will save it in ps->fullname
> > +   and it will also return the value.
> >  
> > +   If this function fails to find the file that this symtab represents,
> > +   NULL will be returned and ps->fullname will be set to NULL.  */
> >  char *
> > -symtab_to_filename (struct symtab *s)
> > +symtab_to_fullname (struct symtab *s)
> >  {
> > -  int fd;
> > +  int r;
> >  
> >    if (!s)
> >      return NULL;
> >  
> > -  /* If we've seen the file before, just return fullname. */
> > +  /* Don't check s->fullname here, the file could have been 
> > +     deleted/moved/..., look for it again */
> > +  r =
> > +    find_and_open_source (s->objfile, s->filename, s->dirname, &s->fullname);
> >  
> > -  if (s->fullname)
> > +  if (r)
> > +  {
> > +    close (r);
> >      return s->fullname;
> > +  }
> >  
> > -  /* Try opening the file to setup fullname */
> > +  return NULL;
> > +}
> >  
> > -  fd = open_source_file (s);
> > -  if (fd < 0)
> > -    return s->filename;		/* File not found.  Just use short name */
> > +/* Finds the fullname that a partial_symtab represents.
> >  
> > -  /* Found the file.  Cleanup and return the full name */
> > +   If this functions finds the fullname, it will save it in ps->fullname
> > +   and it will also return the value.
> >  
> > -  close (fd);
> > -  return s->fullname;
> > +   If this function fails to find the file that this partial_symtab represents,
> > +   NULL will be returned and ps->fullname will be set to NULL.  */
> > +char *
> > +psymtab_to_fullname (struct partial_symtab *ps)
> > +{
> > +  int r;
> > +
> > +  if (!ps)
> > +    return NULL;
> > +
> > +  /* Don't check ps->fullname here, the file could have been
> > +     deleted/moved/..., look for it again */
> > +  r =
> > +    find_and_open_source (ps->objfile, ps->filename, ps->dirname,
> > +			  &ps->fullname);
> > +
> > +  if (r) 
> > +  {
> > +    close (r);
> > +    return ps->fullname;
> >  }
> >  \f
> > +  return NULL;
> > +}
> >  
> >  /* Create and initialize the table S->line_charpos that records
> >     the positions of the lines in the source file, which is assumed
> > Index: gdb/source.h
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/source.h,v
> > retrieving revision 1.4
> > diff -w -u -r1.4 source.h
> > --- gdb/source.h	12 Apr 2003 17:41:25 -0000	1.4
> > +++ gdb/source.h	26 Apr 2004 23:54:54 -0000
> > @@ -27,6 +27,9 @@
> >     negative number for error.  */
> >  extern int open_source_file (struct symtab *s);
> >  
> > +extern char* psymtab_to_fullname ( struct partial_symtab *ps );
> > +extern char* symtab_to_fullname ( struct symtab *s );
> > +
> >  /* Create and initialize the table S->line_charpos that records the
> >     positions of the lines in the source file, which is assumed to be
> >     open on descriptor DESC.  All set S->nlines to the number of such
> > Index: gdb/symtab.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/symtab.c,v
> > retrieving revision 1.129
> > diff -w -u -r1.129 symtab.c
> > --- gdb/symtab.c	8 Apr 2004 21:18:13 -0000	1.129
> > +++ gdb/symtab.c	26 Apr 2004 23:54:58 -0000
> > @@ -181,7 +181,7 @@
> >      
> >      if (full_path != NULL)
> >        {
> > -	const char *fp = symtab_to_filename (s);
> > +	const char *fp = symtab_to_fullname (s);
> >  	if (FILENAME_CMP (full_path, fp) == 0)
> >  	  {
> >  	    return s;
> > @@ -190,7 +190,7 @@
> >  
> >      if (real_path != NULL)
> >        {
> > -	char *rp = gdb_realpath (symtab_to_filename (s));
> > +	char *rp = gdb_realpath (symtab_to_fullname (s));
> >          make_cleanup (xfree, rp);
> >  	if (FILENAME_CMP (real_path, rp) == 0)
> >  	  {
> > Index: gdb/symtab.h
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/symtab.h,v
> > retrieving revision 1.90
> > diff -w -u -r1.90 symtab.h
> > --- gdb/symtab.h	8 Apr 2004 21:18:13 -0000	1.90
> > +++ gdb/symtab.h	26 Apr 2004 23:55:01 -0000
> > @@ -877,6 +877,10 @@
> >  
> >    char *fullname;
> >  
> > +  /* Directory in which it was compiled, or NULL if we don't know.  */
> > +
> > +  char *dirname;
> > +
> >    /* Information about the object file from which symbols should be read.  */
> >  
> >    struct objfile *objfile;
> > Index: gdb/doc/gdb.texinfo
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
> > retrieving revision 1.202
> > diff -w -u -r1.202 gdb.texinfo
> > --- gdb/doc/gdb.texinfo	28 Mar 2004 12:22:55 -0000	1.202
> > +++ gdb/doc/gdb.texinfo	26 Apr 2004 23:55:26 -0000
> > @@ -16805,14 +16805,24 @@
> >  
> >  List the source files for the current executable.
> >  
> > +It will always output the filename, but only when GDB can find the absolute
> > +path to a source file, will it output the fullname.
> > +
> >  @subsubheading @value{GDBN} Command
> >  
> >  There's no @value{GDBN} command which directly corresponds to this one.
> >  @code{gdbtk} has an analogous command @samp{gdb_listfiles}.
> >  
> >  @subsubheading Example
> > -N.A.
> > -
> > +@smallexample
> > +(@value{GDBP})
> > +-file-list-exec-source-files
> > +^done,files=[
> > +@{file=foo.c,fullname=/home/foo.c@},
> > +@{file=/home/bar.c,fullname=/home/bar.c@},
> > +@{file=gdb_could_not_find_fullpath.c@}]
> > +(@value{GDBP})
> > +@end smallexample
> >  
> >  @subheading The @code{-file-list-shared-libraries} Command
> >  @findex -file-list-shared-libraries
> > Index: gdb/mi/mi-cmd-file.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/mi/mi-cmd-file.c,v
> > retrieving revision 1.1
> > diff -w -u -r1.1 mi-cmd-file.c
> > --- gdb/mi/mi-cmd-file.c	2 Apr 2003 22:10:35 -0000	1.1
> > +++ gdb/mi/mi-cmd-file.c	26 Apr 2004 23:55:26 -0000
> > @@ -25,6 +25,7 @@
> >  #include "ui-out.h"
> >  #include "symtab.h"
> >  #include "source.h"
> > +#include "objfiles.h"
> >  
> >  /* Return to the client the absolute path and line number of the 
> >     current file being executed. */
> > @@ -39,7 +40,6 @@
> >    if ( !mi_valid_noargs("mi_cmd_file_list_exec_source_file", argc, argv) )
> >      error ("mi_cmd_file_list_exec_source_file: Usage: No args");
> >  
> > -  
> >    /* Set the default file and line, also get them */
> >    set_default_source_symtab_and_line();
> >    st = get_current_source_symtab_and_line();
> > @@ -51,17 +51,68 @@
> >      error ("mi_cmd_file_list_exec_source_file: No symtab");
> >  
> >    /* Extract the fullname if it is not known yet */
> > -  if (st.symtab->fullname == NULL)
> > -    symtab_to_filename (st.symtab);
> > -
> > -  /* We may not be able to open the file (not available). */
> > -  if (st.symtab->fullname == NULL)
> > -    error ("mi_cmd_file_list_exec_source_file: File not found");
> > +  symtab_to_fullname (st.symtab);
> >  
> >    /* Print to the user the line, filename and fullname */
> >    ui_out_field_int (uiout, "line", st.line);
> >    ui_out_field_string (uiout, "file", st.symtab->filename);
> > +
> > +  /* We may not be able to open the file (not available). */
> > +  if (st.symtab->fullname)
> >    ui_out_field_string (uiout, "fullname", st.symtab->fullname);
> > +
> > +  return MI_CMD_DONE;
> > +}
> > +
> > +enum mi_cmd_result
> > +mi_cmd_file_list_exec_source_files (char *command, char **argv, int argc)
> > +{
> > +  struct symtab *s;
> > +  struct partial_symtab *ps;
> > +  struct objfile *objfile;
> > +
> > +  if (!mi_valid_noargs ("mi_cmd_file_list_exec_source_files", argc, argv))
> > +    error ("mi_cmd_file_list_exec_source_files: Usage: No args");
> > +
> > +  /* Print the table header */
> > +  ui_out_begin (uiout, ui_out_type_list, "files");
> > +
> > +  /* Look at all of the symtabs */
> > +  ALL_SYMTABS (objfile, s)
> > +  {
> > +    ui_out_begin (uiout, ui_out_type_tuple, NULL);
> > +
> > +    ui_out_field_string (uiout, "file", s->filename);
> > +
> > +    /* Extract the fullname if it is not known yet */
> > +    symtab_to_fullname (s);
> > +
> > +    if (s->fullname)
> > +      ui_out_field_string (uiout, "fullname", s->fullname);
> > +
> > +    ui_out_end (uiout, ui_out_type_tuple);
> > +  }
> > +
> > +  /* Look at all of the psymtabs */
> > +  ALL_PSYMTABS (objfile, ps)
> > +  {
> > +    if (!ps->readin)
> > +      {
> > +	ui_out_begin (uiout, ui_out_type_tuple, NULL);
> > +
> > +	ui_out_field_string (uiout, "file", ps->filename);
> > +
> > +	/* Extract the fullname if it is not known yet */
> > +	psymtab_to_fullname (ps);
> > +
> > +	if (ps->fullname)
> > +	  ui_out_field_string (uiout, "fullname", ps->fullname);
> > +
> > +	ui_out_end (uiout, ui_out_type_tuple);
> > +      }
> > +  }
> > +
> > +  ui_out_end (uiout, ui_out_type_list);
> >  
> >    return MI_CMD_DONE;
> >  }
> > Index: gdb/mi/mi-cmds.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/mi/mi-cmds.c,v
> > retrieving revision 1.14
> > diff -w -u -r1.14 mi-cmds.c
> > --- gdb/mi/mi-cmds.c	4 Aug 2003 23:18:50 -0000	1.14
> > +++ gdb/mi/mi-cmds.c	26 Apr 2004 23:55:26 -0000
> > @@ -81,7 +81,7 @@
> >    { "file-exec-file", { "exec-file", 1 }, NULL, NULL },
> >    { "file-list-exec-sections", { NULL, 0 }, NULL, NULL },
> >    { "file-list-exec-source-file", { NULL, 0 }, 0, mi_cmd_file_list_exec_source_file},
> > -  { "file-list-exec-source-files", { NULL, 0 }, NULL, NULL },
> > +  { "file-list-exec-source-files", { NULL, 0 }, NULL, mi_cmd_file_list_exec_source_files },
> >    { "file-list-shared-libraries", { NULL, 0 }, NULL, NULL },
> >    { "file-list-symbol-files", { NULL, 0 }, NULL, NULL },
> >    { "file-symbol-file", { "symbol-file", 1 }, NULL, NULL },
> > Index: gdb/mi/mi-cmds.h
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/mi/mi-cmds.h,v
> > retrieving revision 1.12
> > diff -w -u -r1.12 mi-cmds.h
> > --- gdb/mi/mi-cmds.h	24 Jan 2004 04:21:43 -0000	1.12
> > +++ gdb/mi/mi-cmds.h	26 Apr 2004 23:55:26 -0000
> > @@ -87,6 +87,7 @@
> >  extern mi_cmd_args_ftype mi_cmd_exec_until;
> >  extern mi_cmd_args_ftype mi_cmd_exec_interrupt;
> >  extern mi_cmd_argv_ftype mi_cmd_file_list_exec_source_file;
> > +extern mi_cmd_argv_ftype mi_cmd_file_list_exec_source_files;
> >  extern mi_cmd_argv_ftype mi_cmd_gdb_exit;
> >  extern mi_cmd_argv_ftype mi_cmd_interpreter_exec;
> >  extern mi_cmd_argv_ftype mi_cmd_stack_info_depth;
> > Index: gdb/testsuite/gdb.mi/mi2-file.exp
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi2-file.exp,v
> > retrieving revision 1.1
> > diff -w -u -r1.1 mi2-file.exp
> > --- gdb/testsuite/gdb.mi/mi2-file.exp	7 Aug 2003 17:47:42 -0000	1.1
> > +++ gdb/testsuite/gdb.mi/mi2-file.exp	26 Apr 2004 23:55:27 -0000
> > @@ -47,7 +47,7 @@
> >  mi_gdb_reinitialize_dir $srcdir/$subdir
> >  mi_gdb_load ${binfile}
> >  
> > -proc test_tbreak_creation_and_listing {} {
> > +proc test_file_list_exec_source_file {} {
> >      global srcfile
> >      global srcdir
> >      global subdir
> > @@ -59,7 +59,17 @@
> >                 "request path info of current source file (${srcfile})"
> >  }
> >  
> > -test_tbreak_creation_and_listing
> > +proc test_file_list_exec_source_files {} {
> > +    global srcfile
> > +
> > +    # get the path and absolute path to the current executable
> > +    mi_gdb_test "222-file-list-exec-source-files" \
> > +	    "222\\\^done,files=\\\[\{file=\".*/${srcfile}\",fullname=\"/.*/${srcfile}\"\},\{file=\".*\"\},\{file=\".*\"\},\{file=\".*\"\},\{file=\".*\"\}\\\]" \
> > +              "Getting a list of source files."
> > +}
> > +
> > +test_file_list_exec_source_file
> > +test_file_list_exec_source_files
> >  
> >  mi_gdb_exit
> >  return 0

Re: -file-list-exec-source-files

[Eli Zaretskii]

> Date: Fri, 21 May 2004 21:52:50 -0400
> From: Bob Rossi <bob@brasko.net>
> 
> OK, I just finished ripping down the ceiling and walls in my kitchen.
> Is there any chance my patch got reviewed in that time? There's an
> outstanding bet between my wife and I that I will be able to completely
> renovate my kitchen before this patch gets reviewed.
> 
> What does that say about the GDB patch review process?!?
> 
> Can I *even* get a response from someone capable of committing this
> patch? 
> 
> Someone with authority, pleeeaaassseeeee help me. 

I've reviewed your patch 2 weeks ago and approved the patch to
gdb.texinfo.  I also okayed the other parts of your patch, but the
final approval should come from developers who are responsible for the
MI stuff: Andrew Cagney and Elena Zannoni (according to the
MAINTAINERS file).

Re: -file-list-exec-source-files

[Eli Zaretskii]

> Date: Fri, 21 May 2004 21:52:50 -0400
> From: Bob Rossi <bob@brasko.net>
> 
> OK, I just finished ripping down the ceiling and walls in my kitchen.
> Is there any chance my patch got reviewed in that time? There's an
> outstanding bet between my wife and I that I will be able to completely
> renovate my kitchen before this patch gets reviewed.
> 
> What does that say about the GDB patch review process?!?
> 
> Can I *even* get a response from someone capable of committing this
> patch? 
> 
> Someone with authority, pleeeaaassseeeee help me. 

I've reviewed your patch 2 weeks ago and approved the patch to
gdb.texinfo.  I also okayed the other parts of your patch, but the
final approval should come from developers who are responsible for the
MI stuff: Andrew Cagney and Elena Zannoni (according to the
MAINTAINERS file).

Re: -file-list-exec-source-files

[Bob Rossi]

On Sun, May 23, 2004 at 01:46:09PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 21 May 2004 21:52:50 -0400
> > From: Bob Rossi <bob@brasko.net>
> > 
> > OK, I just finished ripping down the ceiling and walls in my kitchen.
> > Is there any chance my patch got reviewed in that time? There's an
> > outstanding bet between my wife and I that I will be able to completely
> > renovate my kitchen before this patch gets reviewed.
> > 
> > What does that say about the GDB patch review process?!?
> > 
> > Can I *even* get a response from someone capable of committing this
> > patch? 
> > 
> > Someone with authority, pleeeaaassseeeee help me. 
> 
> I've reviewed your patch 2 weeks ago and approved the patch to
> gdb.texinfo.  I also okayed the other parts of your patch, but the
> final approval should come from developers who are responsible for the
> MI stuff: 

Thank you very much Eli.

>Andrew Cagney and Elena Zannoni (according to the MAINTAINERS file).

Andrew or Elena, could you please approve this?

Thanks,
Bob Rossi

Re: -file-list-exec-source-files

[Bob Rossi]

On Sun, May 23, 2004 at 09:35:42PM -0400, Bob Rossi wrote:
> On Sun, May 23, 2004 at 01:46:09PM +0200, Eli Zaretskii wrote:
> > > Date: Fri, 21 May 2004 21:52:50 -0400
> > > From: Bob Rossi <bob@brasko.net>
> > > 
> > > OK, I just finished ripping down the ceiling and walls in my kitchen.
> > > Is there any chance my patch got reviewed in that time? There's an
> > > outstanding bet between my wife and I that I will be able to completely
> > > renovate my kitchen before this patch gets reviewed.
> > > 
> > > What does that say about the GDB patch review process?!?
> > > 
> > > Can I *even* get a response from someone capable of committing this
> > > patch? 
> > > 
> > > Someone with authority, pleeeaaassseeeee help me. 
> > 
> > I've reviewed your patch 2 weeks ago and approved the patch to
> > gdb.texinfo.  I also okayed the other parts of your patch, but the
> > final approval should come from developers who are responsible for the
> > MI stuff: 
> 
> Thank you very much Eli.
> 
> >Andrew Cagney and Elena Zannoni (according to the MAINTAINERS file).
> 
> Andrew or Elena, could you please approve this?

Andrew or Elena, It's been over 3 months since I got a reasonable 
response from either of you regarding this patch.

I get the feeling you are ignoring me, am I correct?

Thanks,
Bob Rossi

Re: -file-list-exec-source-files

[Elena Zannoni]

 > > > +      pst->dirname = xstrdup ( comp_unit_die.dirname );
 > > > +

Forgot this bit.

otherwise ok


 

Re: -file-list-exec-source-files

[Bob Rossi]

On Tue, Jun 01, 2004 at 12:00:39PM -0400, Elena Zannoni wrote:
> 
>  > > > +      pst->dirname = xstrdup ( comp_unit_die.dirname );
>  > > > +
> 
> Forgot this bit.

Is this the bit you are talking about?

The dwarf2 specs say that the name is in the form ":pathname" or
"hostname:pathname". Should we worry about the hostname? Does gcc emit
that?  I have looked at a few executables and didn't see the hostname
part.

Would you like me to try to take into account the 
hostname:dirname? Is the hostname allowed to have a ':' in it?

> otherwise ok

Great! Thanks Elena.

Bob Rossi

Re: -file-list-exec-source-files

[Jason Molenda]

On Jun 1, 2004, at 11:01 AM, Bob Rossi wrote:

> On Tue, Jun 01, 2004 at 12:00:39PM -0400, Elena Zannoni wrote:
>>
>>>>> +      pst->dirname = xstrdup ( comp_unit_die.dirname );
>>>>> +
>>
>> Forgot this bit.
>
> Is this the bit you are talking about?

I'd wager Elena was talking about the spaces inside the parentheses.


> The dwarf2 specs say that the name is in the form ":pathname" or
> "hostname:pathname". Should we worry about the hostname? Does gcc emit
> that?  I have looked at a few executables and didn't see the hostname
> part.

After arguing that this was a stupid standard on gdb-patches :-) I made 
some snarky comment about it on the dwarf2 mailing list and was 
informed that there do exist compilers that emit hostname:pathname.  
I'd have to dig up the e-mails to find it, but I think the SGI compiler 
was an example of one.

I'm not arguing that your patch needs to handle this; this hasn't been 
properly handled in gdb until now so it's not a regression.

Jason

Re: -file-list-exec-source-files

[Bob Rossi]

On Tue, Jun 01, 2004 at 11:55:50AM -0700, Jason Molenda wrote:
> 
> On Jun 1, 2004, at 11:01 AM, Bob Rossi wrote:
> 
> >On Tue, Jun 01, 2004 at 12:00:39PM -0400, Elena Zannoni wrote:
> >>
> >>>>>+      pst->dirname = xstrdup ( comp_unit_die.dirname );
> >>>>>+
> >>
> >>Forgot this bit.
> >
> >Is this the bit you are talking about?
> 
> I'd wager Elena was talking about the spaces inside the parentheses.
> 
> 
> >The dwarf2 specs say that the name is in the form ":pathname" or
> >"hostname:pathname". Should we worry about the hostname? Does gcc emit
> >that?  I have looked at a few executables and didn't see the hostname
> >part.
> 
> After arguing that this was a stupid standard on gdb-patches :-) I made 
> some snarky comment about it on the dwarf2 mailing list and was 
> informed that there do exist compilers that emit hostname:pathname.  
> I'd have to dig up the e-mails to find it, but I think the SGI compiler 
> was an example of one.
> 
> I'm not arguing that your patch needs to handle this; this hasn't been 
> properly handled in gdb until now so it's not a regression.

Ok, Elena, I am going to commit this with the whitespace changes.
Please let me know if this wasn't your intention.

Thanks,
Bob Rossi

Re: -file-list-exec-source-files

[Elena Zannoni]

Bob Rossi writes:
 > 
 > The dwarf2 specs say that the name is in the form ":pathname" or
 > "hostname:pathname". Should we worry about the hostname? Does gcc emit
 > that?  I have looked at a few executables and didn't see the hostname
 > part.
 > 
 > Would you like me to try to take into account the 
 > hostname:dirname? Is the hostname allowed to have a ':' in it?
 > 

Oh, no. Just the formatting. 

elena

Re: -file-list-exec-source-files

[Bob Rossi]

On Wed, Jun 02, 2004 at 03:13:24PM -0400, Elena Zannoni wrote:
> Bob Rossi writes:
>  > 
>  > The dwarf2 specs say that the name is in the form ":pathname" or
>  > "hostname:pathname". Should we worry about the hostname? Does gcc emit
>  > that?  I have looked at a few executables and didn't see the hostname
>  > part.
>  > 
>  > Would you like me to try to take into account the 
>  > hostname:dirname? Is the hostname allowed to have a ':' in it?
>  > 
> 
> Oh, no. Just the formatting. 

Ok, I'll commit it as soon as I get the chance.

Thanks,
Bob Rossi

Re: -file-list-exec-source-files

[Bob Rossi]

On Wed, Jun 02, 2004 at 10:35:22PM -0400, Bob Rossi wrote:
> On Wed, Jun 02, 2004 at 03:13:24PM -0400, Elena Zannoni wrote:
> > Bob Rossi writes:
> >  > 
> >  > The dwarf2 specs say that the name is in the form ":pathname" or
> >  > "hostname:pathname". Should we worry about the hostname? Does gcc emit
> >  > that?  I have looked at a few executables and didn't see the hostname
> >  > part.
> >  > 
> >  > Would you like me to try to take into account the 
> >  > hostname:dirname? Is the hostname allowed to have a ':' in it?
> >  > 
> > 
> > Oh, no. Just the formatting. 
> 
> Ok, I'll commit it as soon as I get the chance.

Ok, I had to make one small change to dwarf2read.c, it was
   pst->dirname = xstrdup (comp_unit_die.dirname);
it now is
   if (comp_unit_die.dirname)
     pst->dirname = xstrdup (comp_unit_die.dirname);

This fixed a crash in the testsuite.


Also, I changed both mi-file.exp and mi2-file.exp from
   global srcfile
   global srcdir
   global subdir
   set srcfilepath [string_to_regexp ${srcdir}/${subdir}/${srcfile}]

   "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=...

to
   "111\\\^done,line=\"23\",file=\".*/${srcfile}\",fullname=...

This had nothing to do with this patch. The testcase was failing with a
clean checkout and run of the testsuite.

Is this OK to commit? If so, I will do it today.

Thanks,
Bob Rossi
   

Re: -file-list-exec-source-files

[Daniel Jacobowitz]

On Wed, Jun 09, 2004 at 02:18:11PM -0400, Bob Rossi wrote:
> Ok, I had to make one small change to dwarf2read.c, it was
>    pst->dirname = xstrdup (comp_unit_die.dirname);
> it now is
>    if (comp_unit_die.dirname)
>      pst->dirname = xstrdup (comp_unit_die.dirname);
> 
> This fixed a crash in the testsuite.

This sounds OK.

> Also, I changed both mi-file.exp and mi2-file.exp from
>    global srcfile
>    global srcdir
>    global subdir
>    set srcfilepath [string_to_regexp ${srcdir}/${subdir}/${srcfile}]
> 
>    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=...
> 
> to
>    "111\\\^done,line=\"23\",file=\".*/${srcfile}\",fullname=...
> 
> This had nothing to do with this patch. The testcase was failing with a
> clean checkout and run of the testsuite.

This is not.  The reason it's failing for you is probably that you
configured in the source directory or using a relative path, right?  Is
it still needed if you configure using an absolute path
(mkdir objdir; cd objdir; /path/to/configure && make && make check) ?

-- 
Daniel Jacobowitz

Re: -file-list-exec-source-files

[Bob Rossi]

On Wed, Jun 09, 2004 at 02:42:12PM -0400, Daniel Jacobowitz wrote:
> On Wed, Jun 09, 2004 at 02:18:11PM -0400, Bob Rossi wrote:
> > Ok, I had to make one small change to dwarf2read.c, it was
> >    pst->dirname = xstrdup (comp_unit_die.dirname);
> > it now is
> >    if (comp_unit_die.dirname)
> >      pst->dirname = xstrdup (comp_unit_die.dirname);
> > 
> > This fixed a crash in the testsuite.
> 
> This sounds OK.

OK.

> > Also, I changed both mi-file.exp and mi2-file.exp from
> >    global srcfile
> >    global srcdir
> >    global subdir
> >    set srcfilepath [string_to_regexp ${srcdir}/${subdir}/${srcfile}]
> > 
> >    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=...
> > 
> > to
> >    "111\\\^done,line=\"23\",file=\".*/${srcfile}\",fullname=...
> > 
> > This had nothing to do with this patch. The testcase was failing with a
> > clean checkout and run of the testsuite.
> 
> This is not.  The reason it's failing for you is probably that you
> configured in the source directory or using a relative path, right?  Is
> it still needed if you configure using an absolute path
> (mkdir objdir; cd objdir; /path/to/configure && make && make check) ?

You seem to be correct here. I will not make this change.
So otherwise, I'm good to go?

Thanks,
Bob Rossi

Re: -file-list-exec-source-files

[Daniel Jacobowitz]

On Wed, Jun 09, 2004 at 03:17:47PM -0400, Bob Rossi wrote:
> On Wed, Jun 09, 2004 at 02:42:12PM -0400, Daniel Jacobowitz wrote:
> > On Wed, Jun 09, 2004 at 02:18:11PM -0400, Bob Rossi wrote:
> > > Ok, I had to make one small change to dwarf2read.c, it was
> > >    pst->dirname = xstrdup (comp_unit_die.dirname);
> > > it now is
> > >    if (comp_unit_die.dirname)
> > >      pst->dirname = xstrdup (comp_unit_die.dirname);
> > > 
> > > This fixed a crash in the testsuite.
> > 
> > This sounds OK.
> 
> OK.
> 
> > > Also, I changed both mi-file.exp and mi2-file.exp from
> > >    global srcfile
> > >    global srcdir
> > >    global subdir
> > >    set srcfilepath [string_to_regexp ${srcdir}/${subdir}/${srcfile}]
> > > 
> > >    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=...
> > > 
> > > to
> > >    "111\\\^done,line=\"23\",file=\".*/${srcfile}\",fullname=...
> > > 
> > > This had nothing to do with this patch. The testcase was failing with a
> > > clean checkout and run of the testsuite.
> > 
> > This is not.  The reason it's failing for you is probably that you
> > configured in the source directory or using a relative path, right?  Is
> > it still needed if you configure using an absolute path
> > (mkdir objdir; cd objdir; /path/to/configure && make && make check) ?
> 
> You seem to be correct here. I will not make this change.
> So otherwise, I'm good to go?

I think so.

-- 
Daniel Jacobowitz

Re: -file-list-exec-source-files

[Bob Rossi]

On Wed, Jun 09, 2004 at 03:57:39PM -0400, Daniel Jacobowitz wrote:
> On Wed, Jun 09, 2004 at 03:17:47PM -0400, Bob Rossi wrote:
> > On Wed, Jun 09, 2004 at 02:42:12PM -0400, Daniel Jacobowitz wrote:
> > > On Wed, Jun 09, 2004 at 02:18:11PM -0400, Bob Rossi wrote:
> > > > Ok, I had to make one small change to dwarf2read.c, it was
> > > >    pst->dirname = xstrdup (comp_unit_die.dirname);
> > > > it now is
> > > >    if (comp_unit_die.dirname)
> > > >      pst->dirname = xstrdup (comp_unit_die.dirname);
> > > > 
> > > > This fixed a crash in the testsuite.
> > > 
> > > This sounds OK.
> > 
> > OK.
> > 
> > > > Also, I changed both mi-file.exp and mi2-file.exp from
> > > >    global srcfile
> > > >    global srcdir
> > > >    global subdir
> > > >    set srcfilepath [string_to_regexp ${srcdir}/${subdir}/${srcfile}]
> > > > 
> > > >    "111\\\^done,line=\"23\",file=\"${srcfilepath}\",fullname=...
> > > > 
> > > > to
> > > >    "111\\\^done,line=\"23\",file=\".*/${srcfile}\",fullname=...
> > > > 
> > > > This had nothing to do with this patch. The testcase was failing with a
> > > > clean checkout and run of the testsuite.
> > > 
> > > This is not.  The reason it's failing for you is probably that you
> > > configured in the source directory or using a relative path, right?  Is
> > > it still needed if you configure using an absolute path
> > > (mkdir objdir; cd objdir; /path/to/configure && make && make check) ?
> > 
> > You seem to be correct here. I will not make this change.
> > So otherwise, I'm good to go?
> 
> I think so.

Committed, thanks.

Bob Rossi

Re: -file-list-exec-source-files

[Andreas Schwab]

Bob Rossi <bob@brasko.net> writes:

> +/* Finds the fullname that a symtab represents.
> +
> +   If this functions finds the fullname, it will save it in ps->fullname
> +   and it will also return the value.
>  
> +   If this function fails to find the file that this symtab represents,
> +   NULL will be returned and ps->fullname will be set to NULL.  */

This causes gdb to crash in lookup_symtab.

    if (full_path != NULL)
      {
	const char *fp = symtab_to_fullname (s);
	if (FILENAME_CMP (full_path, fp) == 0)
	  {
	    return s;
	  }
      }

    if (real_path != NULL)
      {
	char *rp = gdb_realpath (symtab_to_fullname (s));
        make_cleanup (xfree, rp);
	if (FILENAME_CMP (real_path, rp) == 0)
	  {
	    return s;
	  }
      }

Neither of these places expect symtab_to_fullname to return NULL.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: -file-list-exec-source-files

[Bob Rossi]

On Sun, Jun 27, 2004 at 08:06:13PM +0200, Andreas Schwab wrote:
> Bob Rossi <bob@brasko.net> writes:
> 
> > +/* Finds the fullname that a symtab represents.
> > +
> > +   If this functions finds the fullname, it will save it in ps->fullname
> > +   and it will also return the value.
> >  
> > +   If this function fails to find the file that this symtab represents,
> > +   NULL will be returned and ps->fullname will be set to NULL.  */
> 
> This causes gdb to crash in lookup_symtab.
> 
>     if (full_path != NULL)
>       {
> 	const char *fp = symtab_to_fullname (s);
> 	if (FILENAME_CMP (full_path, fp) == 0)
> 	  {
> 	    return s;
> 	  }
>       }
> 
>     if (real_path != NULL)
>       {
> 	char *rp = gdb_realpath (symtab_to_fullname (s));
>         make_cleanup (xfree, rp);
> 	if (FILENAME_CMP (real_path, rp) == 0)
> 	  {
> 	    return s;
> 	  }
>       }
> 
> Neither of these places expect symtab_to_fullname to return NULL.

Is that repeatable with a small example?
I'd be happy to take a look at it.

Bob Rossi

Re: -file-list-exec-source-files

[Andreas Schwab]

Bob Rossi <bob@brasko.net> writes:

> Is that repeatable with a small example?

I get loads of testsuite errors on ia64-linux.  For example, it crashes
after gdb_run_cmd in gdb.base/dbx.exp:test_assign.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: -file-list-exec-source-files

[Bob Rossi]

On Sun, Jun 27, 2004 at 08:06:13PM +0200, Andreas Schwab wrote:
> Bob Rossi <bob@brasko.net> writes:
> 
> > +/* Finds the fullname that a symtab represents.
> > +
> > +   If this functions finds the fullname, it will save it in ps->fullname
> > +   and it will also return the value.
> >  
> > +   If this function fails to find the file that this symtab represents,
> > +   NULL will be returned and ps->fullname will be set to NULL.  */
> 
> This causes gdb to crash in lookup_symtab.
> 
>     if (full_path != NULL)
>       {
> 	const char *fp = symtab_to_fullname (s);
> 	if (FILENAME_CMP (full_path, fp) == 0)
> 	  {
> 	    return s;
> 	  }
>       }
> 
>     if (real_path != NULL)
>       {
> 	char *rp = gdb_realpath (symtab_to_fullname (s));
>         make_cleanup (xfree, rp);
> 	if (FILENAME_CMP (real_path, rp) == 0)
> 	  {
> 	    return s;
> 	  }
>       }
> 
> Neither of these places expect symtab_to_fullname to return NULL.

I will have a simple patch for this within the next few hours.

Thanks,
Bob Rossi

Re: -file-list-exec-source-files

[Bob Rossi]

On Sun, Jun 27, 2004 at 08:06:13PM +0200, Andreas Schwab wrote:
> Bob Rossi <bob@brasko.net> writes:
> 
> > +/* Finds the fullname that a symtab represents.
> > +
> > +   If this functions finds the fullname, it will save it in ps->fullname
> > +   and it will also return the value.
> >  
> > +   If this function fails to find the file that this symtab represents,
> > +   NULL will be returned and ps->fullname will be set to NULL.  */
> 
> This causes gdb to crash in lookup_symtab.
> 
>     if (full_path != NULL)
>       {
> 	const char *fp = symtab_to_fullname (s);
> 	if (FILENAME_CMP (full_path, fp) == 0)
> 	  {
> 	    return s;
> 	  }
>       }
> 
>     if (real_path != NULL)
>       {
> 	char *rp = gdb_realpath (symtab_to_fullname (s));
>         make_cleanup (xfree, rp);
> 	if (FILENAME_CMP (real_path, rp) == 0)
> 	  {
> 	    return s;
> 	  }
>       }

The patch below checks symtab_to_fullname's return value against NULL.
Even though this is the "trivial" fix, I believe it is the correct
patch. When I added these calls recently, I blindly changed the old call
to symtab_to_fullname, and the old call did not return NULL.

Permission to apply?

2004-06-28  Bob Rossi  <bob@brasko.net>

    * symtab.c (lookup_symtab): check return value of symtab_to_fullname
    
Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.133
diff -w -u -r1.133 symtab.c
--- symtab.c    18 Jun 2004 21:36:15 -0000  1.133
+++ symtab.c    28 Jun 2004 20:36:18 -0000
@@ -182,7 +182,7 @@
     if (full_path != NULL)
       {
    const char *fp = symtab_to_fullname (s);
-   if (FILENAME_CMP (full_path, fp) == 0)
+   if (fp != NULL && FILENAME_CMP (full_path, fp) == 0)
      {
        return s;
      }
@@ -190,7 +190,10 @@

     if (real_path != NULL)
       {
-   char *rp = gdb_realpath (symtab_to_fullname (s));
+   char *fullname = symtab_to_fullname (s);
+   if (fullname != NULL)
+     {
+       char *rp = gdb_realpath (fullname);
         make_cleanup (xfree, rp);
    if (FILENAME_CMP (real_path, rp) == 0)
      {
@@ -198,6 +201,7 @@
      }
       }
   }
+  }

   /* Now, search for a matching tail (only if name doesn't have any dirs) */

Re: -file-list-exec-source-files

[Eli Zaretskii]

> Date: Mon, 28 Jun 2004 16:40:31 -0400
> From: Bob Rossi <bob@brasko.net>
> 
> The patch below checks symtab_to_fullname's return value against NULL.
> Even though this is the "trivial" fix, I believe it is the correct
> patch. When I added these calls recently, I blindly changed the old call
> to symtab_to_fullname, and the old call did not return NULL.
> 
> Permission to apply?

This patch is okay with me.

Re: -file-list-exec-source-files

[Bob Rossi]

On Tue, Jun 29, 2004 at 07:00:34AM +0200, Eli Zaretskii wrote:
> > Date: Mon, 28 Jun 2004 16:40:31 -0400
> > From: Bob Rossi <bob@brasko.net>
> > 
> > The patch below checks symtab_to_fullname's return value against NULL.
> > Even though this is the "trivial" fix, I believe it is the correct
> > patch. When I added these calls recently, I blindly changed the old call
> > to symtab_to_fullname, and the old call did not return NULL.
> > 
> > Permission to apply?
> 
> This patch is okay with me.

Am I OK to commit?

Thanks,
Bob Rossi

Re: -file-list-exec-source-files

[Eli Zaretskii]

> Date: Tue, 29 Jun 2004 14:34:11 -0400
> From: Bob Rossi <bob@brasko.net>
> > > 
> > > Permission to apply?
> > 
> > This patch is okay with me.
> 
> Am I OK to commit?

That's what I said, didn't I? ;-)

Re: -file-list-exec-source-files

[Bob Rossi]

On Tue, Jun 29, 2004 at 09:44:44PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 29 Jun 2004 14:34:11 -0400
> > From: Bob Rossi <bob@brasko.net>
> > > > 
> > > > Permission to apply?
> > > 
> > > This patch is okay with me.
> > 
> > Am I OK to commit?
> 
> That's what I said, didn't I? ;-)

Well, "this patch is okay with me" and "permission to commit" could mean
two different things, especially since I've been told that only Elena or
Jim have permission to approve this.

Honestly, I have no idea how things work here, as far as patch approval
is concerned, and I never want to commit a patch without the appropriate
permissions.

But I'm assuming you are saying it's OK to commit.

Thanks,
Bob Rossi

Re: -file-list-exec-source-files

[Eli Zaretskii]

> Date: Tue, 29 Jun 2004 16:08:51 -0400
> From: Bob Rossi <bob@brasko.net>
> 
> Well, "this patch is okay with me" and "permission to commit" could mean
> two different things

Sorry, I thought it was clear what I meant.

Re: -file-list-exec-source-files

[Bob Rossi]

On Tue, Jun 29, 2004 at 11:22:16PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 29 Jun 2004 16:08:51 -0400
> > From: Bob Rossi <bob@brasko.net>
> > 
> > Well, "this patch is okay with me" and "permission to commit" could mean
> > two different things
> 
> Sorry, I thought it was clear what I meant.

Thanks Eli, I will commit this tonight.

Bob Rossi