From: Michael Ellerman <mpe@ellerman.id.au>
To: Andy Polyakov <appro@cryptogams.org>,
Danny Tsen <dtsen@linux.ibm.com>,
linux-crypto@vger.kernel.org
Cc: herbert@gondor.apana.org.au, leitao@debian.org,
nayna@linux.ibm.com, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, ltcgcw@linux.vnet.ibm.com,
dtsen@us.ibm.com
Subject: Re: [PATCH 1/3] crypto: X25519 low-level primitives for ppc64le.
Date: Thu, 16 May 2024 22:06:58 +1000 [thread overview]
Message-ID: <875xvevu3h.fsf@mail.lhotse> (raw)
In-Reply-To: <89e7b4b0-9804-41be-b9b1-aeba57cd3cc6@cryptogams.org>
Andy Polyakov <appro@cryptogams.org> writes:
> Hi,
>
>>> +.abiversion 2
>>
>> I'd prefer that was left to the compiler flags.
>
> Problem is that it's the compiler that is responsible for providing this
> directive in the intermediate .s prior invoking the assembler. And there
> is no assembler flag to pass through -Wa.
Hmm, right. But none of our existing .S files include .abiversion
directives.
We build .S files with gcc, passing -mabi=elfv2, but it seems to have no
effect.
So all the intermediate .o's generated from .S files are not ELFv2:
$ find .build/ -name '*.o' | xargs file | grep Unspecified
.build/arch/powerpc/kernel/vdso/note-64.o: ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500, Unspecified or Power ELF V1 ABI, version 1 (SYSV), not stripped
.build/arch/powerpc/kernel/vdso/sigtramp64-64.o: ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500, Unspecified or Power ELF V1 ABI, version 1 (SYSV), not stripped
.build/arch/powerpc/kernel/vdso/getcpu-64.o: ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500, Unspecified or Power ELF V1 ABI, version 1 (SYSV), not stripped
.build/arch/powerpc/kernel/vdso/gettimeofday-64.o: ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500, Unspecified or Power ELF V1 ABI, version 1 (SYSV), not stripped
.build/arch/powerpc/kernel/vdso/datapage-64.o: ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500, Unspecified or Power ELF V1 ABI, version 1 (SYSV), not stripped
...
But the actual code follows ELFv2, because we wrote it that way, and I
guess the linker doesn't look at the actual ABI version of the .o ?
So it currently works. But it's kind of gross that those .o files are
not ELFv2 for an ELFv2 build.
> If concern is ABI neutrality,
> then solution would rather be #if (_CALL_ELF-0) == 2/#endif. One can
> also make a case for
>
> #ifdef _CALL_ELF
> .abiversion _CALL_ELF
> #endif
Is .abiversion documented anywhere? I can't see it in the manual.
We used to use _CALL_ELF, but the kernel config is supposed to be the
source of truth, so we'd use:
#ifdef CONFIG_PPC64_ELF_ABI_V2
.abiversion 2
#endif
And probably put it in a macro like:
#ifdef CONFIG_PPC64_ELF_ABI_V2
#define ASM_ABI_VERSION .abiversion 2
#else
#define ASM_ABI_VERSION
#endif
Or something like that. But it's annoying that we need to go and
sprinkle that in every .S file.
Anyway, my comment can be ignored as far as this series is concerned,
seems we have to clean this up everywhere.
cheers
next prev parent reply other threads:[~2024-05-16 12:07 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-14 17:38 [PATCH 0/3] crypto: X25519 supports for ppc64le Danny Tsen
2024-05-14 17:38 ` [PATCH 1/3] crypto: X25519 low-level primitives " Danny Tsen
2024-05-15 8:11 ` Andy Polyakov
2024-05-15 12:59 ` Danny Tsen
2024-05-15 9:06 ` Andy Polyakov
2024-05-15 13:04 ` Danny Tsen
2024-05-16 4:53 ` Michael Ellerman
2024-05-16 8:38 ` Andy Polyakov
2024-05-16 11:39 ` Danny Tsen
2024-05-16 12:06 ` Michael Ellerman [this message]
2024-05-16 13:42 ` Andy Polyakov
2024-05-16 19:48 ` Segher Boessenkool
2024-05-16 11:38 ` Danny Tsen
2024-05-14 17:38 ` [PATCH 2/3] crypto: X25519 core functions " Danny Tsen
2024-05-15 8:29 ` Andy Polyakov
2024-05-15 13:06 ` Danny Tsen
2024-05-15 13:33 ` Andy Polyakov
2024-05-15 13:58 ` Danny Tsen
2024-05-15 14:20 ` Andy Polyakov
2024-05-16 19:28 ` Segher Boessenkool
2024-05-14 17:38 ` [PATCH 3/3] crypto: Update Kconfig and Makefile for ppc64le x25519 Danny Tsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875xvevu3h.fsf@mail.lhotse \
--to=mpe@ellerman.id.au \
--cc=appro@cryptogams.org \
--cc=dtsen@linux.ibm.com \
--cc=dtsen@us.ibm.com \
--cc=herbert@gondor.apana.org.au \
--cc=leitao@debian.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=ltcgcw@linux.vnet.ibm.com \
--cc=nayna@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox