From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35808 invoked by alias); 2 Jun 2017 11:35:45 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 35781 invoked by uid 89); 2 Jun 2017 11:35:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=bob X-HELO: mail-yw0-f173.google.com Received: from mail-yw0-f173.google.com (HELO mail-yw0-f173.google.com) (209.85.161.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 02 Jun 2017 11:35:42 +0000 Received: by mail-yw0-f173.google.com with SMTP id l74so31853077ywe.2 for ; Fri, 02 Jun 2017 04:35:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bbeeEwV/vEAvUlPK4xM39TBghNf1IIXvQiMmBckeaQw=; b=Es2KNPxsIQMKPlKvYSWPUXmBYYQVeSViak3G5LLFO9gejt1WIgrcvwFllknv8Ys7Mu bIp8tWrFYS6LTC+qORgx6/3JqZAN9Wamn+Is8MAXudakcvfCSsHfVcHYInH8l9pGlNpr FIG+jo5kWoInbWopLELMIE4hTXylTOPv5FAX4WwvwIvuK5b1RXM9vCPvfIgMr67G/iPy 1QMqmHmQ6YGoRdJ9if9A2nTnJWS9s8QQLOdim39xuK6wCNYnqHVCRB4Yrkk1ahoDWe5K euJe2laI2jARdLABaWmDLGOd6eBnwYv6ZJBo9Yb2gpwc3Fr5VzCga27eZ2SmgY1Qn3f+ myEA== X-Gm-Message-State: AODbwcAUJbtgn68c8pEEfbx7hiBAiI0ZcgVnocVFHPS4O2Xy8fPELmfr HD/LKxcpj/If2g== X-Received: by 10.13.249.67 with SMTP id j64mr4947689ywf.19.1496403345050; Fri, 02 Jun 2017 04:35:45 -0700 (PDT) Received: from ?IPv6:2620:10d:c0a3:20fb:7500:e7fb:4a6f:2254? ([2620:10d:c091:200::7:3f92]) by smtp.googlemail.com with ESMTPSA id u73sm10096363ywc.78.2017.06.02.04.35.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 04:35:44 -0700 (PDT) Subject: Re: [PING**3] [PATCH] Force use of absolute path names for gcov To: Bernd Edlinger , Joseph Myers Cc: "gcc-patches@gcc.gnu.org" , Jan Hubicka References: <9e25bba6-46c0-b0f3-7af7-9149789551aa@acm.org> From: Nathan Sidwell Message-ID: <11b86b52-7420-08c4-0ccd-4dc476c69149@acm.org> Date: Fri, 02 Jun 2017 11:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-06/txt/msg00117.txt.bz2 On 06/01/2017 03:24 PM, Bernd Edlinger wrote: > This is a gcc option that converts relative > path names to absolute ones, so that gcov can > properly merge the line numbers in projects > where different relative path names may refer > to the same source file. Thanks. From reading the patch though, I didn't grok that intent. The patch itself suggests gcov simply fails with relative paths and directories. What you're really trying to do is find the canonical path, which happens to be absolute. But you're not doing that either -- you're concatenating the relative path to cwd. How is that helping? Is it when you have a mixture of absolute and relative paths? Some other cases: 1) 'bob/../foo.c' and 'baz/../foo.c'? 2) 'bob/foo.c' and 'baz/foo.c' where baz is a symlink to bob? 3) combinations of #2 and #3 such that textual elision of .. gets you to a different place than resolving symlinks. Given all that complexity, wouldn't it be better to tell gcov where relative paths should start? (perhaps encoding in the file?). It does need access to the source directories. note libiberty has lrealpath to do (much of?) what you want. nathan -- Nathan Sidwell