gcov patch, multiple paths

Message ID	CAH9D60rATnkcKhr2YaTUzvJUBDuT-sRr-XUWYcb=H6WU3fCD-g@mail.gmail.com
State	New
Headers	show Return-Path: <gcc-patches-return-307784-incoming=patchwork.ozlabs.org@gcc.gnu.org> MIME-Version: 1.0 In-Reply-To: <4EBE5C50.1020804@acm.org> References: <4EBE5C50.1020804@acm.org> Date: Mon, 14 Nov 2011 20:51:10 +0100 Message-ID: <CAH9D60rATnkcKhr2YaTUzvJUBDuT-sRr-XUWYcb=H6WU3fCD-g@mail.gmail.com> Subject: Re: gcov patch, multiple paths From: Alen Skondro <askondro@gmail.com> To: Nathan Sidwell <nathan@acm.org> Cc: GCC Patches <gcc-patches@gcc.gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk Sender: gcc-patches-owner@gcc.gnu.org

Message ID

CAH9D60rATnkcKhr2YaTUzvJUBDuT-sRr-XUWYcb=H6WU3fCD-g@mail.gmail.com

State

New

Headers

MIME-Version: 1.0
In-Reply-To: <4EBE5C50.1020804@acm.org>
References: <4EBE5C50.1020804@acm.org>
Date: Mon, 14 Nov 2011 20:51:10 +0100
Message-ID: <CAH9D60rATnkcKhr2YaTUzvJUBDuT-sRr-XUWYcb=H6WU3fCD-g@mail.gmail.com>
Subject: Re: gcov patch, multiple paths
From: Alen Skondro <askondro@gmail.com>
To: Nathan Sidwell <nathan@acm.org>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
Sender: gcc-patches-owner@gcc.gnu.org

Commit Message

Alen Skondro Nov. 14, 2011, 7:51 p.m. UTC

This breaks the mingw64 build with S_ISLNK being unresolved.

Since windows doesn't know anything about symbolic links, could
something like this help?


On Sat, Nov 12, 2011 at 12:45, Nathan Sidwell <nathan@acm.org> wrote:
> Hi,
> I've committed this patch to gcov,  It deals with cases where the same
> header file, containing inline functions etc, is included by multiple
> different pathnames.  The current behavior treats these as distinct sources,
> which is (a) misleading and (b) in the absence of -p all but one instance of
> the resulting .gcov file will be overwritten.
>
> We now canonicalize the names of source files by eliding '.' components
> always and eliding 'dir/..' components where possible.  We can't resolve a
> 'dir/..' component when 'dir' is a symlink.  We also canonicalize \\ path
> separators.
>
> I discovered some faults with the preserve-pathname mangling, in that it
> didn't match the documented behaviour ('.' wasn't elided, and /../ turned
> into '#..#^'.  These are fixed with this patch too.
>
> I updated the documentation to make it clear you can provide either source
> or object filenames to gcov.  Historically it accepted source files, but
> with current inlining and C++ features, it makes more sense to provide the
> object file names, especially in multi-directory builds.
>
> tested on i686-pc-linux-gnu
>

Comments

Nathan Sidwell Nov. 14, 2011, 8:17 p.m. UTC | #1

On 11/14/11 19:51, Alen Skondro wrote:
> This breaks the mingw64 build with S_ISLNK being unresolved.
>
> Since windows doesn't know anything about symbolic links, could
> something like this help?

thanks, Joseph also pointed this out to me.  I have a slightly different patch 
in testing (posix specifies, when provided, IS_LNK to be a macro).  I'll be 
committing a patch shortly, once testing some visibility changes complete.

diff --git a/gcc/config/i386/xm-mingw32.h b/gcc/config/i386/xm-mingw32.h
index e0dd3f3..34663ac 100644
--- a/gcc/config/i386/xm-mingw32.h
+++ b/gcc/config/i386/xm-mingw32.h
@@ -33,3 +33,7 @@  along with GCC; see the file COPYING3.  If not see
 /* MSVCRT does not support the "ll" format specifier for printing
    "long long" values.  Instead, we use "I64".  */
 #define HOST_LONG_LONG_FORMAT "I64"
+
+/* Windows doesn't know about symbolic links. */
+#define S_ISLNK(x) false
+