From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31980 invoked by alias); 16 Jul 2010 14:44:22 -0000 Received: (qmail 31969 invoked by uid 22791); 16 Jul 2010 14:44:21 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Jul 2010 14:44:15 +0000 Received: (qmail 8653 invoked from network); 16 Jul 2010 14:44:13 -0000 Received: from unknown (HELO tp.orcam.me.uk) (macro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Jul 2010 14:44:13 -0000 Date: Fri, 16 Jul 2010 14:44:00 -0000 From: "Maciej W. Rozycki" To: Tom Tromey cc: gdb@sourceware.org Subject: Re: MIPS: 64-bit DWARF In-Reply-To: Message-ID: References: <4BE16915.7080501@codesourcery.com> <20100505143213.GA4735@caradoc.them.org> <4BE187D8.4050804@codesourcery.com> <20100507132310.GA6374@host0.dyn.jankratochvil.net> <87sk431a3j.fsf@dirichlet.schwinge.homeip.net> <87fwzxvslw.fsf_-_@dirichlet.schwinge.homeip.net> <87eif6v450.fsf@dirichlet.schwinge.homeip.net> <4C3DEC14.8090601@caviumnetworks.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-07/txt/msg00053.txt.bz2 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