From patchwork Thu Feb 20 13:21:30 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Edlinger X-Patchwork-Id: 1241418 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-519851-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=hotmail.de Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha1 header.s=default header.b=AzlB3Wq+; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 48NZxN742Bz9sP7 for ; Fri, 21 Feb 2020 00:21:43 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:content-type:mime-version; q=dns; s= default; b=W9DBxriB9xWJ10dwhBFD1rZRmX9RzlCgC0fnSPXji3zUGlALwMcbW rgiK3E6hEH1+c4RzSKlpDi7f7AM0PMN/vVKk4EhYp/ROjchMDxwenwn4jxdurJC+ mMxFcL60hFntzMzT5X/Z19paUumncWbfqBxkwCJlJd4d+mOiIbNWsY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:content-type:mime-version; s= default; bh=VTL2jCPR2Fjq3T532dH65Ci3KbA=; b=AzlB3Wq+7rrl4ZOgwVSa ys761nTHK+BdoR1ph12nWaVNkOn4KM2dqFw/vLmiu9LGEREb3FFJzBrcle/308ke ABi3r7ZznC/u92a9u5FsfBWQNxPgZyKbUXPLutZ3rDUpNg2C/D8aJkVaiHNvnHdw zHa2TSLp9KcKIOp/y75LlI8= Received: (qmail 114840 invoked by alias); 20 Feb 2020 13:21:35 -0000 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 Received: (qmail 114829 invoked by uid 89); 20 Feb 2020 13:21:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-21.9 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.1 spammy=H*RU:sk:HE1EUR0, HX-Spam-Relays-External:sk:HE1EUR0, H*c:HHH X-HELO: EUR04-HE1-obe.outbound.protection.outlook.com Received: from mail-oln040092073099.outbound.protection.outlook.com (HELO EUR04-HE1-obe.outbound.protection.outlook.com) (40.92.73.99) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Feb 2020 13:21:33 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FHivzOnyyR1l5sI9eqQLGm4Pn5yFBCgt3P1j/l07D/dvooFBfDR8vv4ah9r9T2YiJCf33v70Z9ww4TUewOASYhGzLmNDiJxl7qlQYZb3PH4B4SjtDdMbj7UJOCs+b0C7bwOfXv+I8pvJysinf6esBH4BTo1zBKRunCraCdp50pXUzmB7t9naidgVqHadDu1c9aadkr5ejAHpa3/4RKIvCTZi04n0H3A44SXC0SLL9VsWxH6guIHIchBH2LOfbA/Bjq5MJmPUvRJ6rnZcI9a4fcH57QQf+YSw/16hXr1scDV4Or6IIduJAzARJsCsZdGhhKtWAnQwUa1FeYPLVU7X2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X8vh1b4ObYVkCYEBeFpCPHlAqQKxA0sHOP1L7pml/e0=; b=a7nafqX96tmxF4vvcYQcLnQ5vFfBj8AKWZveaob9E5cIKiSp2Pt6Se59EG7tYtNOPUurruxHtShcdjdVJPsQ/o8nl+Iz0efMGleYzn+e5drqAddHHlNJRvATA7IYgLhX9kxY8ANCW5sCrB3rxkrBDip4XYmCuHTUSidcNF0zqDllnI19BuIv+VmykLsgsRvBFZrqVd278Fi3EqYFy/T/B/pNUKXFEkDO5f9B5iT4Gc36eZHGQmWUbxXXPQne0vcN1OeBoGIi6MUsEuyEJaXqyN8vj2yLpYmGmnVlvZ41B9FsYhWDCeIPDkE7RMaeGVUQsedwIMkpTwbGzz/t5CerrA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from HE1EUR04FT053.eop-eur04.prod.protection.outlook.com (10.152.26.52) by HE1EUR04HT209.eop-eur04.prod.protection.outlook.com (10.152.27.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18; Thu, 20 Feb 2020 13:21:30 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com (10.152.26.53) by HE1EUR04FT053.mail.protection.outlook.com (10.152.27.42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18 via Frontend Transport; Thu, 20 Feb 2020 13:21:30 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com ([fe80::1956:d274:cab3:b4dd]) by AM6PR03MB5170.eurprd03.prod.outlook.com ([fe80::1956:d274:cab3:b4dd%6]) with mapi id 15.20.2729.033; Thu, 20 Feb 2020 13:21:30 +0000 Received: from [192.168.1.101] (92.77.140.102) by FRYP281CA0015.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18 via Frontend Transport; Thu, 20 Feb 2020 13:21:29 +0000 From: Bernd Edlinger To: "gcc-patches@gcc.gnu.org" , Richard Biener Subject: [PATCH] Fix -save-temp leaking lto files in /tmp Date: Thu, 20 Feb 2020 13:21:30 +0000 Message-ID: x-microsoft-original-message-id: <66035e06-b383-6994-ac9f-23a7bbc612c5@hotmail.de> x-ms-exchange-antispam-messagedata: f9VZppAc2ohXRsG52PF0WJie2lwTgS10gzGDcCOlPJjcAVjubnlO5jWQEDYA1Y0kW3/RDk7wd05UYnRbY1End7kX4GLmNrqUqg8hNBrhpbltPIbnftLkm1VvlyKxIngNayIBm49F3uj5QUPzh3N/mg== x-ms-exchange-transport-forked: True MIME-Version: 1.0 Hi, this is the remaining issue that happens when -flto and -save-temps is used together, it leaks several files in /tmp. I try to give more background to how these temp files are created, and in all likelihood the leaking of these files is wanted, and certainly very helpful for debugging lto issues, that's for sure. It is just not helpful that they need to be looked up in the /tmp folder, even if you want to debug something with lto. The short story is... They are created here: if (parallel) { makefile = make_temp_file (".mk"); mstream = fopen (makefile, "w"); and here: /* Note: we assume argv contains at least one element; this is checked above. */ response_file = make_temp_file (""); f = fopen (response_file, "w"); And in a few other places as well, it depends a bit if -o is used or not (i.e. linker_output != NULL or not). and not removed here: if (response_file && !save_temps) { unlink (response_file); response_file = NULL; } and here: do_wait (new_argv[0], pex); maybe_unlink (makefile); makefile = NULL; the code with the response_file is executed both in lto-wrapper and collect2, but in collect2 only when if is invoked from lto-wrapper, triggered by the @file argument list. Therefore I figured that the best possible solution is just let lto-wrapper create a temp-file for those problem cases, and use TMPDIR to have all make_temp_file that follow use that to folder to place the those response files and other stuff in there. So that is what I split out from the previous patch, which focused on collect2. Bootstrapped and reg-tested on x86_64-pc-linux-gnu. Is it OK for trunk? Thanks Bernd. From d6dc826c63dc881fe41dbf0c3a461008afdef8b3 Mon Sep 17 00:00:00 2001 From: Bernd Edlinger Date: Mon, 17 Feb 2020 17:40:07 +0100 Subject: [PATCH] Fix -save-temp leaking lto files in /tmp When linking with -flto and -save-temps, various temporary files are created in /tmp. They would normally be deleted without -save-temps, but are retained for debugging purposes, which is good. So this just creates a folder named as output-file.lto_tmpdir, which makes this feature even more useful, as the temporary files do not linger in the /tmp directoy but instead are more easy to locate this way. 2020-02-20 Bernd Edlinger * lto-wrapper.c (run_gcc): Create an lto tmpdir and use it when -save-temps is used. --- gcc/lto-wrapper.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c index fe8f292..fdc9565 100644 --- a/gcc/lto-wrapper.c +++ b/gcc/lto-wrapper.c @@ -1423,6 +1423,17 @@ run_gcc (unsigned argc, char *argv[]) fputc ('\n', stderr); } + if (save_temps) + { + char *tmpdir = concat (linker_output ? linker_output : "a.out", + ".lto_tmpdir", NULL); + /* Make directory if necessary, but expect no race here. */ + if (access (tmpdir, F_OK) == 0 + || mkdir (tmpdir, S_IRWXU | S_IRWXG | S_IRWXO) == 0) + setenv ("TMPDIR", tmpdir, 1); + free (tmpdir); + } + if (linker_output_rel) no_partition = true; -- 1.9.1