Re: [PATCH, BFD, LD, AArch64, 0/4] Add support for AArch64 BTI and PAC in the linker

[Peter Smith <peter dot smith at linaro dot org>]

On Fri, 8 Mar 2019 at 11:14, Ramana Radhakrishnan
<Ramana.Radhakrishnan@arm.com> 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
> >
> >
>