-
Notifications
You must be signed in to change notification settings - Fork 725
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
Add s390x GHA workflow (cross-compile) #2380
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change itself looks good!
If the step take too long we could run it post-commit I support.. or make it optional to wait for it to complete. Lets see how long it takes..
just a bit faster =^-^= (also yes, it is expected to fail for now.) also, cc @alexreinking ? |
699325f
to
743a722
Compare
.github/workflows/build.yml
Outdated
- name: mkdir | ||
run: mkdir -p out | ||
- name: cmake | ||
run: cmake -DCMAKE_TOOLCHAIN_FILE=../scripts/TC-${{matrix.arch}}.cmake .. -G Ninja -DWITH_WASI=ON -DWERROR=OFF -Werror=dev -Wno-deprecated | ||
working-directory: out |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be simplified a little:
- name: mkdir | |
run: mkdir -p out | |
- name: cmake | |
run: cmake -DCMAKE_TOOLCHAIN_FILE=../scripts/TC-${{matrix.arch}}.cmake .. -G Ninja -DWITH_WASI=ON -DWERROR=OFF -Werror=dev -Wno-deprecated | |
working-directory: out | |
- name: cmake | |
run: cmake -G Ninja -S . -B out -DCMAKE_TOOLCHAIN_FILE=./scripts/TC-${{matrix.arch}}.cmake -DWITH_WASI=ON -DWERROR=OFF -Werror=dev -Wno-deprecated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we would rather keep this consistent with the build
job, aside from the toolchain file (and, currently, the -DWERROR=OFF
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't consistent everywhere in this file, though... look at line 161 for instance. I'd sooner move the file towards having fewer unnecessary steps (which just add noise to logs)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm... @sbc100 thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine with me.
IIRC the support for -S + -B
flags in cmake wasn't always supported but as a long as are running with recent enough cmake everywhere this seems fine to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe make separate PR to convert to using -S + -B
everywhere before we lang this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The -S
and -B
flags were introduced in CMake 3.13 while the minimum version for wabt is CMake 3.16 and has been for a while. No hazard with using them here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm even the places that use -S + -B
aren't consistent about order. would you prefer -S . -B out -G Ninja
or -G Ninja -S . -B out
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No opinion there..
options: --health-cmd distccmon-text --health-interval 5s --health-start-period 5m debian:latest bash -c "apt-get update && apt-get install -y g++-s390x-linux-gnu distcc && distccd --daemon --no-detach" | ||
ports: | ||
- 3632:3632 | ||
steps: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another simplification:
steps: | |
env: | |
CMAKE_GENERATOR: Ninja | |
QEMU_LD_PREFIX: /usr/${{matrix.arch}}-linux-gnu/ | |
steps: |
Then get rid of -G Ninja
and the other QEMU_LD_PREFIX
settings below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We use -G Ninja
elsewhere in this file though... so maybe leave that one as is for consistency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sbc100 - totally non-critical, just a suggestion! I think QEMU_LD_PREFIX
does lower the risk for forgetting it if the workflow has to change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that works...? well, let's find out! (github actions documentation is not exactly the easiest thing to read...)
(huh, so it does!)
Thanks for the great work @SoniEx2! Super happy to see this effort picked back up -- and super happy to see it improved! I commented a couple easy ways to simplify the workflow steps. I no longer work at Google, though, so I'd appreciate it if you would change the co-authored-by email to |
7bc923d
to
c7b1a74
Compare
lgtm in general, but lets see how long it takes (and make sure it passes :) |
c7b1a74
to
c4c5957
Compare
the only blocker now is #2340 , it'd be really nice to get this merged... |
c4c5957
to
709eaa2
Compare
there we go! |
does this need anything else? |
How long does it take compared the current slowest CI step? |
The previous slowest step was the CIFuzz (which goes for exactly 10 minutes of fuzzing); this one takes about 17-18 minutes. Seems tolerable to me but this will be the new tentpole. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm % nits
.github/workflows/build.yml
Outdated
if: ${{ matrix.arch != 's390x' }} # currently broken... | ||
- name: c-api-tests | ||
run: cmake --build out --target run-c-api-tests | ||
if: ${{ matrix.arch != 's390x' }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Give that s390x is the only arch these blocks are now dead code aren't they?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is explicitly intended to make it easy to add more archs (arm64 anyone?) but you're right that there's a slight readability tradeoff here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess I'd rather see that added later once we do actually want more than one cross arch tested here.
But I don't feel too strongly, since its not much code and its already written.
.github/workflows/build.yml
Outdated
@@ -185,3 +185,55 @@ jobs: | |||
- run: make clang-debug | |||
- name: tests (wasm2c tests excluding memory64) | |||
run: ./test/run-tests.py wasm2c --exclude-dir memory64 | |||
|
|||
build-arch: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about calling this build-s390x
? Maybe build-arch
harks of Arch linux?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, maybe build-cross
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure! sgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done!
1938a2b
to
e0842b0
Compare
btw now that we have #2386 we re-enabled run-unittests! (that just leaves run-c-api-tests as dead code) |
Co-Authored-By: Alex Reinking <[email protected]>
e0842b0
to
c11434c
Compare
btw qemu does not emulate stack overflows correctly, would have to run the entire thing in machine emulation for that. maybe something to do as future work? (not really relevant when not using signal handler tho) |
is there anything else missing for this? (we took out the c-api-tests since c-api is unsupported on big-endian... maybe component model will provide a better bridge between big-endian and wasm...) |
Happy to go ahead and land this now. Can you remind me for the record why you care about wabt support for little endian? I'm sorry if I've asked before and forgotten the answer? Is it because you are targeting s390 yourself in in production? |
big endian* we really care about old macs, amigas, the wii, the sega genesis. retro computing really. not so much the s390x, the s390x is a bit out of reach for us. maybe one day it'll become retro computing tho! that would be kinda cool. |
Very interesting. And you are wanting to run wasm on actual hardware using these old devices? Or are you wanting to run wasm inside emulators of these devices? |
yep! it'd be cool to run it on real hardware =^-^= |
This adds a cross-compile workflow for s390x. Heavily based on #1971 , but runs significantly faster.