From patchwork Mon Nov 14 19:51:10 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Alen Skondro X-Patchwork-Id: 125601 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id B5C62B7211 for ; Tue, 15 Nov 2011 06:51:31 +1100 (EST) Received: (qmail 1685 invoked by alias); 14 Nov 2011 19:51:27 -0000 Received: (qmail 1666 invoked by uid 22791); 14 Nov 2011 19:51:26 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-iy0-f175.google.com (HELO mail-iy0-f175.google.com) (209.85.210.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Nov 2011 19:51:11 +0000 Received: by iahk25 with SMTP id k25so7188357iah.20 for ; Mon, 14 Nov 2011 11:51:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.65.79 with SMTP id xl15mr24265303icb.6.1321300270781; Mon, 14 Nov 2011 11:51:10 -0800 (PST) Received: by 10.42.178.194 with HTTP; Mon, 14 Nov 2011 11:51:10 -0800 (PST) In-Reply-To: <4EBE5C50.1020804@acm.org> References: <4EBE5C50.1020804@acm.org> Date: Mon, 14 Nov 2011 20:51:10 +0100 Message-ID: Subject: Re: gcov patch, multiple paths From: Alen Skondro To: Nathan Sidwell Cc: GCC Patches X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org 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 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 > 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 +