S390x: add preliminary support for SystemZ

[liushuyu]

This pull request adds preliminary support for IBM Z systems (running in z/Architecture mode).

[Gayathri-Berli]

Thank you for bringing it to our attention. We will check internally and confirm.

[uweigand]

Many thanks for working on the SystemZ port! I'll have a look at the details.

[kalev]

I tried to build this on s390x on Fedora rawhide, using gdc as a bootstrap compiler and ran into the following error:

core/thread/osthread.d(1648): Error: cannot implicitly convert expression `regs[9]` of type `ulong` to `void*`
core/thread/osthread.d(1648): Error: cannot implicitly convert expression `regs[9]` of type `ulong` to `void*`
core/thread/osthread.d(1648): Error: cannot implicitly convert expression `regs[9]` of type `ulong` to `void*`
core/thread/osthread.d(1648): Error: cannot implicitly convert expression `regs[9]` of type `ulong` to `void*`

Any ideas what's going on?

[liushuyu]

I tried to build this on s390x on Fedora rawhide, using gdc as a bootstrap compiler and ran into the following error:

core/thread/osthread.d(1648): Error: cannot implicitly convert expression `regs[9]` of type `ulong` to `void*`
core/thread/osthread.d(1648): Error: cannot implicitly convert expression `regs[9]` of type `ulong` to `void*`
core/thread/osthread.d(1648): Error: cannot implicitly convert expression `regs[9]` of type `ulong` to `void*`
core/thread/osthread.d(1648): Error: cannot implicitly convert expression `regs[9]` of type `ulong` to `void*`

Any ideas what's going on?

This is now fixed.

[kalev]

Thanks! With this, I was able to build an initial version of ldc (using gdc), but when I try to build ldc with itself, it now fails with the following:

/usr/bin/ld: lib64/libldc.a(asmstmt.cpp.o)(.text+0x1d02): misaligned symbol `_ZN3Loc12messageStyleE' (0x1efc009) for relocation R_390_PC32DBL
/usr/bin/ld: final link failed
collect2: error: ld returned 1 exit status

[kinke]

Wrt. SystemZ CI, we apparently could

1. apply for a free VM from IBM: https://community.ibm.com/zsystems/form/l1cc-oss-vm-request/
2. install a GitHub Actions runner on it: https://github.com/anup-kodlekere/gaplib
3. target it in our GHA YAML (using GDC as host compiler for now), to see how bad the test failures are

[uweigand]

Wrt. SystemZ CI, we apparently could

1. apply for a free VM from IBM: https://community.ibm.com/zsystems/form/l1cc-oss-vm-request/

2. install a GitHub Actions runner on it: https://github.com/anup-kodlekere/gaplib

3. target it in our GHA YAML (using GDC as host compiler for now), to see how bad the test failures are

Yes, that would definitely be an option - that is the intended purpose of those VMs we make available.

As an alternative, some projects go the route of running SystemZ tests under qemu (see e.g. https://github.com/bytecodealliance/wasmtime/blob/main/.github/workflows/main.yml). For performance reasons, in this case it might be preferable to run the compiler natively (as cross-compiler) and only run the resulting test cases in qemu.

[JohanEngelen]

Wrt. SystemZ CI, we apparently could

1. apply for a free VM from IBM: https://community.ibm.com/zsystems/form/l1cc-oss-vm-request/

2. install a GitHub Actions runner on it: https://github.com/anup-kodlekere/gaplib

3. target it in our GHA YAML (using GDC as host compiler for now), to see how bad the test failures are

Yes, that would definitely be an option - that is the intended purpose of those VMs we make available.

Is that a task you are willing to pick up? Thanks!

[uweigand]

Wrt. SystemZ CI, we apparently could

1. apply for a free VM from IBM: https://community.ibm.com/zsystems/form/l1cc-oss-vm-request/

2. install a GitHub Actions runner on it: https://github.com/anup-kodlekere/gaplib

3. target it in our GHA YAML (using GDC as host compiler for now), to see how bad the test failures are

Yes, that would definitely be an option - that is the intended purpose of those VMs we make available.

Is that a task you are willing to pick up? Thanks!

I could certainly set up the machine and the Actions runner. For integration with your CI I'd probably need help from someone who understands its current setup ...

[kinke]

I could certainly set up the machine and the Actions runner.

Thanks, that'd be great!

For integration with your CI I'd probably need help from someone who understands its current setup ...

No worries, once we have a registered runner, we can take over. According to https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners, the registration requires a token from us, which is valid for one hour. So a bit of timely coordination will be required.

[jacob-carlborg]

As an alternative, some projects go the route of running SystemZ tests under qemu (see e.g. bytecodealliance/wasmtime@main/.github/workflows/main.yml)

You can run it under QEMU much simpler by using Docker: https://github.com/jacob-carlborg/lime/blob/1c457159eb3e435c85bfad9ab2aae8b1c6f55e94/.github/workflows/ci.yml#L217-L233.