Re: gdb/2009: Segmentation faults on AMD64

I debugged this segfault and it is caused by incorrect debug
information generated by GCC on AMD64, see http://gcc.gnu.org/PR24400.
The problem is that the filenumbers in the .debug_macinfo arex
wrong. They jump from 0xf to 0x11, skipping 0x10, so the last filename
has a number which isn't in the filename table.

GDB blindly uses the number as index into the filename table,
resulting in a segfault. The following patch adds a check whether the
index isn't bigger than the size of the table.


2005-10-16  Jeroen Dekkers  <jeroen@xxxxxxxxxx>

        Fix PR gdb/2009.
        * dwarf2read.c (file_full_name): Check whether FILE isn't bigger
        than the size of the filename table.


Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.183
diff -u -p -r1.183 dwarf2read.c
--- dwarf2read.c        1 Aug 2005 04:06:27 -0000       1.183
+++ dwarf2read.c        16 Oct 2005 12:43:23 -0000
@@ -8810,7 +8810,19 @@ dwarf_alloc_die (void)
 static char *
 file_full_name (int file, struct line_header *lh, const char *comp_dir)
 {
-  struct file_entry *fe = &lh->file_names[file - 1];
+  struct file_entry *fe;
+
+  /* Check whether FILE isn't bigger than the number of filenames in
+     the table. There used to be a bug in GCC (PR24400) which would
+     generate an index that is one higher than the size of the
+     table. */
+  if (file > lh->num_file_names)
+    {
+      complaint (&symfile_complaints, _("invalid file index number in macro 
section"));
+      return xstrdup ("/invalid/file/index");
+    }
+      
+  fe = &lh->file_names[file - 1];
   
   if (IS_ABSOLUTE_PATH (fe->name))
     return xstrdup (fe->name);