Re: DWARF2 vs. 64-bit MIPS

[Ian Lance Taylor <ian@zembu.com>]

   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