From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32292 invoked by alias); 6 Feb 2002 17:40:38 -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 32199 invoked from network); 6 Feb 2002 17:40:33 -0000 Received: from unknown (HELO mail.sandvine.com) (209.167.74.226) by sources.redhat.com with SMTP; 6 Feb 2002 17:40:33 -0000 Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Feb 2002 12:40:27 -0500 Message-ID: From: Don Bowman To: Don Bowman Cc: "'gdb@sources.redhat.com '" Subject: RE: MIPS stack tracing Date: Wed, 06 Feb 2002 09:40:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SW-Source: 2002-02/txt/msg00116.txt.bz2 > From: Don Bowman > > I'm going to give dwarf2 a try (as suggested in the thread > @ http://sources.redhat.com/ml/crossgcc/2001-12/msg00039.html) > To summarise: So the dwarf-2 gives the same affect, stack traces do not work on mips with gcc 3.0.3 and binutils 2.11.2. The root of the problem is that the multiple returns per function exist as of the new version of gcc, and there is no .mdebug section anymore. gdb doesn't read the .pdr section which is emitted with the information on how to unwind the stack, so it switches to its heuristic, which is now broken because of the multiple returns. Upon examination of gas, the .pdr section is only emitted if MIPS_STABS_ELF is defined. Am I to assume that if I'm using DWARF2 this won't occur? The code which actually emits it seems to be in ecoff.c. Am I correct that the .pdr section is an array of: /* * Procedure Descriptor * * There is one of these for EVERY TEXT LABEL. * If a procedure is in a file with full symbols, then isym * will point to the PROC symbols, else it will point to the * global symbol for the label. */ typedef struct pdr { bfd_vma adr; /* memory address of start of procedure */ long isym; /* start of local symbol entries */ long iline; /* start of line number entries*/ long regmask; /* save register mask */ long regoffset; /* save register offset */ long iopt; /* start of optimization symbol entries*/ long fregmask; /* save floating point register mask */ long fregoffset; /* save floating point register offset */ long frameoffset; /* frame size */ short framereg; /* frame pointer register */ short pcreg; /* offset or reg of return pc */ long lnLow; /* lowest line in the procedure */ long lnHigh; /* highest line in the procedure */ bfd_vma cbLineOffset; /* byte offset for this procedure from the fd base */ /* These fields are new for 64 bit ECOFF. */ unsigned gp_prologue : 8; /* byte size of GP prologue */ unsigned gp_used : 1; /* true if the procedure uses GP */ unsigned reg_frame : 1; /* true if register frame procedure */ unsigned prof : 1; /* true if compiled with -pg */ unsigned reserved : 13; /* reserved: must be zero */ unsigned localoff : 8; /* offset of local variables from vfp */ } PDR, *pPDR; #define cbPDR sizeof(PDR) This doesn't seem right to me, if I dump my .pdr section I get: Contents of section .pdr: 0000 00400080 00000000 00000000 00000000 .@.............. 0010 00000000 00000000 00000000 00000000 ................ 0020 74430080 00000000 00000000 00000000 tC.............. 0030 00000000 00000000 00000000 00000000 ................ 0040 b8430080 00000000 00000000 00000000 .C.............. ... But all of my addresses start @ 0x80000000.