From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28567 invoked by alias); 7 Feb 2002 00:45:22 -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 28501 invoked from network); 7 Feb 2002 00:45:18 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 7 Feb 2002 00:45:18 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16Ycgg-0005OR-00; Wed, 06 Feb 2002 19:45:18 -0500 Date: Wed, 06 Feb 2002 16:45:00 -0000 From: Daniel Jacobowitz To: Don Bowman Cc: "'gdb@sources.redhat.com '" Subject: Re: MIPS stack tracing Message-ID: <20020206194518.B20568@nevyn.them.org> Mail-Followup-To: Don Bowman , "'gdb@sources.redhat.com '" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-SW-Source: 2002-02/txt/msg00119.txt.bz2 On Wed, Feb 06, 2002 at 12:40:18PM -0500, Don Bowman wrote: > > > 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. No. It should be emitted unless we are emitting .mdebug, which we don't do any more for mips-*-linux. > 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) I don't think that's the right one. The code in gas to emit them: subseg_set (pdr_seg, 0); /* Write the symbol. */ exp.X_op = O_symbol; exp.X_add_symbol = p; exp.X_add_number = 0; emit_expr (&exp, 4); fragp = frag_more (7 * 4); md_number_to_chars (fragp, (valueT) cur_proc_ptr->reg_mask, 4); md_number_to_chars (fragp + 4, (valueT) cur_proc_ptr->reg_offset, 4); md_number_to_chars (fragp + 8, (valueT) cur_proc_ptr->fpreg_mask, 4); md_number_to_chars (fragp + 12, (valueT) cur_proc_ptr->fpreg_offset, 4); md_number_to_chars (fragp + 16, (valueT) cur_proc_ptr->frame_offset, 4); md_number_to_chars (fragp + 20, (valueT) cur_proc_ptr->frame_reg, 4); md_number_to_chars (fragp + 24, (valueT) cur_proc_ptr->pc_reg, 4); subseg_set (saved_seg, saved_subseg); So that is: symbol, regmask, regoffset, fpregmask, fpregoffset, frameoffset, framereg, pcreg, and broken for 64-bit targets. Feh, I'll have to fix that last one. > 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. Careful, it has relocations if you look at it in an object. Also careful, you have a host-target endian mismatch. That first word is 0x80000400. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer