From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21827 invoked by alias); 15 Sep 2002 16:02:45 -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 21820 invoked from network); 15 Sep 2002 16:02:44 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 15 Sep 2002 16:02:44 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17qcnF-0000cK-00; Sun, 15 Sep 2002 12:02:45 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17qbrW-0003K9-00; Sun, 15 Sep 2002 12:03:06 -0400 Date: Sun, 15 Sep 2002 09:02: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: <20020915160306.GA31994@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> <20020913225151.GA24869@nevyn.them.org> <3D8270FF.3086EA5C@agilent.com> <20020914013314.GB31038@nevyn.them.org> <3D84AAAD.6090706@agilent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D84AAAD.6090706@agilent.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00191.txt.bz2 On Sun, Sep 15, 2002 at 08:43:41AM -0700, Earl Chew wrote: > Daniel Jacobowitz wrote: > >With any patches? And, did you check which of .mdebug/.stab you're > >getting? > > Some patches for VxWorks compatibility, and yes, it's using .stabs. OK. You're probably fine on this front; you might want to make sure that .stabn directives end with something like "$LM1-main" [stabs style] rather than "$LM1" [mdebug style] but I don't expect that to be the problem. > >>>This sounds like your GCC and binutils are out of sync, in fact. > >> > >>I'm pretty sure there's something wrong with gdb in this regard > >>because end_symtab is being called with cstk->start_addr > >>(succesfully relocated) and end_addr (not relocated). > > > > > >One difference between stabs-in-mdebug and stabs-in-elf is whether line > >and other addresses are relative to the beginning of the function or > >absolute. A mismatch causes this symptom. If you're getting > >stabs-in-ELF, I believe GCC 2.95 is not prepared for that. > > Daniel, I can now see why you are suspicious about my previous attempt > at a fix. Thinking about the problem some more, I see that if my > attempted patch were really the proper fix, this problem should manifest > itself in all sites running gdb --- and clearly it doesn't. > > So I must be on the right track, but clearly, the patch isn't resolving > the core of the problem. > > I'm running gdb like this: > > vxgdb> file c:/foo.dbg > vxgdb> target remote 10.0.0.2:987 > > A consequence of the target command is that the remote is queried for > qOffsets, and responds with the relocated addresses for .text, .data > and .bss. > > The result of this is that objfile_relocate in objfiles.c is called > to relocate the symbols. I can see this walking the partial symbols > using ALL_OBJFILE_PSYMTABS. > > However, dbxread.c has private symbol information cached in > read_symtab_private. The contents of this information is unknown > to objfile_relocate, and hence it doesn't make any attempt to > relocate it. I think the solution here is to provide another > function pointer (eg relocate_symtab) to allow objfile_relocate > to get this private information updated. My first suspect: 2001-10-23 Jim Blandy Isolate STABS readers' use of the `textlow' and `texthigh' fields of `struct partial_symtab' to only a few locations. This change is not supposed to affect the way the values are computed, only where they live. * dbxread.c (struct symloc): Add `textlow' and `texthigh' fields to the reader-specific structure. * mdebugread.c (struct symloc): Same. * dbxread.c (TEXTLOW, TEXTHIGH): New accessor macros. * mdebugread.c (TEXTLOW, TEXTHIGH): Same. * dbxread.c (dbx_symfile_read): After we've built all our partial symbol tables, set each partial symtab's `textlow' and `texthigh' fields from our reader-specific structure. * mdebugread.c (mdebug_build_psymtabs): Same. * dbxread.c (start_psymtab): Initialize the reader-specific structure's `textlow' and `texthigh' from the new psymtab's. * mdebugread.c (parse_partial_symbols, new_psymtab): Same. * dbxread.c (read_dbx_symtab, end_psymtab, read_ofile_symtab): Use the reader-specific `textlow' and `texthigh', not the generic psymtab fields. * mdebugread.c (parse_lines, parse_partial_symbols, psymtab_to_symtab_1): Same. * partial-stab.h: Same. I no longer remember what Jim was trying to accomplish with this change, but it sounds like you're on the right track. You might want to see if this patch is causing the problem. If that doesn't help: there are other consumers of objfile_relocate. For instance, solib-svr4.c. I use that code on a MIPS target without seeing this problem. Or at least I used to... not for terribly long, as I went from mdebug to actually fixing DWARF-2 and using that. Does solib-svr4 manage to avoid this problem? If so, rather than propogating this mess, is there some way you can use the shared library code for this somehow? A parallel, minimal "shared library" implementation which gets relocation information via qOffsets... > > So, I think objfiles.c needs to be changed to: > > { > struct partial_symtab *p; > > ALL_OBJFILE_PSYMTABS (objfile, p) > { > p->textlow += ANOFFSET (delta, SECT_OFF_TEXT (objfile)); > p->texthigh += ANOFFSET (delta, SECT_OFF_TEXT (objfile)); > > p->relocate_symtab(p, delta); > } > } > > And the implementation for dbxread.c should be: > > static void dbx_relocate_symtab( > struct partial_symtab* pst, > struct section_offsets* delta) > { > TEXTLOW(pst) += ANOFFSET (delta, SECT_OFF_TEXT (pst->objfile)); > TEXTHIGH(pst) += ANOFFSET (delta, SECT_OFF_TEXT (pst->objfile)); > } > > Corresponding implementations are required in dwarf2read.c, hpread.c, > mdebugread.c, os9kread.c and xcoffread.c. Some of these do not > cache offsets the way dbxread.c does, so the relocation function > can be empty. > > Earl > > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer