From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18518 invoked by alias); 31 Mar 2009 13:46:18 -0000 Received: (qmail 18497 invoked by uid 22791); 31 Mar 2009 13:46:15 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from eu1sys200aog106.obsmtp.com (HELO eu1sys200aog106.obsmtp.com) (207.126.144.121) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 31 Mar 2009 13:46:09 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob106.postini.com ([207.126.147.11]) with SMTP ID DSNKSdIeifPEG8enVwshDYDy0B7FZ8aY0K5G@postini.com; Tue, 31 Mar 2009 13:46:09 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 BC01CDAD5; Tue, 31 Mar 2009 13:44:30 +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 0147E4C4F7; Tue, 31 Mar 2009 13:45:34 +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 DBO30650 (AUTH lyon); Tue, 31 Mar 2009 15:45:31 +0200 (CEST) Message-ID: <49D21E7E.8080708@st.com> Date: Tue, 31 Mar 2009 15:25:00 -0000 From: Christophe LYON User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: Joel Brobecker , 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> <49D083FB.6020108@st.com> <20090330170216.GB9472@adacore.com> In-Reply-To: <20090330170216.GB9472@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/msg00700.txt.bz2 On 30.03.2009 19:02, Joel Brobecker wrote: >> So... it may be an issue with my compiler handling of #line? > > Not quite sure from the dump what exactly causes the change of behavior, > I would need to look at the code more precisely, and I'm a little rush > right now. > > But since I believe that printing the full name is perfectly valid (in > fact, I later verified that this is what happens with Ada files as well, > even though the debug info looks similar to what we get with step-line.c), > it's fine to commit your patch. > Hi Joel, I have investigated a bit more... and I think I found a bug in our compiler. But I am not 100% sure how to interpret the ANSI C spec regarding the #line directive: when the name of the source file has no path (as in step-line.c, where #line xx "step-line.c" is used), which path should be considered? Indeed, as mentioned before, my compiler generates the following file table: Entry Dir Time Size Name 1 1 0 0 step-line.c 2 2 0 0 step-line.inp while GCC generates: 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 (and uses the 2nd entry for the #line directives). I changed my compiler to behave as GCC, and I got the same behavior under GDB. So... is this a bug in the test, in my compiler? If in my compiler, then I am not sure it's a good idea to apply my fix to the testsuite :-) Thanks, Christophe.