From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3810 invoked by alias); 4 Feb 2002 17:22:51 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 3725 invoked from network); 4 Feb 2002 17:22:49 -0000 Received: from unknown (HELO rj.sgi.com) (204.94.215.100) by sources.redhat.com with SMTP; 4 Feb 2002 17:22:49 -0000 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by rj.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.1) with ESMTP id g14HMnY14929 for ; Mon, 4 Feb 2002 09:22:49 -0800 Received: from quasar.engr.sgi.com (quasar.engr.sgi.com [130.62.180.91]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id JAA53118 for ; Mon, 4 Feb 2002 09:21:33 -0800 (PST) Received: (from davea@localhost) by quasar.engr.sgi.com (SGI-8.9.3/8.9.3) id JAA16362 for gdb@sources.redhat.com; Mon, 4 Feb 2002 09:21:13 -0800 (PST) Date: Mon, 04 Feb 2002 09:22:00 -0000 From: David Anderson Message-Id: <200202041721.JAA16362@quasar.engr.sgi.com> To: gdb@sources.redhat.com Subject: Re: MIPS stack tracing X-SW-Source: 2002-02/txt/msg00082.txt.bz2 Daniel Jacobowitz > > .mdebug is the ECOFF/Third-Eye debugging info format; binutils recently > switched to generating stabs-in-ELF like other targets instead. > > To my complete surprise, we apparently get PDR information out of the > .mdebug section. This is somewhat bizarre, as it is also present in a > .pdr section independent of data format. We need to read in this > information. I'll investigate next week (if no one beats me to it :). The original third-eye was (as you say) added to COFF by MIPS (SGI was separate then, mid 1980's). No real sections. the PDR was inside the third-eye data. When MIPS/SGI moved to Elf we made the third-eye data be a section named .mdebug but with bit-for-bit identical contents to the coff-object third-eye. There was no .pdr section. The third-eye data structures were not ideal, in that they had absolute (not section-relative) file offsets, and those, of course, were always wrong for objects-inside-archives as such objects-inside-archives were simply plunked in by ar(1) and extracted by ld with no update of the mdebug data. Third-eye was designed this way precisely because various object formats of the time third-eye was designed did not have real sections and adding extra sections was a major hassle (compatibility-wise and more). So section-relative offsets were an idea that just did not work back then (and I guess Peter Rowell, the designer (he was Third-eye Software), just did not think of making the mdebug-internal offsets be mdebug-relative (or decided not to, I don't know...)). Andrew Cagney >It would go back to SGI (Hmm, didn't sgi switch to dwarf2?) which was >using mdebug info. A number of embedded MIPS toolchains would have been >mdebug for compatability (I know this as I filed gdb/150, gdb/152 and >gdb/149) and I have a sinking feeling that they haven't yet ``just gone >away''. Ok. More than you want to know (sorry). SGI has 3 ABIs, all ELF (since the mid 1990's). An executable can be built in any ABI. o32. Uses mdebug (third-eye). Follows the MIPS Processor Supplement. Intended for MIPS-1 (and now MIPS-2 cpu chips only. This will never change, compiler in stasis :-) n32 Uses dwarf-2. For MIPS-3 and MIPS-4 cpu chips, takes advantage of 64bit integer registers and additional floating point registers. pointers are 32 bits. Not yet using dwarf-3. ABI defined in N32 Handbook (http://techpubs.sgi.com) 64 Uses dwarf-2. For MIPS-3 and MIPS-4 cpu chips, takes advantage of 64bit integer registers and additional floating point registers. pointers are 64 bits. Not yet using dwarf-3. David Anderson davea@sgi.com