From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8165 invoked by alias); 22 Sep 2009 16:04:38 -0000 Received: (qmail 8090 invoked by uid 22791); 22 Sep 2009 16:04:36 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_53 X-Spam-Check-By: sourceware.org Received: from eu1sys200aog119.obsmtp.com (HELO eu1sys200aog119.obsmtp.com) (207.126.144.147) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 Sep 2009 16:04:31 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob119.postini.com ([207.126.147.11]) with SMTP ID DSNKSrj1jDO+ICQFgivXUbdioXvHquvod5sc@postini.com; Tue, 22 Sep 2009 16:04:31 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 70E8989 for ; Tue, 22 Sep 2009 16:04:27 +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 40FDB4C034 for ; Tue, 22 Sep 2009 16:04:27 +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 DGD38211 (AUTH lyon); Tue, 22 Sep 2009 18:05:33 +0200 (CEST) Message-ID: <4AB8F58A.5080405@st.com> Date: Tue, 22 Sep 2009 16:04:00 -0000 From: Christophe LYON User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: GDB cannot find line info References: <4AB79510.5000909@st.com> <4AB79D3E.8060806@st.com> In-Reply-To: <4AB79D3E.8060806@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/msg00291.txt.bz2 Hi, Merging the patch mentioned earlier does fix most of the regressions I introduced after "fixing" our compiler, but there is still 1 regression left, which I fail to understand. In langs.exp, I have now 1 failure: up #3 0x080003e4 in fsub_ () Current language: auto; currently fortran (gdb) FAIL: gdb.base/langs.exp: up to fsub in langs.exp Remember, the difference between a "langs" executable that passes the test, and one that fails is the correct inclusion of the full dirname of the source file in the debug_line directory table. I am using GDB 6.8 ported to ST200. I have dumped the debug information in various ways: * As suggested by Joel, with MI -symbol-list-lines Gives the very same results in both cases: (gdb) -symbol-list-lines langs1.c ^done,lines=[{pc="0x080003a0",line="24"},{pc="0x080003a4",line="0"},{pc="0x080003a4",line="25"},{pc="0x080003a8",line="0"},{pc="0x080 3a8",line="0"},{pc="0x080003b0",line="0"},{pc="0x080003bc",line="0"}] (gdb) -symbol-list-lines langs1.f ^done,lines=[{pc="0x080003a8",line="5"},{pc="0x080003b0",line="0"},{pc="0x080003b0",line="6"},{pc="0x080003bc",line="0"},{pc="0x08000 c",line="6"},{pc="0x080003c8",line="0"}] * Using "maintenance print symbols": - in the failing case, the data for "langs1.f" is dumped first, while it appears at the end of the dump in the other case. - in the failing case, langs1.c is prefixed with its full path name. * Using readelf -wl: - the failing case has 1 entry in the directory table for langs1.o (full dirname for langs1.c) and langs1.c references it. - In the executable which passes the test, the directory table for langs1.o is empty, and langs1.c has "0" as directory. In both cases, langs1.f has "0" as directory. * Using dwarfdump on langs1.o, - DW_AT_decl_file attributes pointing to langs1.c show the full path in the failing case, and langs1.f (full path) has the hostname as prefix. - In the object file which passes the test, the full path of langs1.c and langs1.f has always the hostname as prefix. - the same difference appears in the debug_line dump. It looks a bit like the problem I had several months ago (http://sourceware.org/ml/gdb-patches/2009-03/msg00617.html). All the information I managed to dump looks correct to me, but GDB is still unhappy :-( Any suggestion appreciated :-) Thanks Christophe.