From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32149 invoked by alias); 30 Mar 2006 07:11:51 -0000 Received: (qmail 32140 invoked by uid 22791); 30 Mar 2006 07:11:50 -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 07:11:49 +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 k2U7Biku015754 for ; Thu, 30 Mar 2006 09:11:45 +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 09:11:41 +0200 Message-Id: <5.2.0.9.1.20060330083638.01f6da00@NT_SERVER> X-Sender: cenedese@NT_SERVER (Unverified) Date: Thu, 30 Mar 2006 14:00:00 -0000 To: gdb@sourceware.org From: Fabian Cenedese Subject: stabs difference gcc 2.95.3 -> 3.4.3 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-01.tornado.cablecom.ch-Metrics: smtp-06.tornado.cablecom.ch 32700; 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/msg00219.txt.bz2 Hi The following is about a cross-compiled tool chain, both gcc and gdb are running on cygwin but the target is a PPC embedded board. I don't know if the problem lies with gcc or gdb. We have an older tool chain with gcc 2.95.3. We compile our cpp files in two steps, basically 1. gcc -S file.cpp -o file.s 2. gcc file.s -o file.o We do this as we need both the assembler file and binary. These binaries get then linked together with ld and a linker script. This works fine. 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 Copyright 2004 Free Software Foundation, Inc. This GDB was configured as "--host=i686-pc-cygwin --target=powerpc-eabi"... (gdb) info address _TASK_CLASS_NAME_::Action Symbol "Action__17_TASK_CLASS_NAME_" is a function at address 0x153c. (gdb) info line '_TASK_CLASS_NAME_::Action(void)' Line 128 of "N:\Indel-PPC\Tests\gcc3\applicat\src\CTaskTemplateClass.cpp" starts at address 0x153c and ends at 0x155c . We now wanted to upgrade and tried the same with gcc 3.4.3. To stay as much compatible to our other tools as possible we use -gstabs+ even if this is not the default format. However this gives some different results. Now doing the same with the result of gcc 3.4.3: GNU gdb 6.2.50_2004-10-14-cvs Copyright 2004 Free Software Foundation, Inc. This GDB was configured as "--host=i686-pc-cygwin --target=powerpc-eabi"... (gdb) info address _TASK_CLASS_NAME_::Action Symbol "_TASK_CLASS_NAME_::Action" is at 0x1650 in a file compiled without debugging. (gdb) info line '_TASK_CLASS_NAME_::Action()' Line 128 of "N:\Indel-PPC\Tests\gcc3\bin343\CTaskTemplateClass.s" starts at address 0x1650 <_ZN17_TASK_CLASS_NAME_6ActionEv> and ends at 0x1668 <_ZN17_TASK_CLASS_NAME_6ActionEv+24>. First thing: why does gdb say that the function is in a file compiled without debugging when it still knows where to find it? 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. Now: Is this a gdb or a gcc problem? Is there some switch or something that may help me further or is the stabs support in gcc regressing as mentioned in this post by Michael Chastain: http://gcc.gnu.org/ml/gcc/2004-07/msg00479.html Is there sense in posting this to the gcc list? 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] As we would like to stay on stabs I didn't pursue this further but it wasn't very promising. Thanks for reading this lengthy mail. bye Fabi