Comments (15)
Please provide details about your system. This works in our CI and in all distribution packages.
from mosh.
@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).
from mosh.
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.
from mosh.
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.
from mosh.
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)
from mosh.
@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.
from mosh.
@barracuda156 please demonstrate that the build is broken on a modern, supported macOS -- otherwise we are not interested in this patchset.
from mosh.
@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.
from mosh.
@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.
from mosh.
ocb_internal is vendered code
This is why you don't bundle vendored libraries.
from mosh.
@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.
from mosh.
@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.
from mosh.
@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.
from mosh.
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.
from mosh.
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: macports/macports-ports@a910a13
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
from mosh.
Related Issues (20)
- VT100 DECKPAM - Alternate Keypad Mode HOT 1
- "Did not find mosh server startup message" when connecting to a busybox ash shell (embedded device) HOT 2
- Symbol not found: ___darwin_check_fd_set_overflow on Mojave
- Combining character not appearing over mosh (but it does over ssh) HOT 3
- mosh crashes with -6 IPv6
- Mosh
- Wrote a launcher for mosh-client and mosh-server for Windows
- Bad configuration option: usekeychain HOT 2
- Mac OS: Library not loaded libprotobuf.23.4.0.dylib HOT 4
- Feature request: undercurl support
- Home/End keys not working on a urxvt terminal under mosh HOT 5
- Text doesn't get to clipboard with `tmux load-buffer -w`
- Synchronized Output (DEC private mode 2026) support
- Mobile
- Introduce configuration file HOT 2
- Mosh unexpectedly shutting down (client side) on OSX HOT 4
- latest protobuf version mismatches with mosh-server 1.4.0 HOT 1
- HelloGitHub Badge
- network-no-diff test is broken for both 1.4.0 regression build and head build
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mosh.