From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28136 invoked by alias); 21 Sep 2009 15:35:39 -0000 Received: (qmail 28127 invoked by uid 22791); 21 Sep 2009 15:35:37 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from eu1sys200aog101.obsmtp.com (HELO eu1sys200aog101.obsmtp.com) (207.126.144.111) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Sep 2009 15:35:31 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob101.postini.com ([207.126.147.11]) with SMTP ID DSNKSredP6Ok/OVYmaxyty/LmMwwj1M9M13Q@postini.com; Mon, 21 Sep 2009 15:35:30 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 9A444196; Mon, 21 Sep 2009 15:35:26 +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 697664C4C4; Mon, 21 Sep 2009 15:35:26 +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 DGC47597 (AUTH lyon); Mon, 21 Sep 2009 17:36:32 +0200 (CEST) Message-ID: <4AB79D3E.8060806@st.com> Date: Mon, 21 Sep 2009 15:35: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: <4AB79510.5000909@st.com> In-Reply-To: <4AB79510.5000909@st.com> 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/msg00274.txt.bz2 I have investigated a bit more, and the GDB patch actually seems to match perfectly my compiler behavior... maybe it was designed for another port of Open64 ;-) For the record, debug_line describes only the source file basename + reference to the full path, while debug_info uses the full path name. Hence, the same basename appears twice in GDB line table, but one of the entries has an empty line table (the one from debug_info). Thanks for your help! Christophe. On 21.09.2009 17:00, Christophe LYON wrote: > 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. >>> >> > >