Re: MIPS: 64-bit DWARF

["Maciej W. Rozycki" <macro@codesourcery.com>]

On Thu, 15 Jul 2010, Tom Tromey wrote:

> Maciej> GDB as of 6.8 didn't cope at all with 64-bit DWARF records that
> Maciej> were generated for n64 binaries before the switch (for the MIPS
> Maciej> platform, that is -- I'd expect it to work for some others,
> Maciej> especially ones that have always been 64-bit like the Alpha) --
> Maciej> the usual symptom was a complete exhaustion of the stack space
> Maciej> followed by a crash (tested natively only).
> 
> Could you try a newer gdb?  And, if it still fails, file a bug report?

 I'm not ready for an upgrade at the moment, sorry.  I'll try to remember 
to test this stuff when I am -- I keep old toolchains around, so I may be 
able to get a test case easily.

 I would have debugged the problem originally myself, but obviously GDB 
crashed with 64-bit-annotated GDB as it did with any other binary.

> gdb isn't fully ready for 64 bit DWARF (e.g., CU offsets are still just
> unsigned ints), but it shouldn't crash.

 Well, it recursed till the end of the stack, at which point IIRC the 
kernel would kill the process.  So a resource exhaustion rather a usual 
segfault or suchlike, though the end result was effectively the same.  
Clearly it must have got rather confused, but with the immaturity of the 
n64 toolchain back when I started looking into it that could have been 
anything up to a compiler or binutils bug.

> Maciej>  TE_IRIX refers to the original 64-bit DWARF stuff invented by
> Maciej> SGI that predates DWARF-3 and differs slightly from the latter.
> Maciej> This may perhaps be the reason of the GDB crash -- it may have
> Maciej> this SGI variant hardcoded for the MIPS target or suchlike.
> 
> gdb's dwarf reader doesn't use the target for this.  It just recognizes
> the SGI approach unconditionally.  See dwarf2read.c:read_initial_length.

 I see.  Somehow I thought there were some target-dependent hooks involved 
as well.  Thanks for your clarification.

  Maciej