[PATCH 0/3] aarch64: enable PAC and BTI

[Bill Roberts]

On 11/13/25 1:20 AM, Niels Möller wrote:
> Bill Roberts <bill.roberts at foss.arm.com> writes:
> 
>> Do you know if ARM Limited (is that the
>>> proper company name?)
>>
>> That is the proper name AFAICT
>>
>>   has a copyright assignment agreement in place with
>>> the FSF, that covers GMP, of if we need to do some paperwork?
>>
>> I will find out.
> 
> Thanks. I'll also check with FSF staff.
> 
>> So existing GMP code, without these patches, could really benefit from
>> using that autoconf standard mechanism.
> 
> To me, it seems rather questionable if that would be an improvement for
> any real systems where one might want to build GMP. I'm sure this can be
> debated, so let's not get into that in the context of your PAC/BTI work.
> 
>> I'll take a closer look at this. But a quick peruse, I thought I
>> needed egrep for | but it looks like you just escape it \|. So that
>> should be easy enough to change to using regular grep.
> 
> You could maybe also use regexp construction like "PROLOGUE_\(_NONLEAF\)?"

Yep, great idea.

> 
>> I can, but I think the issue here is that when readelf isn't there,
>> and I am running the test in an environment where I want a hard
>> failure, ie the binary is built with support, I don't want to skip if
>> readelf is missing as something like a CI will still pass.
> 
> I can understand this desire, but I think you will need to have
> something to CI scripts to deal with this. You would need to look for
> (and reject) a SKIP message in the test log. Which shouldn't be that
> much dfferent from looking for a warning "some tests will be disabled"
> in the configure output.

This isn't a hill I am willing to die on, ill just make it skip.

> 
>> local, pipefail and declare -g offhand. However, pipefail and local
>> can go away and declare -g goes back to eval. I had an eval there
>> before and someone talked me into declare -g. But yeah, we can remove
>> this requirement and do it POSIX shell.
> 
> I would prefer to also take out all features and command line options
> not needed for the test. Or if you have a strong opinion that it is
> really useful (for troubleshooting?) with a script that is more flexible
> with a couple of command line options, you could split it in two parts:
> 
> First script is a /bin/sh sccript that is invoked by make check, with no
> options beyond possibly a --verbose flag if relevant. That script can
> then invoke the second script one or more times with various options
> (depending on environment variables set up by make). If the second
> script benefits from bash features, the first script can do something
> like "type bash >/dev/null || exit 77" to require bash.

I can get rid of the bashisms, as you point out, they're not needed and 
we will just use 2 env vars for the BTI and PAC input status's and 
update the usage text/comments to make it clear.

> 
> For that path, it's essential that each script is small and easy to
> understand in its own right, otherwise it will be more costly to review.
> 
> I also recommend running shellcheck (https://www.shellcheck.net/) on all
> non-trivial shell scripts.
> 
> Regards,
> /Niels

Thanks will send out the next revision soon.

>