Forcing ELFv2 abi doesn't work for big-endian mode as this mode has no support for ELFv2. ppc64 linux big-endian is deprecated, it' not unexpected to get such issues. Dropping big-endian support for powerpc could be an option to solve this issue but that will be a drawback for AIX (BE) systems.
regards, Maamoun
On Mon, Aug 16, 2021 at 10:54 PM Niels Möller nisse@lysator.liu.se wrote:
Stijn Tintel stijn@linux-ipv6.be writes:
I suspect this is because musl doesn't support the ELFv1 ABI on ppc64 at all, regardless of endianness. I've tried adding -mabi=elfv2 to CFLAGS, to force using the ELFv2 ABI, but the problem persists. Suggestions
welcome.
I don't know that much about ppc64 abi issues myself. From your description, it seems clear that it's a linker error, and that object files corresponding to C source files somehow carry different "abi version attributes" than object files corresponding to nettle's assembly source files.
As you've found, configuring with --disable-assembler works around the problem, but to solve it properly, we'd need to understand why that is. The assembler should not be invoked directly, but via the same $(CC) and $(CFLAGS) as the C compiler.
You'd need to compare those object files and how they're generated. Compare the compiler command lines. You could perhaps use gcc -v to see how gcc invokes the assembler in both cases. You can use gcc -save-temps to look at the assembly files generated by gcc, and check if they use some special pseudoops to specify the abi. You can use tools like objdump or readelf to compare attributes in the object files.
If you can figure out how to produce object files that are compatible according to the linker, that may not be sufficient, though. You also need to tweak the assembly files and related macros and configure checks to use the right api. See powerpc64/README and powerpc64/machine.m4. As I understand it, abi is currently selected depending on the endianness, using v1 for big endian and v2 for little endian.
It may need a configure test independent of endianness. Maybe there's some predefined symbol we can check, similar to 32-bit/64-bit ABI checks on other platforms? You could run something like
powerpc64-openwrt-linux-musl-gcc -E -dM - </dev/null | sort
With the powerpc64le-linux-gnu-gcc cross compiler I have, the closest suspect I see is
#define _CALL_ELF 2
Maybe that's the right thing to check? I don't have a big-endian system or crosscompiler close at hand, but at least there's a bigendian powerpc64-linux-gnu cross compile setup in the ci system hosted at gitlab.
Regards, /Niels
-- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.
Maamoun TK maamoun.tk@googlemail.com writes:
Forcing ELFv2 abi doesn't work for big-endian mode as this mode has no support for ELFv2. ppc64 linux big-endian is deprecated, it' not unexpected to get such issues. Dropping big-endian support for powerpc could be an option to solve this issue but that will be a drawback for AIX (BE) systems.
The configuration where it didn't work was powerpc64-openwrt-linux-musl. I'd like Nettle to work on embedded systems whenever practical. But support depends on assistance from users of those systems.
As I understood it, this system needs to use the v2 ABI. I would hope it's easy to detect the abi used by the configured C compiler, and then select the same prologue sequence as is currently used for little-endian. I.e., one more configure test, and changing the "ifelse(WORDS_BIGENDIAN,no," condition in powerpc64/machine.m4 to check a different configure variable.
I don't know how the linker detected abi incompatibility (ld error message like "gcm-hash.o: ABI version 1 is not compatible with ABI version 2 output"), if that's based just on the presence of the special ".opd" section, or if there are other attributes in the ELF file, and if so, how the assembler decides which attributes to attach.
Regards, /Niels
On Tue, Aug 17, 2021 at 2:40 AM Niels Möller nisse@lysator.liu.se wrote:
Maamoun TK maamoun.tk@googlemail.com writes:
Forcing ELFv2 abi doesn't work for big-endian mode as this mode has no support for ELFv2. ppc64 linux big-endian is deprecated, it' not unexpected to get such issues. Dropping big-endian support for powerpc could be an option to solve this issue but that will be a drawback for AIX (BE) systems.
The configuration where it didn't work was powerpc64-openwrt-linux-musl. I'd like Nettle to work on embedded systems whenever practical. But support depends on assistance from users of those systems.
Musl Libc does not support ELFv1, so I don't understand how this configuration is possible.
As I understood it, this system needs to use the v2 ABI. I would hope it's easy to detect the abi used by the configured C compiler, and then select the same prologue sequence as is currently used for little-endian. I.e., one more configure test, and changing the "ifelse(WORDS_BIGENDIAN,no," condition in powerpc64/machine.m4 to check a different configure variable.
I don't know how the linker detected abi incompatibility (ld error message like "gcm-hash.o: ABI version 1 is not compatible with ABI version 2 output"), if that's based just on the presence of the special ".opd" section, or if there are other attributes in the ELF file, and if so, how the assembler decides which attributes to attach.
The linker looks for the special ELF attribute.
Thanks, David
David Edelsohn dje.gcc@gmail.com writes:
Musl Libc does not support ELFv1, so I don't understand how this configuration is possible.
If I understood the original report, musl always uses ELFv2 abi, for both little and big endian configurations. Which for big endian is incompatible with the way powerpc64 assembly is configured in nettle.
Nettle assembly files currently use ELFv2 on little endian, but always uses ELFv1 on big endian.
Regards, /Niels
I believe that some OS (FreeBSD? NetBSD?) is trying to use ELFv2 with PPC64 BE. That is a separate issue and I do not believe that Musl Libc plans to support that configuration.
AIX continues to use its ABI, which essentially is closely related to ELFv1 and uses the XCOFF file format and syntax.
Thanks, David
On Tue, Aug 17, 2021 at 1:27 PM Niels Möller nisse@lysator.liu.se wrote:
David Edelsohn dje.gcc@gmail.com writes:
Musl Libc does not support ELFv1, so I don't understand how this configuration is possible.
If I understood the original report, musl always uses ELFv2 abi, for both little and big endian configurations. Which for big endian is incompatible with the way powerpc64 assembly is configured in nettle.
Nettle assembly files currently use ELFv2 on little endian, but always uses ELFv1 on big endian.
Regards, /Niels
-- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.
David Edelsohn dje.gcc@gmail.com writes:
AIX continues to use its ABI, which essentially is closely related to ELFv1 and uses the XCOFF file format and syntax.
When you say "closely related" is it close enough that the same assembly can be used as for ELFv1? I don't remember if Maamoun or someone else tested Nettle's powerpc64 assembly on AIX?
Is there some established common name for this calling convention, for both ELFv1 and XCOFF? Otherwise, I'd refer to it as ELFv1, even though it works on non-ELF AIX too.
Regards, /Niels
On Thu, Aug 19, 2021 at 4:22 PM Niels Möller nisse@lysator.liu.se wrote:
David Edelsohn dje.gcc@gmail.com writes:
AIX continues to use its ABI, which essentially is closely related to ELFv1 and uses the XCOFF file format and syntax.
When you say "closely related" is it close enough that the same assembly can be used as for ELFv1? I don't remember if Maamoun or someone else tested Nettle's powerpc64 assembly on AIX?
Is there some established common name for this calling convention, for both ELFv1 and XCOFF? Otherwise, I'd refer to it as ELFv1, even though it works on non-ELF AIX too.
The AIX ABI and the ELFv1 ABI are not identical. AIX uses XCOFF file format and syntax. PPC64 BE Linux uses ELF file format and syntax.
The ELFv1 ABI was derived from the AIX ABI and both use function descriptors (ELFv1 calls OPD or Official Procedure Descriptors). Function pointers are pointers to the descriptors, not to code. ELFv1 uses ELF section names and decorations.
AIX uses the TOC for global data managed by the compiler. ELFv1 can use a TOC or a more standard GOT managed by the linker.
The assembly language for the instructions is the same (AIX prefers registers as only numbers, while ELF allows letters to distinguish the different register sets (GPRs, FPRs, VSRs).
One can translate between AIX and ELFv1 fairly easily, and possibly use a single assembly file with some m4 macros to hide the differences, but one cannot use identical assembly language files for both.
Thanks David
On Thu, Aug 19, 2021 at 11:22 PM Niels Möller nisse@lysator.liu.se wrote:
David Edelsohn dje.gcc@gmail.com writes:
AIX continues to use its ABI, which essentially is closely related to ELFv1 and uses the XCOFF file format and syntax.
I don't remember if Maamoun or someone else tested Nettle's powerpc64 assembly on AIX?
I tried testing powerpc64 assembly on AIX but as far as I remember I didn't get the library configured in the first place, there is some issue that obstructs the configuration process on AIX. I'll get into this issue once we're done with the current tasks so I don't get confused.
regards, Mamone
On Tue, Aug 17, 2021 at 9:40 AM Niels Möller nisse@lysator.liu.se wrote:
The configuration where it didn't work was powerpc64-openwrt-linux-musl. I'd like Nettle to work on embedded systems whenever practical. But support depends on assistance from users of those systems.
As I understood it, this system needs to use the v2 ABI. I would hope it's easy to detect the abi used by the configured C compiler, and then select the same prologue sequence as is currently used for little-endian. I.e., one more configure test, and changing the "ifelse(WORDS_BIGENDIAN,no," condition in powerpc64/machine.m4 to check a different configure variable.
I skipped processing the assembly files with a different approach, I made the configuration check for musl and endianness variant to trigger assembly processing. You can check the fix in this branch https://git.lysator.liu.se/mamonet/nettle/-/tree/ppc64_musl_fix Apparently, the bug reporter uses a cross-compiler for powerpc arch. It would be great to run this fix at the same bug environment since I tested the patch in different circumstances.
regards, Mamone
nettle-bugs@lists.lysator.liu.se
-
David Edelsohn -
Maamoun TK -
nisse＠lysator.liu.se