From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12851 invoked by alias); 21 Sep 2009 15:00:45 -0000 Received: (qmail 12833 invoked by uid 22791); 21 Sep 2009 15:00:42 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from eu1sys200aog103.obsmtp.com (HELO eu1sys200aog103.obsmtp.com) (207.126.144.115) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Sep 2009 15:00:38 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob103.postini.com ([207.126.147.11]) with SMTP ID DSNKSreVEgeEomM6rRbjfpXpa1KSNTcbY8t7@postini.com; Mon, 21 Sep 2009 15:00:37 UTC Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 39E9932D; Mon, 21 Sep 2009 15:00:33 +0000 (GMT) Received: from mail2.gnb.st.com (mail2.gnb.st.com [164.129.119.59]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id D123A4C4A1; Mon, 21 Sep 2009 15:00:32 +0000 (GMT) Received: from [164.129.122.40] (gnx2504.gnb.st.com [164.129.122.40]) by mail2.gnb.st.com (MOS 3.8.7a) with ESMTP id DGC46394 (AUTH lyon); Mon, 21 Sep 2009 17:01:38 +0200 (CEST) Message-ID: <4AB79510.5000909@st.com> Date: Mon, 21 Sep 2009 15:00:00 -0000 From: Christophe LYON User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: Robert Bu Cc: gdb@sourceware.org Subject: Re: GDB cannot find line info References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00271.txt.bz2 Hi Robert, Thanks for the suggestion, indeed it has fixed my problem, though I don't really understand why :-) I tried Joel's suggestion, and indeed the line table is empty. I have tried comparing the output of "maintenance print symbols" between executable files generated by 2 compilers (on break.c from the testsuite), and: * with the compiler with the bug (incorrect source directory), Symtab for break.c appears once, with a line table * with the compiler with my fix, Symtab for break.c appears twice, once with only "break.c" and no line table, and once with the full path to "break.c" and the right line table. Christophe. On 21.09.2009 09:45, Robert Bu wrote: > Hi Christophe, > > Maybe you can try the CVS head or the 7.0 preview. I've once met the > same problem. And the problem is gone in CVS. Actually the problem is > fixed by the newly added function "watch_main_source_file_lossage > (void)" in buildsym.c > > Robert. > >> >> Hello, >> >> I have found a bug in our compiler (Open64 for ST200), which I have >> fixed to make it correctly output the directory table related to >> debug_line info. >> But now, I have many regressions in the GDB testsuite (6.8), the first >> one being in break.exp: now the command "break break.c:103" returns >> 'No line 103 in file "break.c"' >> >> I have dumped the dwarf debug_line info with 'dwarfdump -l' and >> 'readelf -wl', but could not find anything suspect: >> - with dwarfdump, the only difference is in the directory path >> - with readelf, the directory tables contain one more entry (absolute >> path to gdb.base) and the file table has dir numbers updated >> accordingly. (obviously, the length and offset of the corresponding >> sections are different) >> >> Is there any GDB internal command I could use to understand the problem? >> >> Thanks, >> >> Christophe. >> >