From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13074 invoked by alias); 13 Sep 2002 22:51:42 -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 13063 invoked from network); 13 Sep 2002 22:51:41 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 13 Sep 2002 22:51:41 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17q0Dn-0002rN-00; Fri, 13 Sep 2002 18:51:35 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17pzHz-0006Vh-00; Fri, 13 Sep 2002 18:51:51 -0400 Date: Fri, 13 Sep 2002 15:51:00 -0000 From: Daniel Jacobowitz To: Earl Chew Cc: gdb@sources.redhat.com Subject: Re: Mystified by "Internal error: pc 0x89f21e10 read in psymtab, but not in symtab Message-ID: <20020913225151.GA24869@nevyn.them.org> Mail-Followup-To: Earl Chew , gdb@sources.redhat.com References: <3D825BB5.48CFAFAB@agilent.com> <20020913220110.GA22097@nevyn.them.org> <3D8269C8.8E33C4AC@agilent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D8269C8.8E33C4AC@agilent.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00169.txt.bz2 On Fri, Sep 13, 2002 at 03:42:16PM -0700, Earl Chew wrote: > Daniel Jacobowitz wrote: > > What debug information is produced by your toolchain - mdebug, I bet. > > Mdebug support is a little on the rotting side because we don't have > > anyone interested/willing to maintain it; and mdebug is a mighty > > arcane format. > > So, I roll up my sleeves and start debugging gdb. I believe > the compiler is producing stabs in elf. How can I check? What version compiler and assembler are you using? And are they FSF or WindRiver-supplied? You should be using stabs-in-ELF, but it requires matching Binutils and GCC. For binutils, it's enough to see that you get a .stab and .stabstr and no .mdebug. For GCC it's harder. > The target is VxWorks using remote serial protocol with > segment resolution using qOffset. > > I put in a couple of printfs, and notice that the > block vectors have start > end. Oops. > > I put another breakpoint in end_symtab, and notice that > it's being called from read_ofile_symtab in dbxread.c. At the > end of this function, there's a line that reads: > > pst->symtab = end_symtab (text_offset + text_size, objfile, > SECT_OFF_TEXT (objfile)); > > Looking at end_symtab in buildsym.c, I see: > > /* Make a block for the local symbols within. */ > finish_block (cstk->name, &local_symbols, cstk->old_blocks, > cstk->start_addr, end_addr, objfile); > > Printing cstk->start_addr, I see that this is the succesfully > relocated address (somewhere at 0x8fxxxxxx), but end_addr is > a small number --- obviously not relocated. > > Patching dbxread.c > > pst->symtab = end_symtab (text_offset + > text_size + > section_offsets->offsets[SECT_OFF_TEXT (objfile)], > objfile, SECT_OFF_TEXT (objfile)); > > cures the problem. > > But I'm not sure if this patch should be applied to > end_symtab() instead. I looked and end_symtab() is called from > many places, and I don't have enough information to decide > if they're right/wrong in the manner of dbxread.c. This sounds like your GCC and binutils are out of sync, in fact. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer