-
-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ppc64 ELFv2 ABI should not be determined from endianness #8858
Comments
First some background information. "perlasm" aims for "least common denominator" among platforms targeted by specific assembly pack. Or in more tangible terms, if question is "why not do something this way, it works for me", then answer is likely to be "it has to work on all systems, even including those that might appear broken to you." I mean there is customarily a reason for why the way things are done looks odd. Next point, more essential in the context, is "verifiability." In sense that whatever that is supported should be actually verified to work, at least at some point. This is basically why big-endian ELFv2 is not supported, there was no opportunity to verify it. But since opportunity presents itself now, i.e. having you verify it, it's presumably no biggie to add it. So try following:
If it passes, create a merge request... |
Sounds good. I will try and test. |
In the context of _CALL_ELF compiler pre-define being 2. One can as well say that perlasm_scheme in linux-ppc64 target can be calculated at config time, based on this pre-define, as opposite to be hardcoded that is. But first things first, i.e. does it pass the test? |
I'm not entirely sure when I'll be able to test this, either later today or during the week. Maybe @awilfox could also help test this. |
Actually, I'm running the tests now. I'll have the results in a bit |
Okay! seems fine. System information (note ppc64 rather than ppc64le):
OpenSSL build confirmed ELFv2:
GCC confirmed emitting ELFv2:
Configdata dump:
Finally, tests passing:
|
Anyway, I think it'd be best to modify the What would be considered the best way to check for the macro in the configurations system? |
Ideally one would appreciate possibility to assign index 701368d..1091eb3 100755
--- a/Configure
+++ b/Configure
@@ -1378,6 +1378,11 @@ unless ($disabled{"fuzz-libfuzzer"} && $disabled{"fuzz-afl"}
# Platform fix-ups
#
+my %predefined_C = compiler_predefined($config{CROSS_COMPILE}.$config{CC});
+my %predefined_CXX = $config{CXX}
+ ? compiler_predefined($config{CROSS_COMPILE}.$config{CXX})
+ : ();
+
# This saves the build files from having to check
if ($disabled{pic})
{
@@ -1466,13 +1471,11 @@ unless ($disabled{asm}) {
if ($target{poly1305_asm_src} ne "") {
push @{$config{lib_defines}}, "POLY1305_ASM";
}
+ if ($target eq "linux-ppc64") {
+ $target{perlasm_scheme} = "linux64v2" if ($predefined_C{_CALL_ELF} == 2);
+ }
}
-my %predefined_C = compiler_predefined($config{CROSS_COMPILE}.$config{CC});
-my %predefined_CXX = $config{CXX}
- ? compiler_predefined($config{CROSS_COMPILE}.$config{CXX})
- : ();
-
# Check for makedepend capabilities.
if (!$disabled{makedepend}) {
if ($config{target} =~ /^(VC|vms)-/) { |
Okay, I thought I could query the compiler from a
|
Associated pr is merged, assuming this is resolved marking as inactive, to be closed at the end of 3.4 dev barring further input |
The
ppc-xlate.pl
script currently uses ELFv2 conditionally based on whether theflavor
is little endian. This is a pretty common way to check it but it is also incorrect - ELFv2 can also be used on big endian and sometimes is, for example themusl
libc uses it unconditionally and it also works withglibc
when enabled.In C, checking for ELFv2 is simple:
If the
_CALL_ELF
macro is defined and set to2
, you are using the ELFv2 ABI. I don't think there is any other reliable way to check, checking formusl
in triple disregards other libcs and there is no dedicated target triple for ELFv2. However, I'm not entirely sure what would be the best way to integrate it in openssl. Maybe @dot-asm knows. For now, asm must be disabled in openssl on such targets.The text was updated successfully, but these errors were encountered: