s390x support

[iii-i]

Hi,

Please consider pulling s390x architecture support (originally developed as part of moonjit).
This branch was created as follows:

• Applied luajit-s390x.patch from luajit-2.1.0-0.18beta3.fc33.src.rpm to v2.1.0-beta3 tag
• Rebased to v2.1 branch
• Added two fixes

The result passes most of the moonjit testsuite on x86_64 and s390x.
What fails are tests for new language features and nonportable artithmetic, which should be OK.

I've decided to go this way instead of taking commits from the moonjit repo, because Fedora version of LuaJIT can be considered battle-tested, and the goal here is to integrate this stable code upstream with minimum changes possible. The rest of s390x support from moonjit (if any) can go in separately later.

[Sarah-Kriesch]

Is there any problem with merging this PR, where we can support?

[sindrom91]

This doesn't really look finished. It seems to have some files that should not really be there (DynASM tests, bash script), some stuff that is copied from ARM and left unchanged. It is mentioned that moonjit tests are passing, but the question is if LuaJIT tests are passing?

I would suggest to clean up the DynASM port first and try to get it in and then make a separate PR for the interpreter. It will probably be easier for maintainer to review that way, since there is a lot of code involved.

Note that I'm not a maintainer.

[levivic]

Can anyone move forward this PR? We have potential products/customers depending on Luajit on ibm s390x platforms.

[teward]

The Lua module for nginx now requires luajit to function. As a result, it is now impossible to build nginx for s390x arch in Debian because there is zero support for s390x in LuaJIT. Can this get put in a higher priority list for the LuaJIT team?

[lysliu]

Assume https://github.com/openresty/luajit2 has s390x support, I have s390x native environment, testing with it.
And I will create a PR if needed.

[iii-i]

I've rebased the code on top of the latest v2.1; squashed all commits; added a short description, which I will quote below for convenience; removed unnecessary debug code and fixed a few stylistic issues. I did not split out the DynASM support yet, but I think it's a good idea and I will look into it.

Add s390x architecture support

s390x (IBM Z) is an architecture of server computers produced by IBM.
It is supported by a number of open source code generators, such as
GCC, LLVM, OpenJDK, eBPF, QEMU, Valgrind and Cranelift. One of the
missing pieces in the ecosystem support is LuaJIT.

The s390x support for LuaJIT was initially developed by @ketank-new,
@mundaym and @niravthakkar. It found its way into moonjit and luajit2
forks, as well as Fedora distro (as a patch). There were also smaller
contributions by @preetikhorjuvenkar, @Bisht13, @velemas and @iii-i.

This is a cumulative patch of the work mentioned above. It contains
all the contributions squashed together, plus minor stylistic
cleanups. It passes all the tests from LuaJIT-test-cleanup, except
for contents.lua, which fails on x86_64 as well.

[juru1234]

Tested with neovim on s390x. Works for me.

[dev-japo]

I've tested it on s390 and on x64.
Note, there is an additional warning on x64 systems:

lj_ccall.c: In function ‘ccall_set_args’:
lj_ccall.c:1025:34: warning: variable ‘onstack’ set but not used [-Wunused-but-set-variable]
 1025 |     MSize n, isfp = 0, isva = 0, onstack = 0;
      |                                  ^~~~~~~

the LJ_TARGET_S390X switch hides the logic not the declaration.

Link against noevim on s390x works as expected no issues found.

Thank you very much @iii-i

[mcepl]

Tested with neovim on s390x. Works for me.

Yes, builds on s390x with openSUSE/Factory. Thank you.

[juru1234]

@MikePall Is there a chance that this will be merged soon?

[iii-i]

• Fixed the warning.
• Split out the DynASM changes.

[skriesch]

@MikePall Can you merge it, please? It is already tested by different Linux distributions and other open source community members.

[NeilHanlon]

I have tested this builds and runs well on s390x on RHEL/CentOS Stream

[lysliu]

I have tested this builds and runs well on s390x on Ubuntu 20.04

[dev-japo]

Hello @MikePall,
is there a missing requirement, to merge this pull request?

[iii-i]

• Rebased.

[niklas88]

Dear @MikePall ,

I'm writing to you not in my capacity as an IBM employee but on a Sunday afternoon on my personal time and
as a fellow Open Source developer with personal interest in this PR. Because of the lack of s390x support in
LuaJIT, I and several of my colleagues have to keep compiling Neovim from source to use it on s390x.
That's not a big burden of course but it is annoying considering all the pieces to make things work properly are there.

I believe there has been some conflict between you and IBM in the past but respectfully, this is getting ridiculous.
For 4 years this PR has been continuously updated and rebased. The code has been tested and even added as downstream patches in several distributions with Fedora 41 development trees just as the latest example.
And yet you have not commented on any of the s390x PRs with a single request to change something, a
single objective argument why you can't support the code or anything at all. No one is asking you to like IBM,
or to put unreasonable extra work into this. but I do ask that you give this PR a fair chance especially considering
how very clearly people are willing to step up to help fix any issues it might cause down the road.

In my opinion this is also a question of respect, yes @iii-i is getting paid for this work but he, the people
who worked on earlier versions of this and everyone involved here are real people, putting in real effort, time and
energy. They have been showing a tremendous amount of patience despite the lack of progress. Please Mike treat
that with the respect it deserves not for IBM's sake but out of solidarity with your fellow developers and users.

Thank you,
Niklas Schnelle

[mcepl]

For 4 years this PR has been continuously updated and rebased. The code has been tested and even added as downstream patches in several distributions with Fedora 41 development trees just as the latest example.

We (I am a SUSE employee) have this patch in our enterprise products as well, not mentioning openSUSE, where it is, as well, continuously tested on s390x. So, it is +1000 from me for the merging of the patch.