This is the mail archive of the
mailing list for the GDB project.
Re: MIPS: 64-bit DWARF
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.