openssl: HPUX - Unable to build with asm

Hello,

when I try to build OpenSSL on HPUX ia64 (itanium) with the native compiler (cc), I have to go with the “no-asm” option. Otherwise, the build fails. I have the following error : ar: crypto/chacha/libcrypto-lib-chacha-ia64.o: No such file or directory I can see the compile line :
cc -I. -Iinclude -Iproviders/common/include -Iproviders/implementations/include -DAES_ASM -DGHASH_ASM -DOPENSSL_CPUID_OBJ -DPOLY1305_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM +Z -Ae +DD64 +Olit=all -z +O3 -DB_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DOPENSSL_BUILDING_OPENSSL -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED -D_HPUX_ALT_XOPEN_SOCKET_API -DNDEBUG -DOPENSSL_TLS_SECURITY_LEVEL=0 -c -o crypto/chacha/libcrypto-lib-chacha-ia64.o crypto/chacha/chacha-ia64.S

But no file is generated. However, if I rename the file “chacha-ia64.S” to “chacha-ia64.s”, the expected .o is generated. It seems this compiler is rather picky when it comes to file extensions, and it only accepts .s…

Unfortunately, I have no idea how to fix it, since :

I’m not familiar enough with HPUX cc compiler to know whether or not there is an option to handle .S instead of .s
I’m not familiar enough with OpenSSL build, I saw some files named .s and others .S, and don’t know what the impact is

I can easily test any patch provided if needed, on a whole bunch of OSes as well.

Note that :

after renaming chacha-ia64.S and poly1305-ia64.S to .s, the build was fine
using no-asm generate a core dump (BUS error) when trying to use AES_set_encrypt_key() (when trying to access key->round in aes_core.c, line 648 with tag openssl-3.0.1) :

Program received signal SIGBUS, Bus error
  si_code: 1 - BUS_ADRALN - Invalid address alignment. Please refer to the following link that helps in handling unaligned data: http://docs.hp.com/en/7730/newhelp0610/pragmas.htm#pragma-
pack-ex3.
0x9fffffffbe53a730:0 in AES_set_decrypt_key () at crypto/aes/aes_core.c:648
648             key->rounds = 14;
(gdb) bt
#0  0x9fffffffbe53a730:0 in AES_set_decrypt_key () at crypto/aes/aes_core.c:648
#1  0x9fffffffbf5a8a00:0 in <caller>

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 16 (14 by maintainers)

Most upvoted comments

Sorry, I wasn’t clear. I meant that gcc yielded no issue when building .s / .S. However, the HP compiler did not make any differences between .S and .s at all. I hadn’t tried the PR yet.

I just built with the PR and it worked perfectly ! Thanks for your work on this 😃

RobinGeffroy on May 25, 2022

What does the GENERATE directive do to generate a .s file from a .S file? Is this something we should with the HP compiler only?

I’m not sure what exactly c99 does on HPUX, but on HPE NonStop, we do not have access to asm. It might be a similar situation. Assembler is not externalized for users.

Does that mean that NonStop targets expect to be configured with no-asm?

If there is an assumption that an assembler exists, then yes, definitely. It has not been an issue in past.

Never mind. Getting assembler built requires that the attribute asm_arch be present in the relevant config target. Since no NonStop includes that attribute, no asm will be compiled for them

(I forgot I had implemented this 😉)

levitte on May 24, 2022

What does the GENERATE directive do to generate a .s file from a .S file? Is this something we should with the HP compiler only?

It does this:

https://github.com/openssl/openssl/blob/828613c3e44ca1de6407a37d34de64c673ca61e9/Configurations/unix-Makefile.tmpl#L1584-L1586

Where $gen0 is the first part of the right hand side of the GENERATE statement (i.e. the .S file in that case), while $args{src} is the target (the .s file in that case).

This should be perfectly safe to do with any compiler, as they all use the same -E to just run the preprocessor. This is what should always have been done, actually, it’s just that we ran with the (incorrect) assumption that all compiler understand .S the same way gcc does

levitte on May 24, 2022