From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25133 invoked by alias); 30 Mar 2006 14:32:27 -0000 Received: (qmail 25123 invoked by uid 22791); 30 Mar 2006 14:32:26 -0000 X-Spam-Check-By: sourceware.org Received: from mxout.hispeed.ch (HELO smtp.hispeed.ch) (62.2.95.247) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 30 Mar 2006 14:32:25 +0000 Received: from indel.ch (84-73-8-49.dclient.hispeed.ch [84.73.8.49]) by smtp.hispeed.ch (8.12.6/8.12.6/taifun-1.0) with SMTP id k2UEWLKc020756 for ; Thu, 30 Mar 2006 16:32:21 +0200 Received: from fabi.indel.ch [192.168.1.19] by indel.ch [127.0.0.1] with SMTP (MDaemon.v2.7.SP5.R) for ; Thu, 30 Mar 2006 16:32:22 +0200 Message-Id: <5.2.0.9.1.20060330162459.01fbe008@NT_SERVER> X-Sender: cenedese@NT_SERVER (Unverified) Date: Thu, 30 Mar 2006 18:22:00 -0000 To: gdb@sourceware.org From: Fabian Cenedese Subject: Re: stabs difference gcc 2.95.3 -> 3.4.3 In-Reply-To: <20060330140023.GA29500@nevyn.them.org> References: <5.2.0.9.1.20060330083638.01f6da00@NT_SERVER> <5.2.0.9.1.20060330083638.01f6da00@NT_SERVER> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: gdb@sourceware.org X-Return-Path: cenedese@indel.ch X-Virus-Status: Clean X-DCC-spamcheck-02.tornado.cablecom.ch-Metrics: smtp-04.tornado.cablecom.ch 32701; Body=1 Fuz1=1 Fuz2=1 X-IsSubscribed: yes 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: 2006-03/txt/msg00222.txt.bz2 >> This is the working file of gcc 2.95.3, looking up _TASK_CLASS_NAME_::Action: >> GNU gdb 6.2.50_2004-10-14-cvs > >First of all, this is an older GDB. You might want to try a current >one. That was just lying around from my last experiments. As it worked fine with output of the older gcc I had no reason (yet) to upgrade. >Secondly, since you're trying to debug C++ with stabs, the basic >reaction is that you'll get what you deserve - the stabs produced >by GCC are missing a lot of information that's available in the default >DWARF-2 format. Well, as the currently used compiler 2.95.3 is even older and I supposed that the stabs format should be compatible I didn't especially try the newest versions but I may now. >> First thing: why does gdb say that the function is in a file compiled without >> debugging when it still knows where to find it? > >We'd need a testcase, sorry. But this is likely to be related to... > >> Second thing: why is the assembler file given as source file? Of course it >> _is_ the source file given our two steps compiling. But the same was true >> with the old tool chain where it worked fine. Also, in the generated assembler >> file is the first line a directive: >> .file "CTaskTemplateClass.cpp" >> so it should be clear where this code comes from. > >... this. I thought so. When I do it in one step it works better, still not perfect though. >Probably gas has been passed the -g option, and generated >its own debug information, which caused GDB to see debug info for the >assembly file instead of for the source file. You might want to check >that. The -g is given to gcc, I don't know if that gets passed on to as. But so was the setup with the older compiler as well, where it worked. >> Just for checking if this would work better I also tried -gdwarf-2. Got even worse: >> GNU gdb 6.2.50_2004-10-14-cvs >> This GDB was configured as "--host=i686-pc-cygwin --target=powerpc-eabi"...Dwarf Error: Could not find abbrev number 128 >> [in module /cygdrive/n/IMD/Bin/Gnu32_new/gcc3.x] > >Either this is a linker bug, or a GDB bug. In either case, it is >almost certainly fixed in current versions of either. The current >releases are GCC 4.1.0, binutils 2.16.1, and GDB 6.4. Hehe... I almost expected this answer, that's the same we tell our customers when they don't have our newest tools. I'll see what I can do. Thanks for answering. bye Fabi