PerlASM for x64

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

PerlASM for x64

Gisle Vanem-4
I'm trying to understand how the generation of ASM-files
are done on x64. (I have no problems on x86).

With the generated Nmake makefile from a
   perl Configure VC-WIN64A-ONECORE

when doing a:
   nmake crypto\aes\libcrypto-lib-aesni-x86_64.obj

seems to do this:
   set ASM=nasm
   "f:/util/StrawberryPerl/perl/bin/perl.exe" "crypto\aes\asm\aesni-x86_64.pl" auto crypto\aes\aesni-x86_64.asm
   nasm -Ox -f win64 -DNEAR -g -o crypto\aes\libcrypto-lib-aesni-x86_64.obj "crypto\aes\aesni-x86_64.asm"

Except for some warnings, nasm generates a valid libcrypto-lib-aesni-x86_64.obj.

BUT, doing the same on the cmd-line:
   set ASM=nasm
   f:\util\StrawberryPerl\perl\bin\perl crypto\aes\asm\aesni-x86_64.pl auto tmp-file.s

Generates a totally invalid 'tmp-file.s' file:

--- tmp-file.s                  2018-12-21 13:12:19
+++ crypto/aes/aesni-x86_64.asm 2018-12-21 13:11:47
@@ -1,4432 +1,5051 @@
-.text
+default        rel
+%define XMMWORD
+%define YMMWORD
+%define ZMMWORD
+section        .text code align=64

-.globl aesni_encrypt
-.type  aesni_encrypt,@function
-.align 16
+EXTERN OPENSSL_ia32cap_P
+global aesni_encrypt
+

What is going on here? Some other exported env-var playing
tricks?

I experimented some more. I figured the "auto" does not work.
But this works:
   perl crypto\aes\asm\aesni-x86_64.pl nasm > tmp-file.s
   diff tmp-file.s crypto\aes\aesni-x86_64.asm

No diffs.

Why does the the generation of .asm-files be so damn hard to
figure out? Some cmd-line help to show what "auto" does would
be nice.


--
--gv
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PerlASM for x64

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Fri, 21 Dec 2018 15:45:23 +0100, Gisle Vanem <[hidden email]> said:

> I'm trying to understand how the generation of ASM-files
> are done on x64. (I have no problems on x86).
>
> With the generated Nmake makefile from a
>   perl Configure VC-WIN64A-ONECORE
>
> when doing a:
>   nmake crypto\aes\libcrypto-lib-aesni-x86_64.obj
>
> seems to do this:
>   set ASM=nasm
>   "f:/util/StrawberryPerl/perl/bin/perl.exe"
>   "crypto\aes\asm\aesni-x86_64.pl" auto crypto\aes\aesni-x86_64.asm
>   nasm -Ox -f win64 -DNEAR -g -o
>   crypto\aes\libcrypto-lib-aesni-x86_64.obj
>   "crypto\aes\aesni-x86_64.asm"
>
> Except for some warnings, nasm generates a valid
> libcrypto-lib-aesni-x86_64.obj.
>
> BUT, doing the same on the cmd-line:
>   set ASM=nasm
>   f:\util\StrawberryPerl\perl\bin\perl crypto\aes\asm\aesni-x86_64.pl
>   auto tmp-file.s
>
> Generates a totally invalid 'tmp-file.s' file:
>
> --- tmp-file.s                  2018-12-21 13:12:19
> +++ crypto/aes/aesni-x86_64.asm 2018-12-21 13:11:47
> @@ -1,4432 +1,5051 @@
> -.text
> +default        rel
> +%define XMMWORD
> +%define YMMWORD
> +%define ZMMWORD
> +section        .text code align=64
>
> -.globl aesni_encrypt
> -.type  aesni_encrypt,@function
> -.align 16
> +EXTERN OPENSSL_ia32cap_P
> +global aesni_encrypt
> +
>
> What is going on here? Some other exported env-var playing
> tricks?
>
> I experimented some more. I figured the "auto" does not work.
> But this works:
>   perl crypto\aes\asm\aesni-x86_64.pl nasm > tmp-file.s
>   diff tmp-file.s crypto\aes\aesni-x86_64.asm
>
> No diffs.
>
> Why does the the generation of .asm-files be so damn hard to
> figure out? Some cmd-line help to show what "auto" does would
> be nice.

The "auto" flavor takes note of the output file extension.  .asm vs .s
in this case.

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PerlASM for x64

Gisle Vanem-4
Richard Levitte wrote:

>> I experimented some more. I figured the "auto" does not work.
>> But this works:
>>    perl crypto\aes\asm\aesni-x86_64.pl nasm > tmp-file.s
>>    diff tmp-file.s crypto\aes\aesni-x86_64.asm
>>
>> No diffs.
>>
>> Why does the the generation of .asm-files be so damn hard to
>> figure out? Some cmd-line help to show what "auto" does would
>> be nice.
>
> The "auto" flavor takes note of the output file extension.  .asm vs .s
> in this case.

Thank, but it was a typo in my 1st email. The correct command was
with a redirect:
   set ASM=nasm
   f:\util\StrawberryPerl\perl\bin\perl crypto\aes\asm\aesni-x86_64.pl auto > tmp-file.s

Still the "auto" forces GNU-asm syntax with 'ASM=nasm'.
I can only conclude the '$ASM' does nothing and only helps obfuscate
things further. This works fine:
   set ASM=
   f:\util\StrawberryPerl\perl\bin\perl crypto\aes\asm\aesni-x86_64.pl nasm > tmp-file.s

--
--gv
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PerlASM for x64

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Mon, 24 Dec 2018 13:17:51 +0100, Gisle Vanem <[hidden email]> said:

> Richard Levitte wrote:
>
> >> I experimented some more. I figured the "auto" does not work.
> >> But this works:
> >>    perl crypto\aes\asm\aesni-x86_64.pl nasm > tmp-file.s
> >>    diff tmp-file.s crypto\aes\aesni-x86_64.asm
> >>
> >> No diffs.
> >>
> >> Why does the the generation of .asm-files be so damn hard to
> >> figure out? Some cmd-line help to show what "auto" does would
> >> be nice.
> > The "auto" flavor takes note of the output file extension.  .asm vs .s
> > in this case.
>
> Thank, but it was a typo in my 1st email. The correct command was
> with a redirect:
>   set ASM=nasm
>   f:\util\StrawberryPerl\perl\bin\perl crypto\aes\asm\aesni-x86_64.pl
>   auto > tmp-file.s

That isn't a correct use of the script.  All of the assembler perl
scripts expect the output file as last argument, and the x86_64 ones
do look at the output file and determines that if the extension is
'.asm', nasm assembler is expected, otherwise you will get gas
assembler.  So if you redirect, the result is, mildly put, undefined.

Thank you, though...  it is time the assembler stuff gets documented,
and I think I'm in a fairly good position to do so.  I will not
promise that it will happen fast, but it is in my backlog.

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PerlASM for x64

OpenSSL - User mailing list
On 24/12/2018 19:08, Richard Levitte wrote:

> In message <[hidden email]> on Mon, 24 Dec 2018 13:17:51 +0100, Gisle Vanem <[hidden email]> said:
>
>> Richard Levitte wrote:
>>
>>>> I experimented some more. I figured the "auto" does not work.
>>>> But this works:
>>>>     perl crypto\aes\asm\aesni-x86_64.pl nasm > tmp-file.s
>>>>     diff tmp-file.s crypto\aes\aesni-x86_64.asm
>>>>
>>>> No diffs.
>>>>
>>>> Why does the the generation of .asm-files be so damn hard to
>>>> figure out? Some cmd-line help to show what "auto" does would
>>>> be nice.
>>> The "auto" flavor takes note of the output file extension.  .asm vs .s
>>> in this case.
>> Thank, but it was a typo in my 1st email. The correct command was
>> with a redirect:
>>    set ASM=nasm
>>    f:\util\StrawberryPerl\perl\bin\perl crypto\aes\asm\aesni-x86_64.pl
>>    auto > tmp-file.s
> That isn't a correct use of the script.  All of the assembler perl
> scripts expect the output file as last argument, and the x86_64 ones
> do look at the output file and determines that if the extension is
> '.asm', nasm assembler is expected, otherwise you will get gas
> assembler.  So if you redirect, the result is, mildly put, undefined.
>
> Thank you, though...  it is time the assembler stuff gets documented,
> and I think I'm in a fairly good position to do so.  I will not
> promise that it will happen fast, but it is in my backlog.
As a trivial (and easily audited first patch) perhaps make the
common code error out with a usage message to STDERR if the
command line makes no sense (no output file, wrong argument
count, auto with unrecognized file extension).  Ideally this
would be in the common perl module(s), not in individual
assembler files.

Remember that keeping every patch easily audited by the wider
community is essential to the trustworthiness of OpenSSL, the
great reformatting a while back was a major mistake in this
regard.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PerlASM for x64

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Thu, 27 Dec 2018 10:12:34 +0100, Jakob Bohm <[hidden email]> said:

> On 24/12/2018 19:08, Richard Levitte wrote:
> > In message <[hidden email]> on Mon, 24
> > Dec 2018 13:17:51 +0100, Gisle Vanem <[hidden email]> said:
> >
> >> Richard Levitte wrote:
> >>
> >>>> I experimented some more. I figured the "auto" does not work.
> >>>> But this works:
> >>>>     perl crypto\aes\asm\aesni-x86_64.pl nasm > tmp-file.s
> >>>>     diff tmp-file.s crypto\aes\aesni-x86_64.asm
> >>>>
> >>>> No diffs.
> >>>>
> >>>> Why does the the generation of .asm-files be so damn hard to
> >>>> figure out? Some cmd-line help to show what "auto" does would
> >>>> be nice.
> >>> The "auto" flavor takes note of the output file extension.  .asm vs .s
> >>> in this case.
> >> Thank, but it was a typo in my 1st email. The correct command was
> >> with a redirect:
> >>    set ASM=nasm
> >>    f:\util\StrawberryPerl\perl\bin\perl crypto\aes\asm\aesni-x86_64.pl
> >>    auto > tmp-file.s
> > That isn't a correct use of the script.  All of the assembler perl
> > scripts expect the output file as last argument, and the x86_64 ones
> > do look at the output file and determines that if the extension is
> > '.asm', nasm assembler is expected, otherwise you will get gas
> > assembler.  So if you redirect, the result is, mildly put, undefined.
> >
> > Thank you, though...  it is time the assembler stuff gets documented,
> > and I think I'm in a fairly good position to do so.  I will not
> > promise that it will happen fast, but it is in my backlog.
> As a trivial (and easily audited first patch) perhaps make the
> common code error out with a usage message to STDERR if the
> command line makes no sense (no output file, wrong argument
> count, auto with unrecognized file extension).  Ideally this
> would be in the common perl module(s), not in individual
> assembler files.

Ideas differ from one person to another, and there are ideas on
flexibility based on intimate knowledge of these modules that are
contrary to the more strict interpretation you desire.  Also, and
we've argued this back and forth quite a bit, there's the idea of the
modules being usable without dependence on other modules (apart from
the xlate module that they pipe to).

These modules have worked this way for quite a while (apart from
standardising on having the last argument be the output file at all
times, that actually varied between assembler modules before 1.1.0),
and while I agree with you that these modules are a bit too flexible
(please take note of this before thinking that I'm arguing against
you!), changing them need to be done carefully.

> Remember that keeping every patch easily audited by the wider
> community is essential to the trustworthiness of OpenSSL, the
> great reformatting a while back was a major mistake in this
> regard.

Regarding the great reformatting, this may be argued 'til hell freezes
over.  One of the things we considered was that the old source format
was arcane, didn't exist anywhere else, and wasn't even well supported
by the project team members (there was code inserted in more common
formats, most often the usual 4 space indent BSD format).  The current
format has much better recognision and is easy to support in editors
and current formatters.  So as "mistake" goes, keeping the old source
code format could have been regarded as one just as much.

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users