Final separate debug info patch

Final separate debug info patch

[Alexander Larsson]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 806 bytes --]

After a few iterations I stopped getting comments, so I guess this patch 
is mature now. I forward ported the patch to cvs HEAD, so this should be 
fine to go in.

The docs changes are approved by Eli, and Daniel Jacobowitz promised to 
handle the test suite changes if this goes in.

The patch doesn't have any autoconf-generated changes in it, because I 
don't have the exact same version of autoconf that gdb seems to use.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl@redhat.com    alla@lysator.liu.se 
He's an unconventional zombie gangster on a mission from God. She's a 
provocative tempestuous former first lady who dreams of becoming Elvis. They 
fight crime! 

[-- Attachment #2: Type: TEXT/PLAIN, Size: 19013 bytes --]

Index: gdb/acconfig.h
===================================================================
RCS file: /cvs/src/src/gdb/acconfig.h,v
retrieving revision 1.18
diff -u -p -r1.18 acconfig.h
--- gdb/acconfig.h	11 Apr 2002 18:32:51 -0000	1.18
+++ gdb/acconfig.h	9 Oct 2002 08:21:16 -0000
@@ -176,3 +176,7 @@
 
 /* nativefile */
 #undef GDB_NM_FILE
+
+/* debugdir */
+#undef DEBUGDIR
+
Index: gdb/acinclude.m4
===================================================================
RCS file: /cvs/src/src/gdb/acinclude.m4,v
retrieving revision 1.4
diff -u -p -r1.4 acinclude.m4
--- gdb/acinclude.m4	20 Sep 2002 00:24:01 -0000	1.4
+++ gdb/acinclude.m4	9 Oct 2002 08:21:16 -0000
@@ -1044,3 +1044,18 @@ size_t iconv();
   fi
   AC_SUBST(LIBICONV)
 ])
+
+dnl written by Guido Draheim <guidod@gmx.de>, original by Alexandre Oliva 
+dnl Version 1.3 (2001/03/02)
+dnl source http://www.gnu.org/software/ac-archive/Miscellaneous/ac_define_dir.html
+
+AC_DEFUN([AC_DEFINE_DIR], [
+  test "x$prefix" = xNONE && prefix="$ac_default_prefix"
+  test "x$exec_prefix" = xNONE && exec_prefix='${prefix}'
+  ac_define_dir=`eval echo [$]$2`
+  ac_define_dir=`eval echo [$]ac_define_dir`
+  ifelse($3, ,
+    AC_DEFINE_UNQUOTED($1, "$ac_define_dir"),
+    AC_DEFINE_UNQUOTED($1, "$ac_define_dir", $3))
+])
+
Index: gdb/configure.in
===================================================================
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.91
diff -u -p -r1.91 configure.in
--- gdb/configure.in	20 Sep 2002 00:24:01 -0000	1.91
+++ gdb/configure.in	9 Oct 2002 08:21:18 -0000
@@ -237,6 +237,14 @@ fi
 AC_CHECK_LIB(socket, socketpair)
 AC_CHECK_FUNCS(socketpair)
 
+debugdir=${libdir}/debug
+	 
+AC_ARG_WITH(separate-debug-dir,
+[  --with-separate-debug-dir=path   Look for global separate debug info in this path [LIBDIR/debug]],
+[debugdir="${withval}"])
+	
+AC_DEFINE_DIR(DEBUGDIR, debugdir)
+#AC_DEFINE_UNQUOTED(DEBUGDIR, "$debugdir"),
 
 BFD_NEED_DECLARATION(malloc)
 BFD_NEED_DECLARATION(realloc)
Index: gdb/defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.99
diff -u -p -r1.99 defs.h
--- gdb/defs.h	27 Sep 2002 22:08:51 -0000	1.99
+++ gdb/defs.h	9 Oct 2002 08:21:18 -0000
@@ -385,6 +385,8 @@ extern void *address_to_host_pointer (CO
 extern char *gdb_realpath (const char *);
 extern char *xfullpath (const char *);
 
+extern unsigned long calc_crc32 (unsigned long crc, unsigned char *buf, size_t len);
+
 /* From demangle.c */
 
 extern void set_demangling_style (char *);
Index: gdb/objfiles.c
===================================================================
RCS file: /cvs/src/src/gdb/objfiles.c,v
retrieving revision 1.22
diff -u -p -r1.22 objfiles.c
--- gdb/objfiles.c	29 Jul 2002 22:55:26 -0000	1.22
+++ gdb/objfiles.c	9 Oct 2002 08:21:18 -0000
@@ -333,6 +333,30 @@ allocate_objfile (bfd *abfd, int flags)
   return (objfile);
 }
 
+/* Put one object file before a specified on in the global list.
+   This can be used to make sure an object file is destroyed before
+   another when using ALL_OBJFILES_SAFE to free all objfiles. */
+void
+put_objfile_before (struct objfile *objfile, struct objfile *before_this)
+{
+  struct objfile **objp;
+
+  unlink_objfile (objfile);
+  
+  for (objp = &object_files; *objp != NULL; objp = &((*objp)->next))
+    {
+      if (*objp == before_this)
+	{
+	  objfile->next = *objp;
+	  *objp = objfile;
+	  return;
+	}
+    }
+  
+  internal_error (__FILE__, __LINE__,
+		  "put_objfile_before: before objfile not in list");
+}
+
 /* Put OBJFILE at the front of the list.  */
 
 void
@@ -405,6 +429,18 @@ unlink_objfile (struct objfile *objfile)
 void
 free_objfile (struct objfile *objfile)
 {
+  if (objfile->separate_debug_objfile)
+    {
+      free_objfile (objfile->separate_debug_objfile);
+    }
+  
+  if (objfile->separate_debug_objfile_backlink)
+    {
+      /* We freed the separate debug file, make sure the base objfile
+	 doesn't reference it.  */
+      objfile->separate_debug_objfile_backlink->separate_debug_objfile = NULL;
+    }
+  
   /* First do any symbol file specific actions required when we are
      finished with a particular symbol file.  Note that if the objfile
      is using reusable symbol information (via mmalloc) then each of
Index: gdb/objfiles.h
===================================================================
RCS file: /cvs/src/src/gdb/objfiles.h,v
retrieving revision 1.15
diff -u -p -r1.15 objfiles.h
--- gdb/objfiles.h	5 Aug 2002 16:17:41 -0000	1.15
+++ gdb/objfiles.h	9 Oct 2002 08:21:18 -0000
@@ -414,6 +414,15 @@ struct objfile
     ExportEntry *export_list;
     int export_list_size;
 
+    /* Link to objfile that contains the debug symbols for this one.
+       One is loaded if this file has an debug link to an existing
+       debug file with the right checksum */
+    struct objfile *separate_debug_objfile;
+
+    /* If this is a separate debug object, this is used as a link to the
+       actual executable objfile. */
+    struct objfile *separate_debug_objfile_backlink;
+    
     /* Place to stash various statistics about this objfile */
       OBJSTATS;
   };
@@ -504,6 +513,8 @@ extern struct objfile *object_files;
 extern struct objfile *allocate_objfile (bfd *, int);
 
 extern int build_objfile_section_table (struct objfile *);
+
+extern void put_objfile_before (struct objfile *, struct objfile *);
 
 extern void objfile_to_front (struct objfile *);
 
Index: gdb/symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.69
diff -u -p -r1.69 symfile.c
--- gdb/symfile.c	20 Sep 2002 14:58:58 -0000	1.69
+++ gdb/symfile.c	9 Oct 2002 08:21:19 -0000
@@ -38,6 +38,7 @@
 #include "complaints.h"
 #include "demangle.h"
 #include "inferior.h"		/* for write_pc */
+#include "filenames.h"		/* for DOSish file names */
 #include "gdb-stabs.h"
 #include "gdb_obstack.h"
 #include "completer.h"
@@ -147,6 +148,8 @@ static void set_ext_lang_command (char *
 
 static void info_ext_lang_command (char *args, int from_tty);
 
+static char *find_separate_debug_file (struct objfile *objfile, const char *name);
+
 static void init_filename_language_table (void);
 
 void _initialize_symfile (void);
@@ -826,7 +829,12 @@ symbol_file_add (char *name, int from_tt
 {
   struct objfile *objfile;
   struct partial_symtab *psymtab;
+  char *debugfile;
   bfd *abfd;
+  struct section_addr_info orig_addrs;
+  
+  if (addrs)
+    orig_addrs = *addrs;
 
   /* Open a bfd for the file, and give user a chance to burp if we'd be
      interactively wiping out any existing symbols.  */
@@ -919,6 +927,28 @@ symbol_file_add (char *name, int from_tt
   if (target_new_objfile_hook)
     target_new_objfile_hook (objfile);
 
+  debugfile = find_separate_debug_file (objfile, name);
+  if (debugfile)
+    {
+      printf_filtered ("loading separate debug info from '%s'\n", debugfile);
+
+      if (addrs != NULL)
+	{
+	  objfile->separate_debug_objfile = symbol_file_add (debugfile, from_tty, &orig_addrs, 0, flags);
+	}
+      else
+	{
+	  objfile->separate_debug_objfile = symbol_file_add (debugfile, from_tty, NULL, 0, flags);
+	}
+      objfile->separate_debug_objfile->separate_debug_objfile_backlink = objfile;
+      
+      /* Put the separate debug object before the normal one, this is so that
+         usage of the ALL_OBJFILES_SAFE macro will stay safe. */
+      put_objfile_before (objfile->separate_debug_objfile, objfile);
+      
+      xfree (debugfile);
+    }
+  
   return (objfile);
 }
 
@@ -978,6 +1008,145 @@ symbol_file_clear (int from_tty)
 #endif
 }
 
+static char *
+get_debug_link_info (struct objfile *objfile, unsigned long *crc32_out)
+{
+  asection *sect;
+  bfd_size_type debuglink_size;
+  unsigned long crc32;
+  char *contents;
+  int crc_offset;
+  unsigned char *crc_data;
+  unsigned char *p;
+  
+  sect = bfd_get_section_by_name (objfile->obfd, ".gnu_debuglink");
+
+  if (sect == NULL)
+    return NULL;
+
+  debuglink_size = bfd_section_size (objfile->obfd, sect);
+  
+  contents = xmalloc (debuglink_size);
+  bfd_get_section_contents (objfile->obfd, sect, contents,
+			    (file_ptr)0, (bfd_size_type)debuglink_size);
+
+  /* Crc value is stored after the filename, aligned up to 4 bytes. */
+  crc_offset = strlen (contents) + 1;
+  if (crc_offset & 3)
+    crc_offset += 4 - (crc_offset & 3);
+  crc_data = contents + crc_offset;
+
+  crc32 = 0;
+  if (TARGET_BYTE_ORDER == BFD_ENDIAN_BIG)
+    {
+      for (p = crc_data; p < crc_data + 4; ++p)
+	crc32 = (crc32 << 8) | *p;
+    }
+  else
+    {
+      for (p = crc_data + 4 - 1; p >= crc_data; --p)
+	crc32 = (crc32 << 8) | *p;
+    }
+  
+  *crc32_out = crc32;
+  return contents;
+}
+
+static int
+separate_debug_file_exists (const char *name, unsigned long crc)
+{
+  unsigned long file_crc = 0;
+  int fd;
+  char buffer[8*1024];
+  int count;
+
+  fd = open (name, O_RDONLY | O_BINARY);
+  if (fd < 0)
+    return 0;
+
+  while ((count = read (fd, buffer, sizeof (buffer))) > 0)
+    file_crc = calc_crc32 (file_crc, buffer, count);
+
+  close (fd);
+
+  return crc == file_crc;
+}
+
+static char *debug_file_directory = NULL;
+
+static char *
+find_separate_debug_file (struct objfile *objfile, const char *name)
+{
+  asection *sect;
+  char *basename;
+  char *dir;
+  char *debugfile;
+  char *name_copy;
+  bfd_size_type debuglink_size;
+  unsigned long crc32;
+  int i;
+
+  basename = get_debug_link_info (objfile, &crc32);
+
+  if (basename == NULL)
+    return NULL;
+  
+  dir = xstrdup (name);
+
+  /* Strip off filename part */
+  for (i = strlen(dir) - 1; i >= 0; i--)
+    {
+      if (IS_DIR_SEPARATOR (dir[i]))
+	break;
+    }
+  dir[i+1] = '\0';
+  
+  debugfile = alloca (strlen (debug_file_directory) + 1 +
+		      strlen (dir) + strlen (".debug/") + strlen (basename) + 1);
+
+  /* First try in the same directory as the original file: */
+  strcpy (debugfile, dir);
+  strcat (debugfile, basename);
+
+  if (separate_debug_file_exists (debugfile, crc32))
+    {
+      xfree (basename);
+      xfree (dir);
+      return xstrdup (debugfile);
+    }
+  
+  /* Then try in a subdirectory called .debug */
+  strcpy (debugfile, dir);
+  strcat (debugfile, ".debug/");
+  strcat (debugfile, basename);
+
+  if (separate_debug_file_exists (debugfile, crc32))
+    {
+      xfree (basename);
+      xfree (dir);
+      return xstrdup (debugfile);
+    }
+  
+  /* Then try in the global debugfile directory */
+  strcpy (debugfile, debug_file_directory);
+  strcat (debugfile, "/");
+  strcat (debugfile, dir);
+  strcat (debugfile, "/");
+  strcat (debugfile, basename);
+
+  if (separate_debug_file_exists (debugfile, crc32))
+    {
+      xfree (basename);
+      xfree (dir);
+      return xstrdup (debugfile);
+    }
+  
+  xfree (basename);
+  xfree (dir);
+  return NULL;
+}
+
+
 /* This is the symbol-file command.  Read the file, analyze its
    symbols, and add a struct symtab to a symtab list.  The syntax of
    the command is rather bizarre--(1) buildargv implements various
@@ -1637,6 +1806,8 @@ reread_symbols (void)
   long new_modtime;
   int reread_one = 0;
   struct stat new_statbuf;
+  char *debug_file;
+  unsigned long crc32;
   int res;
 
   /* With the addition of shared libraries, this should be modified,
@@ -1823,6 +1994,27 @@ reread_symbols (void)
 	         needs to keep track of (such as _sigtramp, or whatever).  */
 
 	      TARGET_SYMFILE_POSTREAD (objfile);
+
+	      /* Verify the checksum of a previously loaded separate debug file. */
+	      if (objfile->separate_debug_objfile)
+		{
+		  debug_file = get_debug_link_info (objfile, &crc32);
+		  if (debug_file)
+		    {
+		      if (!separate_debug_file_exists (objfile->separate_debug_objfile->name, crc32))
+			{
+			  /* The old separate debug symbols file is invalid */
+			  free_objfile (objfile->separate_debug_objfile);
+			}
+		      xfree (debug_file);
+		    }
+		  else
+		    {
+		      /* No more debug link, kill old separate debug symbols */
+		      free_objfile (objfile->separate_debug_objfile);
+		    }
+		}
+	      
 	    }
 	}
     }
@@ -3337,4 +3529,17 @@ Usage: set extension-language .foo bar",
 		  "cache.\n",
 		  &setlist),
      &showlist);
+
+  debug_file_directory = xstrdup (DEBUGDIR);
+  c = add_set_cmd ("debug-file-directory", class_support, var_string,
+		   (char *) &debug_file_directory,
+		   "Set the directory where separate debug symbols are searched for.\n"
+		   "Separate debug symbols are first searched for in the same\n"
+		   "directory as the binary, then in the .debug subdirectory,\n"
+		   "and lastly at the path of the directory of the binary with\n"
+		   "the global debug-file directory prepended\n",
+		   &setlist);
+  add_show_from_set (c, &showlist);
+  set_cmd_completer (c, filename_completer);
+
 }
Index: gdb/utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.80
diff -u -p -r1.80 utils.c
--- gdb/utils.c	20 Sep 2002 00:24:01 -0000	1.80
+++ gdb/utils.c	9 Oct 2002 08:21:19 -0000
@@ -2728,3 +2728,69 @@ xfullpath (const char *filename)
   xfree (real_path);
   return result;
 }
+
+unsigned long
+calc_crc32 (unsigned long crc, unsigned char *buf, size_t len)
+{
+  static const unsigned long crc32_table[256] =
+    {
+      0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419,
+      0x706af48f, 0xe963a535, 0x9e6495a3, 0x0edb8832, 0x79dcb8a4,
+      0xe0d5e91e, 0x97d2d988, 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07,
+      0x90bf1d91, 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
+      0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7, 0x136c9856,
+      0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, 0x14015c4f, 0x63066cd9,
+      0xfa0f3d63, 0x8d080df5, 0x3b6e20c8, 0x4c69105e, 0xd56041e4,
+      0xa2677172, 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
+      0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940, 0x32d86ce3,
+      0x45df5c75, 0xdcd60dcf, 0xabd13d59, 0x26d930ac, 0x51de003a,
+      0xc8d75180, 0xbfd06116, 0x21b4f4b5, 0x56b3c423, 0xcfba9599,
+      0xb8bda50f, 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
+      0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, 0x76dc4190,
+      0x01db7106, 0x98d220bc, 0xefd5102a, 0x71b18589, 0x06b6b51f,
+      0x9fbfe4a5, 0xe8b8d433, 0x7807c9a2, 0x0f00f934, 0x9609a88e,
+      0xe10e9818, 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
+      0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e, 0x6c0695ed,
+      0x1b01a57b, 0x8208f4c1, 0xf50fc457, 0x65b0d9c6, 0x12b7e950,
+      0x8bbeb8ea, 0xfcb9887c, 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3,
+      0xfbd44c65, 0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
+      0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb, 0x4369e96a,
+      0x346ed9fc, 0xad678846, 0xda60b8d0, 0x44042d73, 0x33031de5,
+      0xaa0a4c5f, 0xdd0d7cc9, 0x5005713c, 0x270241aa, 0xbe0b1010,
+      0xc90c2086, 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
+      0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, 0x59b33d17,
+      0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad, 0xedb88320, 0x9abfb3b6,
+      0x03b6e20c, 0x74b1d29a, 0xead54739, 0x9dd277af, 0x04db2615,
+      0x73dc1683, 0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
+      0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1, 0xf00f9344,
+      0x8708a3d2, 0x1e01f268, 0x6906c2fe, 0xf762575d, 0x806567cb,
+      0x196c3671, 0x6e6b06e7, 0xfed41b76, 0x89d32be0, 0x10da7a5a,
+      0x67dd4acc, 0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
+      0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252, 0xd1bb67f1,
+      0xa6bc5767, 0x3fb506dd, 0x48b2364b, 0xd80d2bda, 0xaf0a1b4c,
+      0x36034af6, 0x41047a60, 0xdf60efc3, 0xa867df55, 0x316e8eef,
+      0x4669be79, 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
+      0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f, 0xc5ba3bbe,
+      0xb2bd0b28, 0x2bb45a92, 0x5cb36a04, 0xc2d7ffa7, 0xb5d0cf31,
+      0x2cd99e8b, 0x5bdeae1d, 0x9b64c2b0, 0xec63f226, 0x756aa39c,
+      0x026d930a, 0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
+      0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38, 0x92d28e9b,
+      0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21, 0x86d3d2d4, 0xf1d4e242,
+      0x68ddb3f8, 0x1fda836e, 0x81be16cd, 0xf6b9265b, 0x6fb077e1,
+      0x18b74777, 0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c,
+      0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45, 0xa00ae278,
+      0xd70dd2ee, 0x4e048354, 0x3903b3c2, 0xa7672661, 0xd06016f7,
+      0x4969474d, 0x3e6e77db, 0xaed16a4a, 0xd9d65adc, 0x40df0b66,
+      0x37d83bf0, 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
+      0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6, 0xbad03605,
+      0xcdd70693, 0x54de5729, 0x23d967bf, 0xb3667a2e, 0xc4614ab8,
+      0x5d681b02, 0x2a6f2b94, 0xb40bbe37, 0xc30c8ea1, 0x5a05df1b,
+      0x2d02ef8d
+    };
+  unsigned char *end;
+
+  crc = ~crc & 0xffffffff;
+  for (end = buf + len; buf < end; ++buf)
+    crc = crc32_table[(crc ^ *buf) & 0xff] ^ (crc >> 8);
+  return ~crc & 0xffffffff;;
+}
Index: gdb/doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.130
diff -u -p -r1.130 gdb.texinfo
--- gdb/doc/gdb.texinfo	3 Oct 2002 05:56:40 -0000	1.130
+++ gdb/doc/gdb.texinfo	9 Oct 2002 08:21:24 -0000
@@ -10206,6 +10206,29 @@ Mb).
 Display the current autoloading size threshold, in megabytes.
 @end table
 
+On @sc{elf} based systems, @value{GDBN} supports automatically loading
+symbol tables and debug information from a file separate from the
+executable.  This works by putting information in the executable about
+the name and checksum of the file with debug information.  When
+@value{GDBN} reads such an executable it automatically tries to locate
+the debug file and load it. 
+
+@value{GDBN} searchs for the file first in the same directory as the
+executable, and then in a subdirectory called @file{.debug}. 
+If both these fail @value{GDBN} looks in the global debug directory, with the
+full pathname of the executable.  So if you are loading
+@file{/usr/bin/ls} and it references the debug file @file{ls.debug}
+@value{GDBN} will look for @file{usr/bin/ls.debug} in the global debug
+directory.
+
+@table @code
+@kindex set debug-file-directory
+@item set debug-file-directory @var{directory}
+Set the global directory where @value{GDBN} searches for separate
+debug files to @var{directory}.
+@end table
+
+
 @node Symbol Errors
 @section Errors reading symbol files
 

Re: Final separate debug info patch

[Jim Blandy]

It looks like the stripping process may break some executables.  If $D
is the top directory of a current GDB source tree, try this:

$ g++ --version
g++ (GCC) 3.3 20020820 (experimental)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++ -g $D/gdb/testsuite/gdb.c++/try_catch.cc -o try_catch
$ ./try_catch
$ /home/jimb/elfutils/bin/strip -f try_catch.separate-debug try_catch
$ ./try_catch
Segmentation fault
$ 

I found this by running the GDB test suite, configured to strip the
debug info of every executable it creates to a separate file.  If
you'd like to try it, here's how I did it:

First, I created a file $DEJAGNU/boards/unix-separate-debug.exp, which
contains the following:

    load_base_board_description "unix"

    set strip_to_file_program "/home/jimb/elfutils/bin/strip"

    proc ${current_target_name}_compile {source dest type options} {
        global strip_to_file_program

        # Run the standard compilation procedure.
        set result [default_target_compile $source $dest $type $options]

        # If it didn't succeed, return directly.
        if {[string compare $result ""] != 0} {
            return $result
        }

        puts "jimb: stripping to a separate file..."

        # Otherwise, strip the executable and copy its debug info to a
        # separate file, leaving only a pointer behind.
        if {[string compare $type executable] == 0} {
            exec $strip_to_file_program -f ${dest}.separate-debug ${dest}
        }
    }

This defines a new target, "unix-separate-debug", which is just like
"unix" except that it extracts the debug info of each executable the
test suite builds to a separate file.  Adjust `strip_to_file_program'
as needed, of course.

Then, I use the following target list in my $DEJAGNU file:

    set target_list {
        unix-sdi
        unix
    }

So the effect is to:
- run all the tests once with separate debug info, and then
- run all the tests again with the normal debug info arrangement.

This makes it easy to see if the patch has any effect on the tests.

There are some problems at the moment: DejaGNU has the name "unix"
hard-coded into it, and thinks that anything with another name is a
remote board.  Some tests won't run if the target is remote.  I think
I know how to persuade it that unix-separate-debug is still not a
remote target, but I'm just going to post this as is for the time
being.

Re: Final separate debug info patch

[Daniel Jacobowitz]

On Tue, Nov 19, 2002 at 12:04:02AM -0500, Jim Blandy wrote:
> There are some problems at the moment: DejaGNU has the name "unix"
> hard-coded into it, and thinks that anything with another name is a
> remote board.  Some tests won't run if the target is remote.  I think
> I know how to persuade it that unix-separate-debug is still not a
> remote target, but I'm just going to post this as is for the time
> being.

FYI, I do this.  Here's how.  This is a simple board description file
which just uses a different C compiler, since GDB wasn't honoring CC:

<quote>
# The canonical unix board description.
load_generic_config "unix";

set_board_info compiler  "gcc-3.2";
set_board_info c++compiler  "g++-3.2";

global board
proc ${board}_init { whole_name } {
  global board_info
  set board_info(unix3.2,isremote) 0;
}
</quote>

Replace unix3.2 with whatever goes before the .exp.  The ${board} bit
is necessary and becomes something involving the local hostname, IIRC.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Final separate debug info patch

[Jim Blandy]

Is there any particular reason that the elfutils `strip -f' throws
away all but the last component of the filenames given to it?

$ /home/jimb/elfutils/bin/strip -f `pwd`/foon call-rt-st
$ objdump -s -j .gnu_debuglink call-rt-st

call-rt-st:     file format elf32-i386

Contents of section .gnu_debuglink:
 0000 666f6f6e 00000000 f74a8703           foon.....J..    
$ 

It seems to me that strip should preserve the filename given in its -f
argument.  Let consumers of the .gnu_debuglink section decide for
themselves what to do with it.

Then, I think if the filename in the .gnu_debuglink section is
absolute, GDB should try that path instead of searching in the
directory containing the stripped file.  Or it should at least try it
at some point.

We have a test in the GDB test suite that copies its executable to
/tmp.  It would be nice if we didn't have to add special support to
that test case to copy over the debug info, too.  If the filename in
.gnu_debuglink were absolute, and if GDB were to respect that, this
would work transparently.

Re: Final separate debug info patch

[Alexander Larsson]

On 19 Nov 2002, Jim Blandy wrote:

> 
> It looks like the stripping process may break some executables.  If $D
> is the top directory of a current GDB source tree, try this:
> 
> $ g++ --version
> g++ (GCC) 3.3 20020820 (experimental)
> Copyright (C) 2002 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> $ g++ -g $D/gdb/testsuite/gdb.c++/try_catch.cc -o try_catch
> $ ./try_catch
> $ /home/jimb/elfutils/bin/strip -f try_catch.separate-debug try_catch
> $ ./try_catch
> Segmentation fault
> $ 

This doesn't happen for me with gdb from cvs HEAD and gcc (GCC) 3.2 
20020903 (Red Hat Linux 8.0 3.2-7). Does it happen if you just run strip 
without the -f flag? It might well be a bug in the new strip command.

> So the effect is to:
> - run all the tests once with separate debug info, and then
> - run all the tests again with the normal debug info arrangement.
> 
> This makes it easy to see if the patch has any effect on the tests.

Thats cool.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl@redhat.com    alla@lysator.liu.se 
He's a superhumanly strong alcoholic grifter who hides his scarred face behind 
a mask. She's a time-travelling antique-collecting Hell's Angel with a knack 
for trouble. They fight crime! 

Re: Final separate debug info patch

[Alexander Larsson]

On 19 Nov 2002, Jim Blandy wrote:

> Is there any particular reason that the elfutils `strip -f' throws
> away all but the last component of the filenames given to it?

None in particular. I just didn't need the full pathname with the 
search-method i used in the gdb patch.
 
> $ /home/jimb/elfutils/bin/strip -f `pwd`/foon call-rt-st
> $ objdump -s -j .gnu_debuglink call-rt-st
> 
> call-rt-st:     file format elf32-i386
> 
> Contents of section .gnu_debuglink:
>  0000 666f6f6e 00000000 f74a8703           foon.....J..    
> $ 
> 
> It seems to me that strip should preserve the filename given in its -f
> argument.  Let consumers of the .gnu_debuglink section decide for
> themselves what to do with it.
> 
> Then, I think if the filename in the .gnu_debuglink section is
> absolute, GDB should try that path instead of searching in the
> directory containing the stripped file.  Or it should at least try it
> at some point.

That makes sense to me. Uli? Is this ok with you?
 
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl@redhat.com    alla@lysator.liu.se 
He's a superhumanly strong Jewish romance novelist who must take medication to 
keep him sane. She's a mistrustful hypochondriac bodyguard from a family of 
eight older brothers. They fight crime! 

Re: Final separate debug info patch

[Ulrich Drepper]

Alexander Larsson wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> That makes sense to me. Uli? Is this ok with you?

I don't know.  I imagine that strip is used like this in the build root
for the distribution.  By preserving the entire path lots on unusable
information is leaked and distributed.  This is true for many situations.

Unless somebody can provide a really good reason why the entire path is
needed I rather not change anything.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE92fAR2ijCOnn/RHQRArMvAJ4xl1l2FqC/roZi/QN+fMKg7HcJ5ACgggmx
6r1JCMJCH2RXhB26sPi2y24=
=BBVY
-----END PGP SIGNATURE-----

Re: Final separate debug info patch

[Jim Blandy]

Alexander Larsson <alexl@redhat.com> writes:
> On 19 Nov 2002, Jim Blandy wrote:
> 
> > 
> > It looks like the stripping process may break some executables.  If $D
> > is the top directory of a current GDB source tree, try this:
> > 
> > $ g++ --version
> > g++ (GCC) 3.3 20020820 (experimental)
> > Copyright (C) 2002 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> > 
> > $ g++ -g $D/gdb/testsuite/gdb.c++/try_catch.cc -o try_catch
> > $ ./try_catch
> > $ /home/jimb/elfutils/bin/strip -f try_catch.separate-debug try_catch
> > $ ./try_catch
> > Segmentation fault
> > $ 
> 
> This doesn't happen for me with gdb from cvs HEAD and gcc (GCC) 3.2 
> 20020903 (Red Hat Linux 8.0 3.2-7). Does it happen if you just run strip 
> without the -f flag? It might well be a bug in the new strip
> command.

Yeah, it seems to be:

zenia:separate-debug$ g++ -g $D/gdb/testsuite/gdb.c++/try_catch.cc -o try_catch
zenia:separate-debug$ ./try_catch
zenia:separate-debug$ /home/jimb/elfutils/bin/strip try_catch
zenia:separate-debug$ ./try_catch
Segmentation fault
zenia:separate-debug$ 

This is happening with a pretty motley collection of utilities, so I'm
not sure I can show how to reproduce it.  If you could try running the
GDB test suite on your box with the stuff I've provided, that would be
nice.

Here's the latest iteration of my unix-separate-debug.exp file:

---
load_base_board_description "unix"

set strip_to_file_program "/home/jimb/elfutils/bin/strip"

proc ${current_target_name}_compile {source dest type options} {
    global strip_to_file_program

    # Run the standard compilation procedure.
    set result [default_target_compile $source $dest $type $options]

    # If it didn't succeed, return directly.
    if {[string compare $result ""] != 0} {
        return $result
    }

    # Otherwise, strip the executable and copy its debug info to a
    # separate file, leaving only a pointer behind.
    if {[string compare $type executable] == 0} {
        exec $strip_to_file_program -f ${dest}.separate-debug ${dest}
    }
}

# "unix" is a magic target name to is_remote, so since we're not named
# "unix", we have to spell some stuff out.

# We can't just call set_board_info here, since 
# 1) that doesn't strip off variant information, and 
# 2) it won't override the default guess established by setup_target_hook.

set board_info([lindex [split $board "/"] 0],isremote) 0
---

See if you can get that working.  There is a regression in reread.exp,
and you can ignore everything in schedlock.exp.  But you may find
something that tweaks the problem on your system.

My stripped program seems to be crashing in _dl_map_object_deps...

Re: Final separate debug info patch

[Jim Blandy]

Ulrich Drepper <drepper@redhat.com> writes:

> Alexander Larsson wrote:
> 
> > That makes sense to me. Uli? Is this ok with you?
> 
> I don't know.  I imagine that strip is used like this in the build root
> for the distribution.  By preserving the entire path lots on unusable
> information is leaked and distributed.  This is true for many situations.
> 
> Unless somebody can provide a really good reason why the entire path is
> needed I rather not change anything.

Well, my motivating case is a GDB test script that copies the
executable elsewhere.  At the moment, I can just override the
compilation procedure in the target board file and run the entire GDB
test suite against separated executables without modifying any of the
test scripts.  Except for this one test.  Now, if strip kept an
absolute path when it was given one, and GDB used it, then copying the
executable wouldn't hurt, and everything would just work.

If people don't want to include absolute paths, they don't have to
give one to strip, it seems to me.  Strip preserving what it's given
doesn't take away anyone's choices.

But I admit this isn't the most compelling use case one could imagine.

Re: Final separate debug info patch

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Tue, Nov 19, 2002 at 12:04:02AM -0500, Jim Blandy wrote:
> > There are some problems at the moment: DejaGNU has the name "unix"
> > hard-coded into it, and thinks that anything with another name is a
> > remote board.  Some tests won't run if the target is remote.  I think
> > I know how to persuade it that unix-separate-debug is still not a
> > remote target, but I'm just going to post this as is for the time
> > being.
> 
> FYI, I do this.  Here's how.  This is a simple board description file
> which just uses a different C compiler, since GDB wasn't honoring CC:
> 
> <quote>
> # The canonical unix board description.
> load_generic_config "unix";
> 
> set_board_info compiler  "gcc-3.2";
> set_board_info c++compiler  "g++-3.2";
> 
> global board
> proc ${board}_init { whole_name } {
>   global board_info
>   set board_info(unix3.2,isremote) 0;
> }
> </quote>
> 
> Replace unix3.2 with whatever goes before the .exp.  The ${board} bit
> is necessary and becomes something involving the local hostname, IIRC.

Okay --- that works.  Here's the latest iteration:

---
load_base_board_description "unix"

set strip_to_file_program "/home/jimb/elfutils/bin/strip"

proc ${current_target_name}_compile {source dest type options} {
    global strip_to_file_program

    # Run the standard compilation procedure.
    set result [default_target_compile $source $dest $type $options]

    # If it didn't succeed, return directly.
    if {[string compare $result ""] != 0} {
        return $result
    }

    # Otherwise, strip the executable and copy its debug info to a
    # separate file, leaving only a pointer behind.
    if {[string compare $type executable] == 0} {
        exec $strip_to_file_program -f ${dest}.separate-debug ${dest}
    }
}

proc ${board}_init { whole_name } {
    global board_info
    set board_info(unix-separate-debug,isremote) 0
}

Re: Final separate debug info patch

[Alexander Larsson]

On 19 Nov 2002, Jim Blandy wrote:

> 
> Ulrich Drepper <drepper@redhat.com> writes:
> 
> > Alexander Larsson wrote:
> > 
> > > That makes sense to me. Uli? Is this ok with you?
> > 
> > I don't know.  I imagine that strip is used like this in the build root
> > for the distribution.  By preserving the entire path lots on unusable
> > information is leaked and distributed.  This is true for many situations.
> > 
> > Unless somebody can provide a really good reason why the entire path is
> > needed I rather not change anything.
> 
> Well, my motivating case is a GDB test script that copies the
> executable elsewhere.  At the moment, I can just override the
> compilation procedure in the target board file and run the entire GDB
> test suite against separated executables without modifying any of the
> test scripts.  Except for this one test.  Now, if strip kept an
> absolute path when it was given one, and GDB used it, then copying the
> executable wouldn't hurt, and everything would just work.
> 
> If people don't want to include absolute paths, they don't have to
> give one to strip, it seems to me.  Strip preserving what it's given
> doesn't take away anyone's choices.

When i'm building in the build system i will always be using absolute 
paths to put the files in the right place. For instance for /usr/bin/app 
it will do -f $RPM_BUILD_ROOT/usr/lib/debug/usr/bin/app.debug. So we will 
leak some strange absolute paths. Of course, if gdb used the basename 
when searching the global directories that wouldn't affect the result, but 
it is sort of ugly.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl@redhat.com    alla@lysator.liu.se 
He's an uncontrollable flyboy messiah in a wheelchair. She's a mentally 
unstable gypsy queen of the dead with an evil twin sister. They fight crime! 

Re: Final separate debug info patch

[Alexander Larsson]

On 19 Nov 2002, Jim Blandy wrote:

> Alexander Larsson <alexl@redhat.com> writes:
> > On 19 Nov 2002, Jim Blandy wrote:
> > 
> > > 
> > > It looks like the stripping process may break some executables.  If $D
> > > is the top directory of a current GDB source tree, try this:
> > > 
> > > $ g++ --version
> > > g++ (GCC) 3.3 20020820 (experimental)
> > > Copyright (C) 2002 Free Software Foundation, Inc.
> > > This is free software; see the source for copying conditions.  There is NO
> > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> > > 
> > > $ g++ -g $D/gdb/testsuite/gdb.c++/try_catch.cc -o try_catch
> > > $ ./try_catch
> > > $ /home/jimb/elfutils/bin/strip -f try_catch.separate-debug try_catch
> > > $ ./try_catch
> > > Segmentation fault
> > > $ 
> > 
> > This doesn't happen for me with gdb from cvs HEAD and gcc (GCC) 3.2 
> > 20020903 (Red Hat Linux 8.0 3.2-7). Does it happen if you just run strip 
> > without the -f flag? It might well be a bug in the new strip
> > command.
> 
> Yeah, it seems to be:
> 
> zenia:separate-debug$ g++ -g $D/gdb/testsuite/gdb.c++/try_catch.cc -o try_catch
> zenia:separate-debug$ ./try_catch
> zenia:separate-debug$ /home/jimb/elfutils/bin/strip try_catch
> zenia:separate-debug$ ./try_catch
> Segmentation fault
> zenia:separate-debug$ 
> 
> This is happening with a pretty motley collection of utilities, so I'm
> not sure I can show how to reproduce it.  If you could try running the
> GDB test suite on your box with the stuff I've provided, that would be
> nice.
>
> My stripped program seems to be crashing in _dl_map_object_deps...
> 

I don't have gdb built at the moment, so I can't run the test suite. Could 
you just send me the try_catch binary and i'll have a look at it.


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl@redhat.com    alla@lysator.liu.se 
He's an ungodly soccer-playing messiah with a robot buddy named Sparky. She's 
a radical extravagent mercenary with only herself to blame. They fight crime! 

Re: Final separate debug info patch

[Jim Blandy]

Alexander Larsson <alexl@redhat.com> writes:
> On 19 Nov 2002, Jim Blandy wrote:
> 
> > 
> > Ulrich Drepper <drepper@redhat.com> writes:
> > 
> > > Alexander Larsson wrote:
> > > 
> > > > That makes sense to me. Uli? Is this ok with you?
> > > 
> > > I don't know.  I imagine that strip is used like this in the build root
> > > for the distribution.  By preserving the entire path lots on unusable
> > > information is leaked and distributed.  This is true for many situations.
> > > 
> > > Unless somebody can provide a really good reason why the entire path is
> > > needed I rather not change anything.
> > 
> > Well, my motivating case is a GDB test script that copies the
> > executable elsewhere.  At the moment, I can just override the
> > compilation procedure in the target board file and run the entire GDB
> > test suite against separated executables without modifying any of the
> > test scripts.  Except for this one test.  Now, if strip kept an
> > absolute path when it was given one, and GDB used it, then copying the
> > executable wouldn't hurt, and everything would just work.
> > 
> > If people don't want to include absolute paths, they don't have to
> > give one to strip, it seems to me.  Strip preserving what it's given
> > doesn't take away anyone's choices.
> 
> When i'm building in the build system i will always be using absolute 
> paths to put the files in the right place. For instance for /usr/bin/app 
> it will do -f $RPM_BUILD_ROOT/usr/lib/debug/usr/bin/app.debug. So we will 
> leak some strange absolute paths. Of course, if gdb used the basename 
> when searching the global directories that wouldn't affect the result, but 
> it is sort of ugly.

I see.  I'm fine with leaving the behavior as it is.

Re: Final separate debug info patch

[Jim Blandy]

Some other stuff I've noticed:

- In reread_symbols, it looks like we do throw away
  objfile->separate_debug_objfile if it doesn't match any more, but I
  don't see where we read in the new one.  (I think this is the cause
  of the reread.exp failure.)

- Similarly, if we start with an unseparated objfile, but then it is
  changed to a separated objfile, I don't see where reread_symbols
  loads the separated objfile's debug objfile.

- In reread_symbols, if the new objfile's debug link has a different
  name, but the CRC's happen to match, it won't toss the old file.  It
  seems to me that we should re-run find_separate_debug_file from
  scratch, and make sure the filename we get matches the existing
  separate_debug_objfile's name.

In general, I'm not convinced that the change to reread_symbols really
covers all the cases.  I'll try to fix it.

Re: Final separate debug info patch

[Alexander Larsson]

On Tue, 19 Nov 2002, Alexander Larsson wrote:

> On 19 Nov 2002, Jim Blandy wrote:
> 
> > Alexander Larsson <alexl@redhat.com> writes:
> > > On 19 Nov 2002, Jim Blandy wrote:
> > > 
> > > > 
> > > > It looks like the stripping process may break some executables.  If $D
> > > > is the top directory of a current GDB source tree, try this:
> > > > 
> > > > $ g++ --version
> > > > g++ (GCC) 3.3 20020820 (experimental)
> > > > Copyright (C) 2002 Free Software Foundation, Inc.
> > > > This is free software; see the source for copying conditions.  There is NO
> > > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> > > > 
> > > > $ g++ -g $D/gdb/testsuite/gdb.c++/try_catch.cc -o try_catch
> > > > $ ./try_catch
> > > > $ /home/jimb/elfutils/bin/strip -f try_catch.separate-debug try_catch
> > > > $ ./try_catch
> > > > Segmentation fault
> > > > $ 
> > > 
> > > This doesn't happen for me with gdb from cvs HEAD and gcc (GCC) 3.2 
> > > 20020903 (Red Hat Linux 8.0 3.2-7). Does it happen if you just run strip 
> > > without the -f flag? It might well be a bug in the new strip
> > > command.
> > 
> > Yeah, it seems to be:
> > 
> > zenia:separate-debug$ g++ -g $D/gdb/testsuite/gdb.c++/try_catch.cc -o try_catch
> > zenia:separate-debug$ ./try_catch
> > zenia:separate-debug$ /home/jimb/elfutils/bin/strip try_catch
> > zenia:separate-debug$ ./try_catch
> > Segmentation fault
> > zenia:separate-debug$ 
> > 
> > This is happening with a pretty motley collection of utilities, so I'm
> > not sure I can show how to reproduce it.  If you could try running the
> > GDB test suite on your box with the stuff I've provided, that would be
> > nice.
> >
> > My stripped program seems to be crashing in _dl_map_object_deps...
> > 
> 
> I don't have gdb built at the moment, so I can't run the test suite. Could 
> you just send me the try_catch binary and i'll have a look at it.

Can you send me the binary?

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl@redhat.com    alla@lysator.liu.se 
He's a maverick ninja jungle king who hangs with the wrong crowd. She's a 
time-travelling cat-loving femme fatale with a knack for trouble. They fight 
crime! 

Re: Final separate debug info patch

[Jim Blandy]

Alexander Larsson <alexl@redhat.com> writes:
> > I don't have gdb built at the moment, so I can't run the test suite. Could 
> > you just send me the try_catch binary and i'll have a look at it.
> 
> Can you send me the binary?

Yes, sorry:

begin 644 try_catch
M?T5,1@$!`0````````````(``P`!`````(D$"#0````0%````````#0`(``'
M`"@`'0`<``8````T````-(`$"#2`!`C@````X`````4````$`````P```!0!
M```4@00(%($$"!,````3````!`````$````!``````````"`!`@`@`0(<`\`
M`'`/```%`````!````$`````$````)`$"`"0!`@T`@``V`(```8`````$```
M`@```/00``#TD`0(])`$".````#@````!@````0````$````*`$``"B!!`@H
M@00((````"`````$````!````%#E=&1$#P``1(\$"$2/!`@L````+`````0`
M```$````+VQI8B]L9"UL:6YU>"YS;RXR```$````$`````$```!'3E4`````
M``(````"````!0```!$````=````%`````\`````````&0```!$````,````
M%P```!8`````````&@````0`````````&P```!@````*````'````!4`````
M``````````````````````````$````%````````````````````````````
M```)```````````````+`````````!`````'`````P`````````"````$@``
M`!,````&````"`````T`````````#@````````````````````````#/`0``
M#(@$"/,````2````*0```!R(!`@%````$@```$T!```LB`0(9@```!(````0
M````,(\$"!0````A``X`-@```!F/!`@5````(0`.`*X`````````"````!$`
M``""````/(@$""H````2````>````$R(!`A.````$@```.@!``!<B`0(*P``
M`!(````B`0``;(@$"'8````2````3P```#B2!`@L````(0`8`'<!``!HD@0(
M+````"$`&`!@`0``?(@$"&(````2````X````"Z-!`@S````(@`,`(D```",
MB`0(9````!(````N`0``G(@$"#X````2````F0```*R(!`AN!```$@```'\"
M``"\B`0(R@```!(```#\````F)($""P````A`!@`OP```,R(!`@%````$@``
M`*$!``"RC00(,P```"(`#`"]`0``W(@$"%L````2````9@(``.R(!`C1````
M$@```$D"``!$C@0(!````!$`#@`#`@`````````````@````%P(``&R.!`@,
M````(0`.`,P```#(D@0(#````"$`&``P`@`````````````@`````&QI8G-T
M9&,K*RYS;RXU`%]:5%93=#$V:6YV86QI9%]A<F=U;65N=`!?6DY384EC14,Q
M178`7UI44U-T,39I;G9A;&ED7V%R9W5M96YT`%]:5%9.,3!?7V-X>&%B:78Q
M,C!?7W-I7V-L87-S7W1Y<&5?:6YF;T4`7UI.4W-$,45V`%]:9&Q0=@!?7V-X
M85]E;F1?8V%T8V@`7U]G>'A?<&5R<V]N86QI='E?=C``7UI425-T.65X8V5P
M=&EO;@!?6DY384EC140Q178`7UI425-T,3%L;V=I8U]E<G)O<@!?6DY3=#$V
M:6YV86QI9%]A<F=U;65N=$0Q178`7UI45DXQ,%]?8WAX86)I=C$Q-U]?8VQA
M<W-?='EP95]I;F9O10!?7V-X85]T:')O=P!?6DY3=#$V:6YV86QI9%]A<F=U
M;65N=$,Q15)+4W,`7UI.4W-#,4502V-22U-A26-%`%]:3E-T,3%L;V=I8U]E
M<G)O<D0R178`7UI45DXQ,%]?8WAX86)I=C$R,5]?=FUI7V-L87-S7W1Y<&5?
M:6YF;T4`7UI.4W0Q-FEN=F%L:61?87)G=6UE;G1$,$5V`%]?8WAA7V)E9VEN
M7V-A=&-H`%]?8WAA7V%L;&]C871E7V5X8V5P=&EO;@!?6DY+4W0Q,6QO9VEC
M7V5R<F]R-'=H871%=@!?2G9?4F5G:7-T97)#;&%S<V5S`%]:5$E3=#$V:6YV
M86QI9%]A<F=U;65N=`!?7V=M;VY?<W1A<G1?7P!L:6)M+G-O+C8`7TE/7W-T
M9&EN7W5S960`;&EB9V-C7W,N<V\N,0!?56YW:6YD7U)E<W5M90!L:6)C+G-O
M+C8`7U]L:6)C7W-T87)T7VUA:6X`1T-#7S,N,`!'3$E"0U\R+C``1TQ)0D-0
M4%\S+C(`0UA804))7S$N,@````(``P`#```````#``,``P`#``(```````,`
M```"``,``@`$`````P````(`!0```````````````0`!`%@"```0````(```
M`%`F>0L```4`D0(````````!``$`=0(``!`````@````$&EI#0``!`"9`@``
M``````$``@`!````$`````````!R*1H(```#`*,"```0````TJ]K!0```@"O
M`@```````/"0!`@!!@``,)($"`8<```XD@0(!0L``&B2!`@%#```F)($"`43
M``#(D@0(!1L``/21!`@'`0``^)$$"`<"``#\D00(!P,```"2!`@'!P``!)($
M"`<(```(D@0(!PD```R2!`@'"@``$)($"`<-```4D@0(!P\``!B2!`@'$```
M')($"`<1```@D@0(!Q(``"22!`@'%```*)($"`<6```LD@0(!Q<``%6)Y8/L
M".@U`0``D.B;`0``Z/8%``#)P_\U[)$$"/\E\)$$"`````#_)?21!`AH````
M`.G@_____R7XD00(:`@```#IT/____\E_)$$"&@0````Z<#_____)0"2!`AH
M&````.FP_____R4$D@0(:"````#IH/____\E")($"&@H````Z9#_____)0R2
M!`AH,````.F`_____R40D@0(:#@```#I</____\E%)($"&A`````Z6#_____
M)1B2!`AH2````.E0_____R4<D@0(:%````#I0/____\E()($"&A8````Z3#_
M____)222!`AH8````.D@_____R4HD@0(:&@```#I$/____\E+)($"&AP````
MZ0#___\`````,>U>B>&#Y/!05%)H((X$"&CDAP0(459HN(D$".B;____](GV
M58GE4U#H`````%N!P[H(``"+@T@```"%P'0"_]"+7?S)PXGVD)"0D)"0D)!5
MB>6#[`B`/=22!`@`=2VA")`$"(L0A=)T&XVV`````(/`!*,(D`0(_]*A")`$
M"(L0A=)UZ\8%U)($"`')PXGV58GE@^P(H>21!`B%P'05N`````"%P'0,QP0D
MY)$$".A,=OOWB>Q=PU6)Y593@>R@````@^3PN``````IQ,9%]P''1?`%````
MQT7L!0```(U%R(D$),=$)`0$````Z*P"``"-1:B)!"3'1"0$`@```.C3`@``
MC47L_P#'!"00````Z/;]__^)PXD<),=$)`0!````QT0D".T1``#H6@,``(D<
M),=$)`3`C@0(QT0D"`````#H)/[__XF%=/___XF5</___X.]</___P-T`NLZ
MBX5T____B00DZ&_^__^)1:2-1>S_`(M%I(-X#`%T!,9%]P"+1:2!>`CM$0``
M=`3&1?<`Z/7]___K'HN%=/___XD$).@U_O__QT7L`````,9%]P#HU?W__XU%
M[/\`C47L_P"-1>S_`,<$)!````#H.OW__XG#B1PDQT0D!`$```#'1"0([1$`
M`.B>`@``B1PDQT0D!,".!`C'1"0(`````.AH_?__B85T____B95P____@[UP
M____`W0"ZSJ+A73___^)!"3HL_W__XE%I(U%[/\`BT6D@W@,`70$QD7W`(M%
MI(%X".T1``!T!,9%]P#H.?W__^L>BX5T____B00DZ'G]___'1>P`````QD7W
M`.@9_?__@WWL8P^/%0$``(V%>/___XD$).B1_/__C95X____C46(B00DQT0D
M!$B.!`B)5"0(Z(3\__^-78C'!"0(````Z%7\__^)A6S___^+A6S___^)!"2)
M7"0$Z,W\__^-18B)!"3H<OS__^LTB85T____B95P____BYUT____B[5P____
MC85X____B00DZ,K\__^)G73___^)M7#____K.(V%>/___XD$).BN_/__BX5L
M____B00DQT0D!&R.!`C'1"0(+HT$".@P_/__B85T____B95P____@[UP____
M`70.BX5T____B00DZ(W\__^+A73___^)!"3H;_S__XE%I(M%I(L0@\((BT6D
MB00DBP+_T#U(C@0(=`3&1?<`Z/K[__^X`````(UE^%M>7<-5B>6#[!B+10B#
MP`B)!"3'1"0$`````,=$)`@'````Z*````"+50BX;(X$"(D"BU4(BT4,B4($
MR<.058GE@^P(BT4(B00DQT0D!`,```#H`P```,G#D%6)Y8/L&(M%"(/`"(D$
M),=$)`0`````QT0D"`<```#H2@```(M5"+A<C@0(B0*+50B+10R)0@3)PY!5
MB>6#[`B+10C'`#B/!`B+10B)!"3H-/O__[@!````@^`"A,!T"XM%"(D$).C=
M^O__R<.058GEBT4(Q@`!BT4(QT`$!0```(M5"(M%$(E""(M5"(M%#(E"#%W#
MD%6)Y8M%",8``8M%",=`!`4```"+50B+11")0@B+50B+10R)0@Q=PY!5B>6#
M[`B+10C'`#B/!`B+10B)!"3HL/K__[@!````@^`#A,!T"XM%"(D$).A9^O__
MR<.0D)"0D)"0D)"0D%6)Y5.#[`2[U)$$"*'4D00(@_C_=!:-=@"-O"<`````
M@^L$_]"+`X/X_W7T6%M=PU6)Y5-2Z`````!;@<.^`P``C78`Z!?[__^+7?S)
MPP```P````$``@!G9&(N,0````@`````````H(X$"``````(`````````(".
M!`A`D@0(&8\$",B2!`@``````````'"2!`C]C@0("`````$```#`C@0(`_3_
M_P``````````<)($".&.!`@(`````0```,".!`@#]/__``````````"@D@0(
MR(X$"$XQ,%]?9VYU7W1E<W0Y9VYU7V]B:E\Q10!.,3!?7V=N=5]T97-T.6=N
M=5]O8FI?,DEI144`3C$P7U]G;G5?=&5S=#EG;G5?;V)J7S));$5%`%-T,39I
M;G9A;&ED7V%R9W5M96YT`````````&R.!`@NC00(LHT$"%R(!`@!&P,[Q```
M``0```!T^O__Y````%K]__\(`0``E/W__R@!``"P_?__2`$`````````````
MX)$$"!@``````````7I03``!?`@&`*R(!`@`#`0$B`$@````(````+B)!`CF
M`@``!+"0!`A!#@B%`D(-!4B#!(8#```<````1````)Z,!`@Y````!`````!!
M#@B%`D(-!0```!P```!D````V(P$"!L````$`````$$."(4"0@T%````'```
M`(0```#TC`0(.0````0`````00X(A0)"#04`````````_P!!`2LU&```BP$%
MD`$#^@$%``#'`@7,`@.V`P4``.L#!:0$!_\$!80%!:(%!0```@`#?0$``'W`
MC@0(```````````!`````0````$````_`@```0```%@"```!````=0(```P`
M``#DAP0(#0```"".!`@$````2($$"`4```#8@P0(!@````B"!`@*````N@(`
M``L````0````%0`````````#````Z)$$"`(```!X````%````!$````7````
M;(<$"!$````\AP0($@```#`````3````"````/[__V_,A@0(____;P,```#P
M__]ODH8$"```````````````````````````````````````````````````
M`````````````/____\`````_____P``````````])`$"```````````$H@$
M""*(!`@RB`0(0H@$"%*(!`ABB`0(<H@$"(*(!`B2B`0(HH@$"+*(!`C"B`0(
MTH@$".*(!`CRB`0(````````````1T-#.B`H1TY5*2`R+CDV(#(P,#`P-S,Q
M("A2960@2&%T($QI;G5X(#<N,B`R+CDV+3$P."XQ*0``1T-#.B`H1TY5*2`R
M+CDV(#(P,#`P-S,Q("A2960@2&%T($QI;G5X(#<N,B`R+CDV+3$P."XQ*0``
M1T-#.B`H1TY5*2`S+C,@,C`P,C`X,C`@*&5X<&5R:6UE;G1A;"D``$=#0SH@
M*$=.52D@,RXS(#(P,#(P.#(P("AE>'!E<FEM96YT86PI``!'0T,Z("A'3E4I
M(#,N,R`R,#`R,#@R,"`H97AP97)I;65N=&%L*0``1T-#.B`H1TY5*2`R+CDV
M(#(P,#`P-S,Q("A2960@2&%T($QI;G5X(#<N,B`R+CDV+3$P."XQ*0`(````
M``````$````P,2XP,0````@``````````0```#`Q+C`Q````"``````````!
M````,#$N,#$`````=')Y7V-A=&-H+F1E8G5G`)>.K[@`+F1A=&$`+G)O9&%T
M80`N<VAS=')T86(`+F1Y;F%M:6,`+F=C8U]E>&-E<'1?=&%B;&4`+F5H7V9R
M86UE`"YN;W1E`"YN;W1E+D%"22UT86<`+FAA<V@`+F9I;FD`+F=N=5]D96)U
M9VQI;FL`+F1Y;G-Y;0`N9VYU+G9E<G-I;VX`+G)E;"YD>6X`+FEN=&5R<``N
M9VYU+G9E<G-I;VY?<@`N:F-R`"YE:%]F<F%M95]H9'(`+F1Y;G-T<@`N8W1O
M<G,`+F1T;W)S`"YB<W,`+FEN:70`+G)E;"YP;'0`+F-O;6UE;G0`+F=O=``N
M=&5X=```````````````````````````````````````````````````````
M`(L````!`````@```!2!!`@4`0``$P```````````````0````````!$````
M!P````(````H@00(*`$``"````````````````0`````````4@````4````"
M````2($$"$@!``#`````!``````````$````!````&T````+`````@````B"
M!`@(`@``T`$```4````!````!````!````"U`````P````(```#8@P0(V`,`
M`+H"``````````````$`````````=0```/___V\"````DH8$")(&```Z````
M!``````````"`````@```),```#^__]O`@```,R&!`C,!@``<`````4````#
M````!`````````""````"0````(````\AP0(/`<``#`````$`````0````0`
M```(````U@````D````"````;(<$"&P'``!X````!`````L````$````"```
M`-`````!````!@```.2'!`CD!P``&```````````````!`````````#:````
M`0````8```#\AP0(_`<````!``````````````0````$````[0````$````&
M`````(D$"``)```@!0`````````````0`````````%@````!````!@```"".
M!`@@#@``'@``````````````!``````````'`````0````(```!`C@0(0`X`
M``0!`````````````"``````````IP````$````"````1(\$"$0/```L````
M```````````$``````````$````!`````P````"0!`AP#P``#```````````
M````!``````````T`````0````,````,D`0(?`\``*0```````````````0`
M````````(@````$````#````L)`$""`0``!$```````````````$````````
M`!D````&`````P```/20!`AD$```X`````4`````````!`````@```"]````
M`0````,```#4D00(1!$```@```````````````0`````````Q`````$````#
M````W)$$"$P1```(```````````````$`````````*(````!`````P```.21
M!`A4$0``!```````````````!`````````#H`````0````,```#HD00(6!$`
M`$P```````````````0````$````RP````@````#````.)($"*@1``"@````
M```````````(`````````-\````!``````````````"H$0``(P$`````````
M`````0`````````^````!P``````````````RQ(``#P```````````````$`
M````````7@````$```````````````@3```4```````````````$````````
I```````````````````````<$P``\P```````````````0``````````
`
end

Re: Final separate debug info patch

[Alexander Larsson]

On 21 Nov 2002, Jim Blandy wrote:

> 
> Alexander Larsson <alexl@redhat.com> writes:
> > > I don't have gdb built at the moment, so I can't run the test suite. Could 
> > > you just send me the try_catch binary and i'll have a look at it.
> > 
> > Can you send me the binary?
> 
> Yes, sorry:
> ...
> end

Oh. Thats that stripped binary. I'd like to look at the unstripped one.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl@redhat.com    alla@lysator.liu.se 
He's a superhumanly strong flyboy paranormal investigator who dotes on his 
loving old ma. She's an elegant winged politician operating on the wrong side 
of the law. They fight crime! 

Re: Final separate debug info patch

[Jim Blandy]

Just to give some status on this patch:

The patch as posted doesn't properly handle the case where the
executable file has changed since the last 'run' command, and GDB
needs to re-read the symbols.  It does get rid of the out-of-date
separated objfile, but it doesn't read in the new one.  You may have
said this in one of your earlier posts, but I'll guess now that the
omission was deliberate: this is kind of a pain to do.

I think the separated debug info should use the same section offset
table that its parent objfile does --- that's the table that
reread_symbols would have used if the debug info weren't separated,
anyway.  I've got a patch written, but not working, that does this; it
involved some interface changes to pass the information down to where
it's needed, so it's larger than one would like.  I'll post it as soon
as it seems to work; it'll need to be broken into a few separate
patches before it can really be reviewed and committed.

Re: Final separate debug info patch

[Alexander Larsson]

On 24 Nov 2002, Jim Blandy wrote:

> 
> Just to give some status on this patch:
> 
> The patch as posted doesn't properly handle the case where the
> executable file has changed since the last 'run' command, and GDB
> needs to re-read the symbols.  It does get rid of the out-of-date
> separated objfile, but it doesn't read in the new one.  You may have
> said this in one of your earlier posts, but I'll guess now that the
> omission was deliberate: this is kind of a pain to do.

Yes. That was more or less deliberate. My knowledge of gdb was reaching 
its limits...
 
> I think the separated debug info should use the same section offset
> table that its parent objfile does --- that's the table that
> reread_symbols would have used if the debug info weren't separated,
> anyway.  I've got a patch written, but not working, that does this; it
> involved some interface changes to pass the information down to where
> it's needed, so it's larger than one would like.  I'll post it as soon
> as it seems to work; it'll need to be broken into a few separate
> patches before it can really be reviewed and committed.

Cool.

Btw. You saw that uli fixed the strip problem you had, right?

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl@redhat.com    alla@lysator.liu.se 
He's a fast talking moralistic firefighter who hides his scarred face behind a 
mask. She's a tortured tomboy former first lady fleeing from a Satanic cult. 
They fight crime! 

Re: Final separate debug info patch

[Jim Blandy]

Alexander Larsson <alexl@redhat.com> writes:
> On 24 Nov 2002, Jim Blandy wrote:
> > The patch as posted doesn't properly handle the case where the
> > executable file has changed since the last 'run' command, and GDB
> > needs to re-read the symbols.  It does get rid of the out-of-date
> > separated objfile, but it doesn't read in the new one.  You may have
> > said this in one of your earlier posts, but I'll guess now that the
> > omission was deliberate: this is kind of a pain to do.
> 
> Yes. That was more or less deliberate. My knowledge of gdb was reaching 
> its limits...

I don't blame you a bit.  It doesn't help that GDB has four data
structures which all look pretty much the same:
- struct section_offsets (used by debug readers to offset shlib syms)
- struct section_addr_info (holds user args to add-symbol-file, and dl info)
- struct section_table (in the target structure, for exec files and cores?)
- struct obj_section (for overlay management)

And the functions in symfile.c don't really break the problem down
very helpfully.

> Btw. You saw that uli fixed the strip problem you had, right?

No, that's good.  Where did he post about it?