From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26598 invoked by alias); 3 Jan 2003 19:19:21 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26589 invoked from network); 3 Jan 2003 19:19:19 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 3 Jan 2003 19:19:19 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18UZEE-0002pl-00 for ; Fri, 03 Jan 2003 15:19:42 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18UXLg-0001ty-00 for ; Fri, 03 Jan 2003 14:19:16 -0500 Date: Fri, 03 Jan 2003 19:19:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFA] Fix a "pc ... in psymtab but not in symtab" internal error warning Message-ID: <20030103191915.GA7201@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20030103190722.GL693@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030103190722.GL693@gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00075.txt.bz2 On Fri, Jan 03, 2003 at 11:07:22PM +0400, Joel Brobecker wrote: > Hello, > > After fixing the problem in mdebugread.c (see one of my recent patches), > GDB was no longer crashing, but some internal errors later appeared. > Something like this: > > warning: (Internal error: pc 0x3ff800203a8 in read in psymtab, but not in symtab.) > > This would happen when trying to do a backtrace, for intance. These > warnings are really annoying, as they have a tendency to flood the > regular output... > > I found that the address was a valid PC address for a function inside > one of the system libraries (eg libc or libpthread, for instance). What > happened is that GDB was doing a symtab lookup for this address and did > not find any. It then did a psymtab lookup, and found one. But then GDB > was surprised to find out that the psymtab was already read in, and > hence generated the warning. See find_pc_sect_symtab in symtab.c: > > | ALL_SYMTABS (objfile, s) > | { > | if (BLOCK_START (b) <= pc && BLOCK_END (b) > pc && [...]) > | { > | [...] > | best_s = s; > | } > | } > | > | if (best_s != NULL) > | return best_s; > | > | ps = find_pc_sect_psymtab (pc, section); > | if (ps) > | { > | if (ps->readin) > | warning ("Internal error: [...]"); > | s = PSYMTAB_TO_SYMTAB (ps); > | } > | > | return s; > > What really striked me when I started debugging this is that the > psymtab found by find_pc_sect_psymtab was completely incorrect. > At second thought, it should not have found any psymtab, since > the symbol in question did not come with any debugging info besides > the minimal symbol table. > > So I looked at the textlow and texthigh values for the psymtab, > and was started by the texthigh value: 0xfffffffffffffffe, or > written differently: -2. A "maintenance print symbols" and "maintenance > print psymbols" confirmed that many symtabs had a suspisciouly high > texthigh value. These dumps also revealed that these entries contained > procedures with empty names and and address of 0xfffffffffffffffe. > > Debugging a bit furter, I indeed found stProc symbol records whose value > are -2. I then looked up the Compaq documentation for the ECOFF format, > and it says p171 that (stProc, scInfo) entries represent "a procedure > without code, or a function prototype, or a function pointer". In that > case, the value field is respectively either -1, -2, or a non-negative > value. > > I read a bit more about stProc and stStaticProc symbol records. > According to this documentation, only a very small subset of the > (storage type, storage class) couple is legal: > - stProc can only be associated with scNil, scText, scUndefined, > and scInfo. > - stStaticProc can only be associated with scText, scInit, and scFini. > > It also says that only (stProc, scText) entries are "real" procedures > (all combinations of (stStaticProc, sc*) are "real" procedures). > > I therefore made some modifications in mdebugread.c to ignore all > stProc entries when the storage class was not scText. This fixed > the warnings, and did not introduce any regressions. > > But there is one flaw in my testing that I have to admit: we don't have > a C++ compiler on our Tru64 machine... I still suggest this fix for > inclusion in our sources, although I would understand that it be > rejected for lack of testing. I checked the output of the "maint print > symbols" and "maint print psymbols" commands, and did not find any > 0xff[...]fe addresses anymore. > > 2003-01-03 J. Brobecker > > * mdebugread.c (parse_symbol): Skip stProc entries which storage > class is not scText. These do not define "real" procedures. > (parse_partial_symbols): Likewise. > > Ahem, ok to commit? Yes, I think so. Meanwhile, I recommend: http://www.testdrive.hp.com/os/#tru64 I imagine they've got a C++ compiler available; yeah, it's a bit of a nuisance to use their systems, but... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer