From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6736 invoked by alias); 22 Apr 2003 22:18:17 -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 6727 invoked from network); 22 Apr 2003 22:18:16 -0000 Received: from unknown (HELO cygnus.equallogic.com) (65.170.102.10) by sources.redhat.com with SMTP; 22 Apr 2003 22:18:16 -0000 Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id h3MMIGt32460 for ; Tue, 22 Apr 2003 18:18:16 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id h3MMIGr32454 for ; Tue, 22 Apr 2003 18:18:16 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id h3MMIFZ29278 for ; Tue, 22 Apr 2003 18:18:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16037.49033.658180.401145@pkoning.dev.equallogic.com> Date: Tue, 22 Apr 2003 22:18:00 -0000 From: Paul Koning To: gdb@sources.redhat.com Subject: trouble with gdb 5.3, gcc 3.4, mips, dwarf-2 X-SW-Source: 2003-04/txt/msg00260.txt.bz2 Gentlepeople, I'm not sure how best to attack this so I'm starting here... I have a slightly modified gdb 5.3 that's given me a bunch of nasty problems on a MIPS target. Given what I'm seeing, it's unlikely that the local changes are the cause (minor tweaks to mips-tdep, plus a bunch of extensions -- but nothing in the guts of type handling or symbol table reading). In the process of trying to look for solutions, I tried building a current snapshot of gcc for my target. After some struggles, I have a build that worked (it doesn't execute -- but at least it links). Gdb 5.3 acts very strangely as a result. When I tried to cast a pointer to a C++ class type, it complained about a parse error. "ptype" explains why -- gdb didn't recognize the name as a class name, it took it for a function name. I reduced it to a simple test case: class test { public: int z; void foo(int i) { z = i; } }; class bar : public test { public: int m; int x; bar(int); void test(int i) { m = i; } }; bar::bar(int i) { x = i; m = i*3; } int errno; int exit; bar *bp; int main (int, char**) { bp = new bar(16); } Compiled with -gdwarf-2, I see this: (gdb) ptype bar type = void (bar * const, int) Compiled with -gstabs+, I get what I expect: (gdb) ptype bar type = class bar : public test { public: int m; int x; bar & operator=(bar const&); bar(bar const&); bar(int); void test(int); } Obviously this could be a gdb problem or a gcc problem. How can I tell? I've poked in both, but only around the edges. FWIW, the problems that drove me to try this experiment are: 1. For some functions (involving C++ classes with templates and multiple inheritance, that may or may not be relevant, I don't know yet) breakpoints aren't hit. Single stepping through the code causes nonsensical line numbers to be displayed, jumping wildly over several source files as the PC advances by one or two instructions. 2. We see a bunch of symtab vs. psymtab mismatch errors. The easiest way to see it is to issue "maint check-symtabs" on gdb startup; it complains bitterly about large quantities of errors (all C++ mangled names). Any suggestions? Thanks, paul