From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99077 invoked by alias); 4 Mar 2020 17:42:33 -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 99068 invoked by uid 89); 4 Mar 2020 17:42:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Mar 2020 17:42:31 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2076AAB7F; Wed, 4 Mar 2020 17:42:29 +0000 (UTC) Subject: Re: [PATCH v2 3/3] Keep .GCC.command.line sections of LTO objetcs. To: Jakub Jelinek Cc: Egeyar Bagcioglu , Richard Biener , GCC Patches , nickc@redhat.com References: <1583246660-6390-1-git-send-email-egeyar.bagcioglu@oracle.com> <1583246660-6390-4-git-send-email-egeyar.bagcioglu@oracle.com> <20200304173322.GR2156@tucnak> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: Date: Wed, 04 Mar 2020 17:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200304173322.GR2156@tucnak> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2020-03/txt/msg00238.txt On 3/4/20 6:33 PM, Jakub Jelinek wrote: > On Wed, Mar 04, 2020 at 06:23:10PM +0100, Martin Liška wrote: >> On 3/4/20 4:25 PM, Egeyar Bagcioglu wrote: >>> Thanks Richard. >>> >>> I do not have write-access to the GCC repo. I'd be glad if someone commits it for me. >> >> Can we please wait? I'm really convinced we do not want one another very similar >> functionality. I would definitely recommend to change the semantics >> of -frecord-gcc-switches to what the patchset does. >> >> That's why I added Nick as he's the author of the original implementation. >> Reasoning is provided in my previous email. > > Also, what is the reason for storing the option in a file, rather than say > putting them into an environment variable from which the backend can pick it > up? That's smart suggestion! It would not be the first environment variable that we use, right? > I must say I don't really see advantages of this over > -grecord-gcc-switches, recording all options looks very bloaty and will > include mostly stuff you don't really care about (such as, e.g. the -I > options without knowing what was the current directory when the source file > has been compiled), on the other side will not record interesting options > that -grecord-gcc-switches records (say, if some code is compiled with > -march=native, this new option will record that, rather than what it really > is), but I won't stand in a way unless such an option would be on by > default. Yes, it's a minor disadvantage. On the other hand one can check the fortify macros. I don't care much about them too, but what's the biggest benefit to me is that each argument will not go into it's own mergeable section. Then you will not see something like: $ gcc -O0 foo.c -frecord-gcc-switches -c -g $ gcc -Ofast bar.c -frecord-gcc-switches -c -g0 $ gcc foo.o bar.o $ readelf -p .GCC.command.line a.out String dump of section '.GCC.command.line': [ 0] foo.c [ 6] -mtune=generic [ 15] -march=x86-64 [ 23] -g [ 26] -O0 [ 2a] -frecord-gcc-switches [ 40] bar.c [ 46] -g0 [ 4a] -Ofast The output is useless and can't disambiguate each compiler invocations. Martin > > Jakub >