From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8801 invoked by alias); 30 Mar 2009 08:35:02 -0000 Received: (qmail 7693 invoked by uid 22791); 30 Mar 2009 08:34:49 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32,J_CHICKENPOX_34,J_CHICKENPOX_84 X-Spam-Check-By: sourceware.org Received: from eu1sys200aog117.obsmtp.com (HELO eu1sys200aog117.obsmtp.com) (207.126.144.143) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Mar 2009 08:34:44 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob117.postini.com ([207.126.147.11]) with SMTP ID DSNKSdCEB2iyuDZgKuoBec0155g9oC0E4Sio@postini.com; Mon, 30 Mar 2009 08:34:43 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 E92D5DABC; Mon, 30 Mar 2009 08:33:02 +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 862F54C1C3; Mon, 30 Mar 2009 08:34:05 +0000 (GMT) Received: from [164.129.122.46] (gnx2504.gnb.st.com [164.129.122.46]) by mail2.gnb.st.com (MOS 3.8.7a) with ESMTP id DBN19990 (AUTH lyon); Mon, 30 Mar 2009 10:34:01 +0200 (CEST) Message-ID: <49D083FB.6020108@st.com> Date: Mon, 30 Mar 2009 13:51:00 -0000 From: Christophe LYON User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] obvious pattern fix in gdb.base/step-line.exp References: <49CCDB3D.5010302@st.com> <20090327184726.GW9472@adacore.com> In-Reply-To: <20090327184726.GW9472@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-03/txt/msg00666.txt.bz2 Hello Joel, On 27.03.2009 19:47, Joel Brobecker wrote: > Hello Christophe, > >> 2009-03-27 Christophe Lyon >> >> testsuite/ >> * gdb.base/step-line.exp: Fix pattern to allow full path before >> "step-line.c". > > I'd love to have some feedback from the other maintainers on this one. > > My first observation is that it doesn't fail for me when testing > out-of-tree, using either DWARF or stabs. So I'm wondering why > this is failure in Chistophe's case. Perhaps a dump of your debugging > information (filename/dirname info for step-line.c and the line table > as well) would allows to understand the difference. > > That being said, I don't see that we make a guaranty at the user-level > that the name of the file will be printed using either its full path or > just the basename, or anthing in the middle. So we could argue that > the output with the full path is equally valid and that the expected > output should therefore be enhanced to accept both. > > WDYT? I forgot to mention that before submitting the patch, I grepped in gdb.base and gdb.cp to see how other tests expect the filename to be printed. Maybe I missed some of them, but I noticed that step-line.c was the only one not using .*$srcfile. So I thought it had been forgotten. Yet, this is not an explanation of why it fails :-) I am not using GCC, but a retargetting of Open64 for one of our internal targets. Maybe people from Tensilica or PathScale have already noticed the same issue. If I dump the Dwarf info (using dwarfdump and readelf), I can see the full path name in DW_AT_name for the compile_unit (I tried to call runtest with absolute and relative --srcdir, and in both cases the test fails). For DW_AT_comp_dir, I have the expected hostname:absolute_path string. Comparing with GCC, there is a difference in the DW_AT_comp_dir, where GCC does not print the hostname prefix. But my understanding of the Dwarf spec is that hostname:path should be used, isn't it? Anyway GDB seems to be able to cope with this (see read_file_scope in dwarf2read.c). Still with GCC, I notice that if I use an absolute source file name, there is no DW_AT_comp_dir. To summarize, when using an absolute src file name: * GCC: DT_AT_name=absolute src file name DW_AT_comp_dir: not present Directory table in debug_line: absolute path to `dirname $srcfile` The File Name Table: Entry Dir Time Size Name 1 1 0 0 step-line.c 2 0 0 0 step-line.c 3 0 0 0 step-line.inp * Open64: DT_AT_name=absolute src file name DW_AT_comp_dir=hostname:absolute `pwd` Directory table in debug_line: - absolute path to `dirname $srcfile` - absolute `pwd` The File Name Table: Entry Dir Time Size Name 1 1 0 0 step-line.c 2 2 0 0 step-line.inp So... it may be an issue with my compiler handling of #line? Thanks, Christophe.