From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19699 invoked by alias); 8 Mar 2019 10:07:22 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 19691 invoked by uid 89); 8 Mar 2019 10:07:22 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=forgets, H*f:sk:5e442d2, H*i:sk:5e442d2, HContent-Transfer-Encoding:8bit X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Mar 2019 10:07:20 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 60F2230832CB; Fri, 8 Mar 2019 10:07:19 +0000 (UTC) Received: from [10.33.36.34] (unknown [10.33.36.34]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D66CB5D787; Fri, 8 Mar 2019 10:07:17 +0000 (UTC) To: Sudakshina Das , "binutils@sourceware.org" Cc: nd , Richard Earnshaw , Ramana Radhakrishnan , "peter.smith@linaro.org" References: <08762e41-1e80-a504-d840-f8715ea59a50@arm.com> <581bbc74-441c-8f39-c4d5-38475f12dfb6@redhat.com> <6fcac9a6-5c6e-274d-9f5d-05094d0437c7@redhat.com> <5e442d26-6978-4efe-9f44-81143877cddd@arm.com> From: Nick Clifton Openpgp: preference=signencrypt Subject: Re: [PATCH, BFD, LD, AArch64, 0/4] Add support for AArch64 BTI and PAC in the linker Message-ID: <054d9601-0009-2227-3155-1c013beb74dd@redhat.com> Date: Fri, 08 Mar 2019 10:07:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <5e442d26-6978-4efe-9f44-81143877cddd@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00043.txt.bz2 Hi Sudi, >> OK, so just to be clear, with --bti or --bti-nowarn the output will be >> given the BTI tag *even if* some of the input files do not have the BTI note ? > Yes > can go back and check the objects that need recompiling or use > --bti-nowarn when they are sure that even if there is any object with > missing BTI note section it is still safe to turn on BTI (or they still > want to turn on BTI). We think that these options would be most helpful > in early deployment. OK, well I get the --bti option then, but I still think that --bti-nowarn is a mistake. Given that --bti will only generate warnings if there are object files without the BTI note, and warnings can be ignored, I do not see the need for --bti-nowarn. Plus using --bti-nowarn could potentially cause problems if the developer forgets (or does not know) that it is enabled, and they end up thinking that they are creating BTI enabled binaries when in fact they are not. If a developer really wants to skip the warnings they could pipe the output from the linker through a grep that eliminates them. Which would have the added benefit of being more visible in the output logs of a complex build than a single command line option. Cheers Nick