[PATCH, BFD, LD, AArch64, 0/4] Add support for AArch64 BTI and PAC in the linker
Szabolcs Nagy
Szabolcs.Nagy@arm.com
Fri Mar 8 11:08:00 GMT 2019
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.
>
> 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.
does -z ibt warn on x86_64?
it is important to allow the user to force bti on
(a non-bti marked object file can easily be compatible
with bti, e.g if there are no indirect branches targeting
it, or somebody might just want to do runtime tests to
find out where are the problematic branches), so at least
one of --bti or --bti-nowarn should be added, it is just
convenience to have them both since there are different
use cases.
i think it's also reasonable to just have one option that
is compatible with the x86_64 behaviour.
More information about the Binutils
mailing list