From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11168 invoked by alias); 15 Nov 2005 06:50:46 -0000 Received: (qmail 11159 invoked by uid 22791); 15 Nov 2005 06:50:43 -0000 Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 15 Nov 2005 06:50:43 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EbudA-0002al-0X for gdb@sources.redhat.com; Tue, 15 Nov 2005 07:49:24 +0100 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Nov 2005 07:49:24 +0100 Received: from ghost by zigzag.lvk.cs.msu.su with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Nov 2005 07:49:24 +0100 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: warning: (Internal error: pc 0xd00 in read in psymtab, but not in symtab.) Date: Tue, 15 Nov 2005 06:50:00 -0000 Message-ID: References: <20051108150752.62145.qmail@web81211.mail.mud.yahoo.com> <20051113173904.GF1945@nevyn.them.org> <20051115010716.GA14640@Power-Mac-G5.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.8.2 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00290.txt.bz2 Ron McCall wrote: > By the way, I did try a newer snapshot but still got the same result, as > you suspected. I ran the cross gdb under a native gdb to try to see > what was happening. With a breakpoint on find_pc_sect_symtab() in > symtab.c and a single command input of "disas 0xd00 0xd04" there are > several calls to this function. I can re-run the test to get specific > input values if that would help. If I remember correctly, the call that > resulted in the warning message being printed had inputs of pc=0 and > section=0. pc=0? Hmm, does your application start at address zero? I distinctly remember I had to patch my local gdb version because it did not like sections starting at address zero. Below is the patch I use. But I'm not sure it's the problem in your case: the patch fixes the "pc = 0" problem both for partial symbol table (psymtab), and complete symbol table (symtab). Without this patch I get error even earlier. - Volodya Index: gdb/dwarf2read.c =================================================================== --- gdb/dwarf2read.c (revision 1679) +++ gdb/dwarf2read.c (revision 1680) @@ -3164,8 +3203,13 @@ labels are not in the output, so the relocs get a value of 0. If this is a discarded function, mark the pc bounds as invalid, so that GDB will ignore it. */ + /* VP: commented out of the same reason as in read_partial_die. + Damn the code duplication. + */ + #if 0 if (low == 0 && (bfd_get_file_flags (obfd) & HAS_RELOC) == 0) return 0; + #endif *lowpc = low; *highpc = high; @@ -5423,10 +5467,15 @@ labels are not in the output, so the relocs get a value of 0. If this is a discarded function, mark the pc bounds as invalid, so that GDB will ignore it. */ + /* VP: 2005/04/20: On NM, text segment starts at address 0, so disable + the check for zero. */ if (has_low_pc_attr && has_high_pc_attr && part_die->lowpc < part_die->highpc +#if 0 && (part_die->lowpc != 0 - || (bfd_get_file_flags (abfd) & HAS_RELOC))) + || (bfd_get_file_flags (abfd) & HAS_RELOC)) +#endif + ) part_die->has_pc_info = 1; return info_ptr; }