From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81866 invoked by alias); 8 Mar 2019 11:46:12 -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 81767 invoked by uid 89); 8 Mar 2019 11:46:11 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=drown, HX-Languages-Length:1843, H*i:sk:5653d89, H*f:sk:5653d89 X-HELO: mail-wr1-f65.google.com Received: from mail-wr1-f65.google.com (HELO mail-wr1-f65.google.com) (209.85.221.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Mar 2019 11:46:10 +0000 Received: by mail-wr1-f65.google.com with SMTP id i12so21028258wrw.0 for ; Fri, 08 Mar 2019 03:46:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/14tO3O56Ph+cObXGRL6dMxonfr8YaLF5DNSARxqKsQ=; b=u/yURFD+gIY+33wf+33pGBrU5h0gaWwN+vossFjvxz31aj3dJaT5vGWSJEL1nOIoH3 qjgnULex2RaE6UTh8NzzSWeWHBxyPlx/JIzchNTSTJt/OcnmsuPQd4V85G+3ZTMw4dgO tNpWbTIbo/DVRnUUxZu5qP3U3SCTO2C8elWKts8cquXdMGy9o3q+V2fCeadZbc8GFgiP 79HAsnoZjhfnZXVi7QFlAlC/BfK3Vl3BZaZfMTMiJr3LwUxySuCtZqois9UU6TPpRJ9E zho08/lNdXc0yHiqUTk5Q181meEEMhUi0JdnlKPXwqXFa6q2QwdGSzsDlFWFc85jvRdU MCjA== MIME-Version: 1.0 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> <054d9601-0009-2227-3155-1c013beb74dd@redhat.com> <5653d89c-3239-df8f-6a62-07c0fa189387@arm.com> In-Reply-To: <5653d89c-3239-df8f-6a62-07c0fa189387@arm.com> From: Peter Smith Date: Fri, 08 Mar 2019 11:46:00 -0000 Message-ID: Subject: Re: [PATCH, BFD, LD, AArch64, 0/4] Add support for AArch64 BTI and PAC in the linker To: Ramana Radhakrishnan Cc: "nickc@redhat.com" , Sudakshina Das , "binutils@sourceware.org" , nd , Richard Earnshaw Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-03/txt/msg00048.txt.bz2 On Fri, 8 Mar 2019 at 11:14, Ramana Radhakrishnan wrote: > > On 08/03/2019 10:07, Nick Clifton wrote: > > 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. > > Given this conversation, maybe renaming --bti to --force-bti would > express the intention clearer ? > > Indeed warnings can be ignored in most cases, particularly when there aren't too many. In a large project the output could be large enough to drown out other possibly more important warnings though. If there were a way to generically suppress individual warnings then the case for the separate command line option wouldn't be as good. Having said that, I the nowarn form isn't as important as just --bti, or as Ramana says --force-bti. Peter > regards > Ramana > > > > Cheers > > Nick > > > > >