DWARF2 vs. 64-bit MIPS

DWARF2 vs. 64-bit MIPS

[Mark Mitchell]

The 64-bit IRIX6 use of DWARF2 does not follow the published DWARF
documents I found on Intel's web-site.  In particular, look at the
beginning of this DWARF2 section from the 64-bit crt1.o:

.debug_info:

           	0000  0000  0000  0140  0002  0000  0000  0000  
           	0000  0801  2f78  6c76  3535  2f6b  7564  7a75  

There are *eight* (rather than four) bytes, indicating the length of
the debugging information, two bytes (as required) of DWARF version
information, and *eight* (rather than four) bytes of address offset,
followed by the single-byte value indicating the address size.

Contrast with the N32 version:

.debug_info:

           	0000  0106  0002  0000  0000  0401  2f78  6c76  

In order to handle this situation, it would seem that we need
parse_comp_unit to take the address size as a parameter, rather than
calculating it from looking at the debugging information.  Of course,
if no such size is provided, it could fall back on the method it uses
now, which matches the DWARF2 documentation.

Objections to such a patch, or suggestions for other approaches?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: DWARF2 vs. 64-bit MIPS

[Ian Lance Taylor]

   From: Mark Mitchell <mark@codesourcery.com>
   Date: Fri, 02 Jul 1999 16:15:48 -0700

   The 64-bit IRIX6 use of DWARF2 does not follow the published DWARF
   documents I found on Intel's web-site.  In particular, look at the
   beginning of this DWARF2 section from the 64-bit crt1.o:

   .debug_info:

		   0000  0000  0000  0140  0002  0000  0000  0000  
		   0000  0801  2f78  6c76  3535  2f6b  7564  7a75  

   There are *eight* (rather than four) bytes, indicating the length of
   the debugging information, two bytes (as required) of DWARF version
   information, and *eight* (rather than four) bytes of address offset,
   followed by the single-byte value indicating the address size.

   Contrast with the N32 version:

   .debug_info:

		   0000  0106  0002  0000  0000  0401  2f78  6c76  

   In order to handle this situation, it would seem that we need
   parse_comp_unit to take the address size as a parameter, rather than
   calculating it from looking at the debugging information.  Of course,
   if no such size is provided, it could fall back on the method it uses
   now, which matches the DWARF2 documentation.

gdb appears to have the same problem, judging by
dwarf2_build_psymtabs_hard in dwarf2read.c in gdb 4.18 and on
sourceware.  Do any gdb hackers read this list?

gcc appears to generate an 8 byte length on Irix 6 in 64-bit mode,
by doing this:

/* The size in bytes of a DWARF field indicating an offset or length
   relative to a debug info section, specified to be 4 bytes in the DWARF-2
   specification.  The SGI/MIPS ABI defines it to be the same as PTR_SIZE.  */
#define DWARF_OFFSET_SIZE PTR_SIZE

This seems to be the only case in gcc where it generates a DWARF 2
offset size of other than 4 bytes.

It appears that this needs to be a parameter to
_bfd_dwarf2_find_nearest_line, which I assume is what you were
suggesting.  Then _bfd_mips_elf_find_nearest_line can pass it in the
right value based on the object file flags.

Ian

Re: DWARF2 vs. 64-bit MIPS

[Mark Mitchell]

Ian --

    Ian> It appears that this needs to be a parameter to
    Ian> _bfd_dwarf2_find_nearest_line, which I assume is what you
    Ian> were suggesting.  Then _bfd_mips_elf_find_nearest_line can
    Ian> pass it in the right value based on the object file flags.

Yup, that's what I had in mind.  How about this patch?
  
--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

1999-07-02  Mark Mitchell  <mark@codesourcery.com>

	* dwarf2.c (parse_comp_unit): Add ABBREV_LENGTH parameter.
	(_bfd_dwarf2_find_nearest_line): Add ADDR_SIZE parameter.
	* elf.c (_bfd_elf_find_nearest_line): Pass it.
	* elf32-arm.h (elf32_arm_find_nearest_line): Likewise.
	* elf32-mips.c (ABI_64_P): New macro.
	(IRIX_COMPAT): We are IRIX6-compatible if ABI_64_P.
	(_bfd_mips_elf_find_nearest_line): Adjust call to
	_bfd_dwarf2_find_nearest_line.
	* libbfd-in.h (_bfd_dwarf2_find_nearest_line): Update prototype.
	* libbfd.h: Regenerated.

Index: dwarf2.c
===================================================================
RCS file: /cvs/binutils/binutils/bfd/dwarf2.c,v
retrieving revision 1.6
diff -u -p -r1.6 dwarf2.c
--- dwarf2.c	1999/06/26 16:05:58	1.6
+++ dwarf2.c	1999/07/03 01:04:33
@@ -1216,19 +1216,22 @@ scan_unit_for_functions (unit)
 
 
 
-/* Parse a DWARF2 compilation unit starting at INFO_PTR.  This includes
-   the compilation unit header that proceeds the DIE's, but does not
-   include the length field that preceeds each compilation unit header.
-   END_PTR points one past the end of this comp unit.
+/* Parse a DWARF2 compilation unit starting at INFO_PTR.  This
+   includes the compilation unit header that proceeds the DIE's, but
+   does not include the length field that preceeds each compilation
+   unit header.  END_PTR points one past the end of this comp unit.
+   If ABBREV_LENGTH is 0, then the length of the abbreviation offset
+   is assumed to be four bytes.  Otherwise, it it is the size given.
 
    This routine does not read the whole compilation unit; only enough
    to get to the line number information for the compilation unit.  */
 
 static struct comp_unit *
-parse_comp_unit (abfd, info_ptr, end_ptr)
+parse_comp_unit (abfd, info_ptr, end_ptr, abbrev_length)
      bfd* abfd;
      char* info_ptr;
      char* end_ptr;
+     unsigned int abbrev_length;
 {
   struct comp_unit* unit;
 
@@ -1243,8 +1246,14 @@ parse_comp_unit (abfd, info_ptr, end_ptr
 
   version = read_2_bytes (abfd, info_ptr);
   info_ptr += 2;
-  abbrev_offset = read_4_bytes (abfd, info_ptr);
-  info_ptr += 4;
+  BFD_ASSERT (abbrev_length == 0
+	      || abbrev_length == 4
+	      || abbrev_length == 8);
+  if (abbrev_length == 0 || abbrev_length == 4)
+    abbrev_offset = read_4_bytes (abfd, info_ptr);
+  else if (abbrev_length == 8)
+    abbrev_offset = read_8_bytes (abfd, info_ptr);
+  info_ptr += abbrev_length;
   addr_size = read_1_byte (abfd, info_ptr);
   info_ptr += 1;
 
@@ -1435,12 +1444,17 @@ comp_unit_find_nearest_line (unit, addr,
   return line_p || func_p;
 }
 
-/* The DWARF2 version of find_nearest line.
-   Return true if the line is found without error. */
+/* The DWARF2 version of find_nearest line.  Return true if the line
+   is found without error.  ADDR_SIZE is the number of bytes in the
+   initial .debug_info length field and in the abbreviation offset.
+   You may use zero to indicate that the default value should be
+   used.  */
 
 boolean
 _bfd_dwarf2_find_nearest_line (abfd, section, symbols, offset,
-			  filename_ptr, functionname_ptr, linenumber_ptr)
+			       filename_ptr, functionname_ptr,
+			       linenumber_ptr,
+			       addr_size)
      bfd *abfd;
      asection *section;
      asymbol **symbols;
@@ -1448,6 +1462,7 @@ _bfd_dwarf2_find_nearest_line (abfd, sec
      const char **filename_ptr;
      const char **functionname_ptr;
      unsigned int *linenumber_ptr;
+     unsigned int addr_size;
 {
   /* Read each compilation unit from the section .debug_info, and check
      to see if it contains the address we are searching for.  If yes,
@@ -1470,6 +1485,13 @@ _bfd_dwarf2_find_nearest_line (abfd, sec
   *functionname_ptr = NULL;
   *linenumber_ptr = 0;
 
+  /* The DWARF2 spec says that the initial length field, and the
+     offset of the abbreviation table, should both be 4-byte values.
+     However, some compilers do things differently.  */
+  if (addr_size == 0)
+    addr_size = 4;
+  BFD_ASSERT (addr_size == 4 || addr_size == 8);
+    
   if (! stash)
     {
       asection *msec;
@@ -1540,16 +1562,20 @@ _bfd_dwarf2_find_nearest_line (abfd, sec
   while (stash->info_ptr < stash->info_ptr_end)
     {
       struct comp_unit* each;
-      unsigned int length;
+      bfd_vma length;
       boolean found;
 
-      length = read_4_bytes (abfd, stash->info_ptr);
-      stash->info_ptr += 4;
+      if (addr_size == 4)
+	length = read_4_bytes (abfd, stash->info_ptr);
+      else
+	length = read_8_bytes (abfd, stash->info_ptr);
+      stash->info_ptr += addr_size;
 
       if (length > 0)
         {
 	  each = parse_comp_unit (abfd, stash->info_ptr, 
-				  stash->info_ptr + length);
+				  stash->info_ptr + length,
+				  addr_size);
 	  stash->info_ptr += length;
 
 	  if (each)
Index: elf.c
===================================================================
RCS file: /cvs/binutils/binutils/bfd/elf.c,v
retrieving revision 1.8
diff -u -p -r1.8 elf.c
--- elf.c	1999/07/01 23:20:06	1.8
+++ elf.c	1999/07/03 00:54:22
@@ -4616,7 +4616,7 @@ _bfd_elf_find_nearest_line (abfd,
 
   if (_bfd_dwarf2_find_nearest_line (abfd, section, symbols, offset,
 				     filename_ptr, functionname_ptr,
-				     line_ptr))
+				     line_ptr, 0))
     return true;
 
   if (! _bfd_stab_section_find_nearest_line (abfd, symbols, section, offset,
Index: elf32-arm.h
===================================================================
RCS file: /cvs/binutils/binutils/bfd/elf32-arm.h,v
retrieving revision 1.10
diff -u -p -r1.10 elf32-arm.h
--- elf32-arm.h	1999/06/30 02:30:04	1.10
+++ elf32-arm.h	1999/07/03 00:54:24
@@ -2396,7 +2396,7 @@ elf32_arm_find_nearest_line
 
   if (_bfd_dwarf2_find_nearest_line (abfd, section, symbols, offset,
 				     filename_ptr, functionname_ptr,
-				     line_ptr))
+				     line_ptr, 0))
     return true;
 
   if (! _bfd_stab_section_find_nearest_line (abfd, symbols, section, offset,
Index: elf32-mips.c
===================================================================
RCS file: /cvs/binutils/binutils/bfd/elf32-mips.c,v
retrieving revision 1.12
diff -u -p -r1.12 elf32-mips.c
--- elf32-mips.c	1999/07/01 23:20:08	1.12
+++ elf32-mips.c	1999/07/03 01:41:54
@@ -235,12 +235,17 @@ typedef enum {
 #define ABI_N32_P(abfd) \
   ((elf_elfheader (abfd)->e_flags & EF_MIPS_ABI2) != 0)
 
+/* Nonzero if ABFD is using the 64-bit ABI.  FIXME: This is never
+   true, yet.  */
+#define ABI_64_P(abfd) \
+  ((elf_elfheader (abfd)->e_ident[EI_CLASS] == ELFCLASS64) != 0)
+
 /* What version of Irix we are trying to be compatible with.  FIXME:
    At the moment, we never generate "normal" MIPS ELF ABI executables;
    we always use some version of Irix.  */
 
 #define IRIX_COMPAT(abfd) \
-  (ABI_N32_P (abfd) ? ict_irix6 : ict_irix5)
+  ((ABI_N32_P (abfd) || ABI_64_P (abfd)) ? ict_irix6 : ict_irix5)
 
 /* Whether we are trying to be compatible with IRIX at all.  */
 
@@ -3517,7 +3522,8 @@ _bfd_mips_elf_find_nearest_line (abfd, s
 
   if (_bfd_dwarf2_find_nearest_line (abfd, section, symbols, offset,
 				     filename_ptr, functionname_ptr,
-				     line_ptr))
+				     line_ptr, 
+				     ABI_64_P (abfd) ? 8 : 0))
     return true;
 
   msec = bfd_get_section_by_name (abfd, ".mdebug");
Index: libbfd-in.h
===================================================================
RCS file: /cvs/binutils/binutils/bfd/libbfd-in.h,v
retrieving revision 1.3
diff -u -p -r1.3 libbfd-in.h
--- libbfd-in.h	1999/06/03 18:48:22	1.3
+++ libbfd-in.h	1999/07/03 00:54:28
@@ -365,7 +365,7 @@ extern boolean _bfd_dwarf1_find_nearest_
 /* Find the nearest line using DWARF 2 debugging information.  */
 extern boolean _bfd_dwarf2_find_nearest_line
   PARAMS ((bfd *, asection *, asymbol **, bfd_vma, const char **,
-	   const char **, unsigned int *));
+	   const char **, unsigned int *, unsigned int));
 
 /* A routine to create entries for a bfd_link_hash_table.  */
 extern struct bfd_hash_entry *_bfd_link_hash_newfunc

Re: DWARF2 vs. 64-bit MIPS

[Richard Henderson]

On Fri, Jul 02, 1999 at 04:15:48PM -0700, Mark Mitchell wrote:
> There are *eight* (rather than four) bytes, indicating the length of
> the debugging information, two bytes (as required) of DWARF version
> information, and *eight* (rather than four) bytes of address offset,
> followed by the single-byte value indicating the address size.

Yep, there's a comment to that effect in the gcc sources.  SGI
decided to change all the inter-debug offsets to 64-bits on the
64-bit targets. 

Jason didn't follow them.  It does bloat the size of the debug info,
and it does require you write enough code for 4G of debug info.  
There should be a way to tell the difference (and switch between the
two, supposing you _do_ write such big programs!), but I don't know
what off-hand.

> In order to handle this situation, it would seem that we need
> parse_comp_unit to take the address size as a parameter...

Seems reasonable.


r~

Re: DWARF2 vs. 64-bit MIPS

[Ian Lance Taylor]

   Date: Tue, 6 Jul 1999 18:49:29 -0700
   From: Richard Henderson <rth@cygnus.com>

   Jason didn't follow them.  It does bloat the size of the debug info,
   and it does require you write enough code for 4G of debug info.  
   There should be a way to tell the difference (and switch between the
   two, supposing you _do_ write such big programs!), but I don't know
   what off-hand.

I would normally expect to get such information from sh_info, sh_link,
or sh_entsize.

However, I don't know if SGI thought ahead enough to make any of those
values different for the arguably non-standard debugging information
generated by their tools.  It won't do us much good to implement some
way to detect this case if it doesn't work for SGI generated objects.

Of course, we can fall back on simple if fallible heuristics like ``if
the length appears to be zero, we probably have an eight byte
length.''  On a little endian system, check whether the version number
is valid, and, if not, see if we can make it valid by assuming an
eight byte length.

Ian