Open barracuda156 opened 5 months ago
Please provide details about your system. This works in our CI and in all distribution packages.
@achernya Thank you for responding! macOS 10.6, gcc-13.2 (in fact gcc-4.2 is not picked at all due to C++ standard requirement, I just did not notice that initially).
It could be that either code is correct but uses VSX and not Altivec, in which case fixing a macro will work (i.e., use __VSX__
). Or if the code is supposed to by ISA 2.03-compliant, then something is wrong in it (maybe includes).
If it is supposed to be ISA 2.03-compliant, then a macro for ppc64
has to be fixed as well, since the current one will lead to Darwin on ppc64
trying to use 32-bit chunk (it should also check for __ppc64__
to have an intended effect).
With includes by the way configure does not check for machine/endian.h
, which is the path on Darwin, but it is likely unrelated to the issue here and possibly inconsequential, since libkern macros are checked for.
A lazy fix will be
--- src/crypto/ocb_internal.cc
+++ src/crypto/ocb_internal.cc
@@ -220,7 +220,7 @@
bl = _mm_slli_epi32(bl, 1);
return _mm_xor_si128(bl,tmp);
}
-#elif __ALTIVEC__ && _CALL_ELF != 2
+#elif __VSX__ && _CALL_ELF != 2
#include <altivec.h>
typedef vector unsigned block;
#define xor_block(x,y) vec_xor(x,y)
or if it is known that it works on G4/G5 but not on MacOS, then
--- src/crypto/ocb_internal.cc
+++ src/crypto/ocb_internal.cc
@@ -220,7 +220,7 @@
bl = _mm_slli_epi32(bl, 1);
return _mm_xor_si128(bl,tmp);
}
-#elif __ALTIVEC__ && _CALL_ELF != 2
+#elif (__ALTIVEC__ && _CALL_ELF != 2) && !defined(__APPLE__)
#include <altivec.h>
typedef vector unsigned block;
#define xor_block(x,y) vec_xor(x,y)
However it may be just some error, and the code could work. In which case we would not want to simply disable vectorization.
macOS 10.6 is no longer in support and ocb_internal is vendered code from https://www.cs.ucdavis.edu/~rogaway/ocb/news/code/ocb.c so I'm hesitant to touch it in a meaningful way other than deletions. I suggest you try enabling the openssl-based ocb implementation instead. (That would have been our default for mosh-1.4.0 if it hasn't been for CVE-2022-2097)
@achernya Well, if no one knows how to fix it to work on macOS (I do not know Altivec syntax), then just disabling is fine. It will not affect anything else, obviously, since __APPLE__
is defined only for macOS.
That will at least unbreak the build and allow it to function.
@barracuda156 please demonstrate that the build is broken on a modern, supported macOS -- otherwise we are not interested in this patchset.
@achernya The patch specifically disables it where it is broken. It does not affect other systems where the code is presumed to work. I also fix the failing case here.
@barracuda156 as I mentioned in my comment above: I am not willing to take any changes to this file other than deletions. If you would like to get mosh to work, please enable the openssl-based ocb build instead. If you would like to submit a PR to delete all the altivec code instead, I would be willing to merge that.
ocb_internal is vendered code
This is why you don't bundle vendored libraries.
@achernya I guess I did not understand correctly your reasoning. If you do not want to modify the code because it is vendored, I am not a legal expert, but I can accept that.
I am not sure if it is a right thing to remove the code, since while it will fix the bug for one platform, it may result in suboptimal performance on another platform, and I have no way to verify if the code builds on BSD and Linux or not.
@barracuda156 there's nothing about legality or not of modifying it. It's our inability to have CI for this configuration, therefore a desire to not support it.
@achernya What you do with your project is up to you, of course, but to be honest I cannot see how my fix could have any conceivable adverse effect on any platform whatsoever. The only effect of it was to disable usage of that Altivec code on macOS. It was as non-invasive as possible. I am not asking you to support PowerPC proactively nor expect anyone to do it. But no one is better off if the broken code is left unfixed, when the cost of the fix is a single line change with no effect on other systems.
Your fix creates an ongoing expectation of support by the maintainers of this project. I've already expressed my desires here that we reduce that support burden since we cannot easily test for altivec on ppc. As a result, I can't take your contribution as is.
Continuing to discuss won't cause us to accept the single-line fix since it doesn't change our ability to test it in an ongoing basis.
Just for the record if anyone ever bumps into the issue: the correct fix is to change vector
to __vector
(and obviously fix a macro for ppc64
). Like this: https://github.com/macports/macports-ports/commit/a910a13fe316e9f4a3277a8766ece5590756ee92
My initial suggestion to disable it was suboptimal. The code is fine, but type used is inaccurate.
Related chunk in altivec.h
is here: https://github.com/gcc-mirror/gcc/blob/58ecd2eb507ab216861408cf10ec05efc4e8344e/gcc/config/rs6000/altivec.h#L37-L49
Code in
ocb_internal.cc
is broken and fails to compile:Same failure with gcc-4.2 and gcc-13.2.1.