From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90624 invoked by alias); 2 Jun 2017 14:43:27 -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 90607 invoked by uid 89); 2 Jun 2017 14:43:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=admit, H*r:10.152.8, H*f:sk:11b86b5, Hx-languages-length:3157 X-HELO: EUR02-VE1-obe.outbound.protection.outlook.com Received: from mail-oln040092069065.outbound.protection.outlook.com (HELO EUR02-VE1-obe.outbound.protection.outlook.com) (40.92.69.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 02 Jun 2017 14:43:24 +0000 Received: from AM5EUR02FT013.eop-EUR02.prod.protection.outlook.com (10.152.8.56) by AM5EUR02HT021.eop-EUR02.prod.protection.outlook.com (10.152.9.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1101.12; Fri, 2 Jun 2017 14:43:25 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com (10.152.8.52) by AM5EUR02FT013.mail.protection.outlook.com (10.152.8.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.12 via Frontend Transport; Fri, 2 Jun 2017 14:43:25 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com ([fe80::2073:585b:84f6:9881]) by AM4PR0701MB2162.eurprd07.prod.outlook.com ([fe80::2073:585b:84f6:9881%17]) with mapi id 15.01.1143.013; Fri, 2 Jun 2017 14:43:25 +0000 From: Bernd Edlinger To: Nathan Sidwell , Joseph Myers CC: "gcc-patches@gcc.gnu.org" , Jan Hubicka Subject: Re: [PING**3] [PATCH] Force use of absolute path names for gcov Date: Fri, 02 Jun 2017 14:43:00 -0000 Message-ID: References: <9e25bba6-46c0-b0f3-7af7-9149789551aa@acm.org> <11b86b52-7420-08c4-0ccd-4dc476c69149@acm.org> In-Reply-To: <11b86b52-7420-08c4-0ccd-4dc476c69149@acm.org> authentication-results: acm.org; dkim=none (message not signed) header.d=none;acm.org; dmarc=none action=none header.from=hotmail.de; x-incomingtopheadermarker: OriginalChecksum:5DD90648FF252384760D61E1574F153E52C468FEEEA9A9ACF00F6B4BBEE600AC;UpperCasedChecksum:62C4229D71E351EEA709DB9DC7292C57555C1120B1AA43A77AA37485720FE8B5;SizeAsReceived:9058;Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [SmqyEt131rkdW/M1PdeZ5uCnvOhZj1cM] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;AM5EUR02HT021;24:cVgflZ/4Q+c0NQ75LI0spQYDA65aWQy7zi7L8vXnL7H9zpMTW4fuzIsWvuCsfbvpy52aeeUyWJBtBEHYbmroz2kUfF2fiHnm3xIAbxacpVA=;7:Dqm14RZI+ApWbbsfeuYO1GlH6+PII6OTQ206cdkfg1KtXl7YUu+0d3TkZx8iVgjsZmD4gacctrxFDodzCpHCymef+SfreO09VylgMWfIEyWU3GRfVakBdePBUe0f1xoD+8mwVml9gfORnAy9RvH4lR6Petigc68fWtJrCuXPlhd8YE458IlOi8SrrNeevdeQkl8Rb33g6CYPux620Kn0UsPdN/P3VoIQXG771Q9Qt82cyqGD4nJcD7QJ/ddaybTN9QV4ou+JvJmLUIj/4RNyN+KrqsVpm6qlUATtTAaQekMHe2eJQuAtUxisv8LVRIRC x-incomingheadercount: 46 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI;SFV:NSPM;SFS:(7070007)(98901004);DIR:OUT;SFP:1901;SCL:1;SRVR:AM5EUR02HT021;H:AM4PR0701MB2162.eurprd07.prod.outlook.com;FPR:;SPF:None;LANG:en; x-ms-traffictypediagnostic: AM5EUR02HT021: x-ms-office365-filtering-correlation-id: 47ec59e6-0aa5-4af6-48d7-08d4a9c5b8ed x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045);SRVR:AM5EUR02HT021; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031);SRVR:AM5EUR02HT021;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:AM5EUR02HT021; x-forefront-prvs: 03264AEA72 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: <15F6F79F668CCF47AC7E341C23FA30BA@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2017 14:43:25.6198 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR02HT021 X-SW-Source: 2017-06/txt/msg00138.txt.bz2 On 06/02/17 13:35, Nathan Sidwell wrote: > On 06/01/2017 03:24 PM, Bernd Edlinger wrote: >=20 >> 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. >=20 > Thanks. From reading the patch though, I didn't grok that intent. The=20 > patch itself suggests gcov simply fails with relative paths and=20 > directories. What you're really trying to do is find the canonical=20 > path, which happens to be absolute. But you're not doing that either --= =20 > you're concatenating the relative path to cwd. How is that helping? Is=20 > it when you have a mixture of absolute and relative paths? >=20 Yes, let me explain why I need that. Recently I wanted to get the line-coverage of an application I work with. The problem I faced is, that different modules invoke gcc in different working directories, and there are things like -I ../include in one place, and -I ../../Core/include in other places, so ../include/test.h and ../../Core/include/test.h may or may not refer to the same file. Also several module tests use a separate folder, and a file like "./Test1.cpp" may actually exist in several directories, but gcov does not find the sources, in this scenario and copying everything to a single directory is not a good solution either. So in the end I want to run the different module tests etc. and let gcov collect and merge all the coverage data, and of course find the right source files for the report, without substantially changing the application's original make files. > 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= =20 > a different place than resolving symlinks. >=20 > Given all that complexity, wouldn't it be better to tell gcov where=20 > relative paths should start? (perhaps encoding in the file?). It does=20 > need access to the source directories. >=20 gcov.c already has a function named canonicalize_name that does exactly what I need, i.e. elide /./ and collapse ../bob/../foo.c to ../foo.c and even do something with symbolic links, however my app does not use any sym-links so I did not really test that part. But this function works only under the assumption that relative file=20 names start always from the current working directory. So what my patch does, is leave absolute file names untouched and prepend the current working directory to all file names that do not look like absolute file names. Thus it does not claim to canonicalize the file name, but only to make it an absolute file name. But now gcov's canonicalize_name is actually able to do the rest. At least in my real-word application this did the trick. But I must admit the test case does not prove more than that the option is not causing an error, especially because the test suite uses absolute path names. Is it now clear? Thanks Bernd. > note libiberty has lrealpath to do (much of?) what you want. >=20 > nathan >=20