From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30432 invoked by alias); 6 Aug 2010 18:20:12 -0000 Received: (qmail 30253 invoked by uid 22791); 6 Aug 2010 18:20:11 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail3.caviumnetworks.com (HELO mail3.caviumnetworks.com) (12.108.191.235) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Aug 2010 18:20:01 +0000 Received: from caexch01.caveonetworks.com (Not Verified[192.168.16.9]) by mail3.caviumnetworks.com with MailMarshal (v6,7,2,8378) id ; Fri, 06 Aug 2010 11:20:29 -0700 Received: from caexch01.caveonetworks.com ([192.168.16.9]) by caexch01.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Aug 2010 11:20:00 -0700 Received: from dd1.caveonetworks.com ([12.108.191.236]) by caexch01.caveonetworks.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Aug 2010 11:20:00 -0700 Message-ID: <4C5C524B.6040904@caviumnetworks.com> Date: Fri, 06 Aug 2010 18:20:00 -0000 From: David Daney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100720 Fedora/3.0.6-1.fc12 Thunderbird/3.0.6 MIME-Version: 1.0 To: Bruce Korb CC: gcc@gcc.gnu.org, bug-gdb@gnu.org, insight@sourceware.org Subject: Re: Bizarre GCC problem - how do I debug it? References: <4C5C4433.60302@gmail.com> <4C5C453D.4090704@caviumnetworks.com> <4C5C4B8A.7090303@gmail.com> In-Reply-To: <4C5C4B8A.7090303@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact insight-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sourceware.org X-SW-Source: 2010-q3/txt/msg00020.txt.bz2 On 08/06/2010 10:51 AM, Bruce Korb wrote: > On 08/06/10 10:24, David Daney wrote: >> On 08/06/2010 10:19 AM, Bruce Korb wrote: >>> The problem seems to be that GDB thinks all the code belongs to a >>> single line of text. At first, it was a file of mine, so I presumed >>> I had done something strange and passed it off. I needed to do some >>> more debugging again and my "-g -O0" output still said all code >>> belonged to that one line. So, I made a .i file and compiled that. >>> Different file, but the same problem. The .i file contains the >>> correct preprocessor directives: >>> >>> # 309 "wrapup.c" >>> static void >>> done_check(void) >>> { >>> >>> but under gdb: >>> >>> (gdb) b done_check >>> Breakpoint 5 at 0x40af44: file /usr/include/gmp.h, line 1661. >>> >>> the break point *is* on the entry to "done_check", but the >>> source code displayed is line 1661 of gmp.h. Not helpful. >>> Further, I cannot set break points on line numbers because >>> all code belongs to the one line in gmp.h. >>> >>> Yes, for now I can debug in assembly code, but it isn't very easy..... >>> >>> $ gcc --version >>> gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292] >>> Copyright (C) 2010 Free Software Foundation, Inc. >>> This is free software; see the source for copying conditions. There >>> is NO >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>> PURPOSE. >>> >>> I've googled for: gcc|gdb wrong source file >>> which only yields how to examine source files in gdb. >>> >> >> Which version of GDB? >> >> IIRC with GCC-4.5 you need a very new version of GDB. This page: >> >> http://gcc.gnu.org/gcc-4.5/changes.html >> >> indicates that GDB 7.0 or later would be good candidates. > > That seems to work. There are one or two or three bugs then. > Either gdb needs to recognize an out of sync object code It cannot do this as it was released before GCC-4.5. > , or else > gcc needs to produce object code that forces gdb to object in a way > more obvious than just deciding upon the wrong file and line -- > or both. I simply installed the latest openSuSE and got whatever > was supplied. It isn't reasonable to expect folks to go traipsing > through upstream web sites looking for "changes.html" files .... > > And, of course, the insight stuff needs to incorporate the latest > and greatest gdb. (I don't use ddd because it is _completely_ non- > intuitive.) > My understanding is that whoever packages GCC and GDB for a particular distribution is responsible to make sure that they work together. In your case it looks like that didn't happen. David Daney