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

[Niels Möller]

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\)?"

> 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.

> 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.

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

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.