From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30864 invoked by alias); 22 Oct 2004 12:28: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 30810 invoked from network); 22 Oct 2004 12:28:40 -0000 Received: from unknown (HELO NUTMEG.CAM.ARTIMI.COM) (217.40.111.177) by sourceware.org with SMTP; 22 Oct 2004 12:28:40 -0000 Received: from mace ([192.168.1.25]) by NUTMEG.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Oct 2004 13:27:57 +0100 From: "Dave Korn" To: , Subject: "Unrecognized demangle component" error Date: Fri, 22 Oct 2004 15:01:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 22 Oct 2004 12:27:57.0765 (UTC) FILETIME=[9009BF50:01C4B832] X-SW-Source: 2004-10/txt/msg00400.txt.bz2 I've got this big executable (that uses the wxWindows library, a huge C++ cross-platform gui api), built with gcc version (GCC) 3.3.3 (cygwin special) and binutils version GNU assembler 2.15.91 20040725 (they all report the same timestamp). When I try debugging it with gdb, I found that all the line number info was badly messed up. So I thought I'd take a look at the debugging info with objdump and see what I could see, and what I saw was this: ---------------------------------------- dk@mace /test> objdump -g macsim.exe macsim.exe: file format pei-i386 Unrecognized demangle component ---------------------------------------- Wow. I've never before come across an error message that brings up so few hits at google. That's probably because ILT only added it in January: http://sources.redhat.com/ml/binutils/2004-01/msg00192.html and I see from the following FIXME that it's not a big surprise that it sometimes fails: + /* FIXME: These are demangle component types which we probably + need to handle one way or another. */ Anyway, I don't know a lot about the interactions round here, but I was wondering if this problem could have had a knockon effect on gdb making it lose track of the line tables. I'm not too familiar with the internal gdb commands for trying to debug these problems, so I was wondering if anyone had a few suggestions to try? Here's an example of how wrong it goes: dk@mace /artimi/firmware/build/debug-i686-pc-cygwin/macsim> gdb ./macsim.exe GNU gdb 2003-09-20-cvs (cygwin-special) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) list main 29 } tBerPoint; 30 31 // This class should be specialised for concrete phy layers 32 class CphyLayer 33 { 34 public: 35 CphyLayer(){} 36 virtual ~CphyLayer(){} 37 38 // Frame detection (gdb) cheers, DaveK -- Can't think of a witty .sigline today....