They now generally conform to the following argument sequence:
script.pl "$(PERLASM_SCHEME)" [ C preprocessor arguments ... ] \
$(PROCESSOR) <output file>
However, in the spirit of being able to use these scripts manually,
they also allow for no argument, or for only the flavour, or for only
the output file. This is done by only using the last argument as
output file if it's a file (it has an extension), and only using the
first argument as flavour if it isn't a file (it doesn't have an
extension).
While we're at it, we make all $xlate calls the same, i.e. the $output
argument is always quoted, and we always die on error when trying to
start $xlate.
There's a perl lesson in this, regarding operator priority...
This will always succeed, even when it fails:
open FOO, "something" || die "ERR: $!";
The reason is that '||' has higher priority than list operators (a
function is essentially a list operator and gobbles up everything
following it that isn't lower priority), and since a non-empty string
is always true, so that ends up being exactly the same as:
open FOO, "something";
This, however, will fail if "something" can't be opened:
open FOO, "something" or die "ERR: $!";
The reason is that 'or' has lower priority that list operators,
i.e. it's performed after the 'open' call.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9884)
"Windows friendliness" means a) flipping .thumb and .text directives,
b) always generate Thumb-2 code when asked(*); c) Windows-specific
references to external OPENSSL_armcap_P.
(*) so far *some* modules were compiled as .code 32 even if Thumb-2
was targeted. It works at hardware level because processor can alternate
between the modes with no overhead. But clang --target=arm-windows's
builtin assembler just refuses to compile .code 32...
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8252)
Branch to global symbol results in reference to PLT, and when compiling
for THUMB-2 - in a R_ARM_THM_JUMP19 relocation. Some linkers don't
support this relocation (ld.gold), while others can end up truncating
the relocation to fit (ld.bfd).
Convert this branch through PLT into a direct branch that the assembler
can resolve locally.
See https://github.com/android-ndk/ndk/issues/337 for background.
The current workaround is to disable poly1305 optimization assembly,
which is not optimal and can be reverted after this patch:
beab607d2b
CLA: trivial
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5949)
Even though no test could be found to trigger this, paper-n-pencil
estimate suggests that x86 and ARM inner loop lazy reductions can
loose a bit in H4>>*5+H0 step.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Some of these scripts would recognise an output parameter if it looks
like a file path. That works both in both the classic and new build
schemes. Some fo these scripts would only recognise it if it's a
basename (i.e. no directory component). Those need to be corrected,
as the output parameter in the new build scheme is more likely to
contain a directory component than not.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Formally only 32-bit AVX2 code path needs this, but I choose to
harmonize all vector code paths.
RT#4346
Reviewed-by: Richard Levitte <levitte@openssl.org>
Most of the assembly uses constants from arm_arch.h, but a few references to
ARMV7_NEON don't. Consistently use the macros everywhere.
Signed-off-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Different assembler versions disagree on how to interpret #-1 as
argument to vmov.i64, as 0xffffffffffffffff or 0x00000000ffffffff.
So replace it with something they can't disagree on.
Reviewed-by: Rich Salz <rsalz@openssl.org>
