s390x support for Luajit #395

ketank-new · 2018-02-14T11:33:27Z

Added necessary code to support arch s390x in Luajit.

Guesses for now based on the ELF ABI supplement for zSeries.

Stick to the default until we know what we actually need.

Added missing elif condition for s390x for GCC dependency

Removing the gcc check for now .. missed micheal's comment earlier

changed instruction opcode to 64bit

Added s390x specific condition codes

made some changes like mentioning arch from x86 to S390x removed some x86 specific code

Added CFrame definations for S390X values un assigned as i am unsure of the values

Referred arm dasc file have created slots wherein i have to replace them with s390x registers and instructions

Assigned general purpose register to existing macros

Added definitions to macros savereg and restreg used Store and Load instructions to store and load register contents to n from memory

These are educated guesses at this point. We might need more stack space because we don't have many free registers available.

I believe these macros obey the C calling convention, so we need to allocate our stack frame and save all callee-save registers. We can tune it later if it turns out we don't need all the registers.

f8-f15 are callee-saved (not f0,f2,f4 and f6). There isn't space for them in the caller's stack frame so we need to increase the size of the interpreter's stack frame.

Still guessing at this point. This code will need to be changed.

used MOVE LONG EXTENDED in place of mov and MOVE LONG instead of movzx

added instructions to macros, referring macro defination of x86 for macro ins_ANDdid not find equivalent s390x replacement instruction for 'Not' hence have currently marked the place as '????' '????' has to be replaced with s390x complement instruction

added definations to macros to test operand type refeered x86 definations no JUMP instruction found for s390x used BRANCH RELATIVE on CONDITION instead (brc) Not sure how the condition will be checked , need to discuss this

The extra check for register is currently ignored, and trying to see what value does the encode function return. Its still to be worked out, how this value is used later, after decoding.

We can discuss if we need to keep it 6 bytes or 8 bytes long, Not clear enough to me as well

I have added the number depending on the number of operands, pls check for the ones which access memory. Also For base register and displacement, should I assume that it will be passed in the same order as it is expected, since I dont have any means to see the output, I am confused a bit for those add modes. Since we decided to test RR first, thats in progress, but would like to add others as well.

- Fix syntax errors - Fix whitespace (use two-space indentation to match surrounding code)

It's convenient for sp to be a pseudonym for r15 (the stack pointer). 'or_2' doesn't need to be special cased ('or' did because it is a keyword).

Each memory operand will be a single parameter so we also need to update the instruction encoding nargs field.

Also sets the action list type to unsigned short (uint16_t) which I think is the most appropriate type for s390x (x86 uses uint8_t and other platforms use uint32_t).

sharkcz · 2019-04-17T11:25:43Z

@siddhesh , if you would look for some s390x and ppc64le hw for things like CI, let me know, we can arrange that.

jmertic · 2019-04-17T11:47:34Z

Let me know if you need s390x hardware access for CI or testing - happy to help provide.

sharkcz · 2019-04-18T07:51:19Z

I did a quick test on a zEC12 machine running Fedora 29 with "make all check bench" and all looks good.

siddhesh · 2019-04-18T08:55:10Z

Thanks for testing, I'll merge it into my v2.1 and work on getting it into Fedora.

siddhesh · 2019-04-24T10:32:18Z

Hi, I have now merged the s390x port into my tree in v2.1 branch and also pushed the patch into Fedora rawhide[1]. F30 is already branched so this will automatically go into F31, but I'll also check with Igor to see if he is comfortable backporting the patches to F30.

I've started pushing my branch patches into Debian, which is a bit slow going (since I am less familiar with Debian processes than Fedora) but the maintainer has agreed in principle to accept patches.

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1254116

sharkcz · 2019-04-24T10:37:26Z

Sounds good, I suppose there is a plan for long term maintenance of the fork, right?

siddhesh · 2019-04-24T10:47:37Z

Sounds good, I suppose there is a plan for long term maintenance of the fork, right?

For now my goal is to try and regain the lost momentum on the project by cherry-picking PRs into my fork and them pushing them into distributions and staying in sync with this repo at the same time. Please get in touch with me on siddhesh at gotplt dot org to continue the discussion on the fork since this PR may not be the best place to do that.

kamiyaa · 2020-01-31T16:22:00Z

Any updates on if this will be merged?

yselkowitz · 2020-03-25T23:06:05Z

I'm having an issue building lyaml with this patchset. If you install gcc, git, libyaml-devel, and the patched luajit, checkout lyaml, and run luajit build-aux/luke, I get:

luke: fatal: no modules table in 'lukefile', nothing to build

I don't see this with lua on s390x, or with (patched) luajit on other arches that I have tried.

iii-i · 2020-03-31T14:29:00Z

lyaml issue is fixed by moonjit#107

ccorley · 2020-10-08T14:01:01Z

We also would like to run Kong on s390x, which requires LuaJIT. @MikePall could you please shed some light on what it would take to get PR #395 merged?

rinaldou · 2020-10-13T16:41:11Z

Hi ccorley!
I was able to build kong on s390x (RHEL 8).
Check this one https://github.com/openresty/luajit2/pull/89/files
After I corrected this file, I was able to build lyaml on s390x.
On kong, run kong build tools to create the appropriate requirements.
Good luck!

ccorley · 2020-10-15T12:14:24Z

Thanks, rinaldou! After I pulled that fix in, I was able to build as well. For anyone else that runs into this, I created a LuaJIT patch for that 2-line change from the OpenResty 1.17.8.2 source, then applied the patch during the kong-build-tools package-kong step. Also important, I used the kong 'next' source branch.

skriesch · 2021-02-01T16:59:09Z

What is the status here?
If you require any test environment, you can use the LinuxONE Community Cloud. The usage is free for Open-Source Developers:
https://developer.ibm.com/components/ibm-linuxone/gettingstarted/

jmertic · 2021-02-01T17:00:38Z

From my understanding, they have an instance for testing. Not sure what other blockers exist

siddhesh · 2021-02-01T17:06:52Z

From my understanding, they have an instance for testing. Not sure what other blockers exist

That's me (moonjit) who has that instance, which is different from LuaJIT/LuaJIT. Given that I'm not actively involved in either project, please feel free to take that instance back and offer it to Mike. I don't have anything to salvage from that instance.

membphis · 2021-02-22T15:24:09Z

need to resolve the conflicting files first

iii-i · 2021-02-22T15:54:40Z

@membphis FWIW I submitted a rebased version here: #631

Sarah-Kriesch · 2021-03-02T10:42:15Z

Thank you for this engagement! We would be happy about this enablement.

teward · 2022-04-03T19:21:16Z

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?

LoganDark · 2022-05-06T20:14:19Z

Considering the fact that this PR has been sitting for over 4 years with absolutely zero response from LuaJIT or anyone even remotely connected to LuaJIT (not members or even contributors), I have doubts that this will ever be merged or even acknowledged.

The best course of action here is to abandon all hope of getting this merged upstream, and make a high-quality third-party package/distribution that everyone can depend on.

glaubitz · 2022-05-12T07:41:10Z

This PR needs some clean-up. I don't think it's reasonable to merge it with 261 individual commits.

nealef · 2022-05-12T14:16:12Z

I am working with the Open Mainframe Project (part of the Linux Foundation) to get this cleaned up and to address the concerns in #395 (comment). We hope to get this done over the next couple of months and to generate a PR that is more acceptable.

Bisht13 · 2022-06-21T23:49:08Z

I'm currently working with the Open Mainframe Project under @nealef on cleaning this PR, resolving merge conflicts and addressing any other concerns with a goal of merging it in couple of months.

I'll be splitting this PR into 2 or more PRs for easier reviewing purposes.

skriesch · 2023-08-08T16:57:54Z

The mentorship program by the Linux Foundation is finished and the s390x support is provided by #891 .
Linux distributions are waiting for a working Luajit for s390x! Can you accept the PR, please?

You can receive a Linux vm for verification for free for 120 days on a mainframe via this link: https://developer.ibm.com/articles/get-started-with-ibm-linuxone/

If you want to receive long-term access as an Open Source Community Member, you can use this form with a reference to the special open source project: https://www.ibm.com/community/z/open-source/virtual-machines-request/

Choosable Linux distributions: SLES (upgradable to openSUSE), RHEL, Ubuntu, debian

mundaym and others added 30 commits November 15, 2016 14:44

Add some s390x C calling convention constants.

71d40ba

Guesses for now based on the ELF ABI supplement for zSeries.

Delete gcc version check for now.

820fa8a

Stick to the default until we know what we actually need.

Update lj_arch.h

3e472eb

Added missing elif condition for s390x for GCC dependency

Update lj_arch.h

31fb648

Removing the gcc check for now .. missed micheal's comment earlier

Update lj_target_s390x.h

498f028

changed instruction opcode to 64bit

Changed the encoding for add,and,branch instructions

dcb977d

Update lj_target_s390x.h

777b067

Added s390x specific condition codes

Update vm_s390x.dasc

547b158

made some changes like mentioning arch from x86 to S390x removed some x86 specific code

Update lj_frame.h

c36895a

Added CFrame definations for S390X values un assigned as i am unsure of the values

Update vm_s390x.dasc

4aa1099

Referred arm dasc file have created slots wherein i have to replace them with s390x registers and instructions

Update vm_s390x.dasc

3ac644e

Assigned general purpose register to existing macros

Look for s390x file rather than S390x file.

e90d985

Update vm_s390x.dasc

31c0e60

Added definitions to macros savereg and restreg used Store and Load instructions to store and load register contents to n from memory

Add preliminary frame offsets.

d50f8aa

These are educated guesses at this point. We might need more stack space because we don't have many free registers available.

Cleanup.

d505a0e

Fixup the save/restore register macros.

5a69b46

I believe these macros obey the C calling convention, so we need to allocate our stack frame and save all callee-save registers. We can tune it later if it turns out we don't need all the registers.

Fix stack frame layout.

dbf7895

f8-f15 are callee-saved (not f0,f2,f4 and f6). There isn't space for them in the caller's stack frame so we need to increase the size of the interpreter's stack frame.

Add assembly for decoding instructions.

5887962

Still guessing at this point. This code will need to be changed.

Update vm_s390x.dasc

372f721

used MOVE LONG EXTENDED in place of mov and MOVE LONG instead of movzx

Update vm_s390x.dasc

4ea7607

added instructions to macros, referring macro defination of x86 for macro ins_ANDdid not find equivalent s390x replacement instruction for 'Not' hence have currently marked the place as '????' '????' has to be replaced with s390x complement instruction

Update vm_s390x.dasc

3288e54

added definations to macros to test operand type refeered x86 definations no JUMP instruction found for s390x used BRANCH RELATIVE on CONDITION instead (brc) Not sure how the condition will be checked , need to discuss this

Added s390x instructions with their encoding

9b01b4d

Add extended mnemonics for branches.

cac5d4f

Removed the extra check in parse_reg

2030065

The extra check for register is currently ignored, and trying to see what value does the encode function return. Its still to be worked out, how this value is used later, after decoding.

Updated size of the instruction word

538a4af

We can discuss if we need to keep it 6 bytes or 8 bytes long, Not clear enough to me as well

Various cleanup of dasm_s390x.lua

0e32411

- Fix syntax errors - Fix whitespace (use two-space indentation to match surrounding code)

Add sp -> r15 mapping and don't special case or_2

89ca41c

It's convenient for sp to be a pseudonym for r15 (the stack pointer). 'or_2' doesn't need to be special cased ('or' did because it is a keyword).

Add stubs for parsing memory operands and delete unwanted code.

36479af

Each memory operand will be a single parameter so we also need to update the instruction encoding nargs field.

Add a description of how immediate actions should be encoded.

d97dea2

Also sets the action list type to unsigned short (uint16_t) which I think is the most appropriate type for s390x (x86 uses uint8_t and other platforms use uint32_t).

abhay1722 mentioned this pull request Apr 29, 2019

Add support for s390x openresty/luajit2#50

Closed

J0WI mentioned this pull request May 6, 2019

main/nginx: upgrade to 1.16.0 alpinelinux/aports#7223

Closed

J0WI mentioned this pull request Oct 6, 2019

main/luajit: add support for s390x alpinelinux/aports#7666

Closed

LuaJIT deleted a comment from jmertic Feb 23, 2021

xet7 mentioned this pull request Jan 21, 2024

wrk for s390x with cosmocc or blink? jart/blink#163

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

s390x support for Luajit #395

s390x support for Luajit #395

ketank-new commented Feb 14, 2018

sharkcz commented Apr 17, 2019

jmertic commented Apr 17, 2019

sharkcz commented Apr 18, 2019

siddhesh commented Apr 18, 2019

siddhesh commented Apr 24, 2019

sharkcz commented Apr 24, 2019

siddhesh commented Apr 24, 2019

kamiyaa commented Jan 31, 2020

yselkowitz commented Mar 25, 2020 •

edited

iii-i commented Mar 31, 2020

ccorley commented Oct 8, 2020

rinaldou commented Oct 13, 2020

ccorley commented Oct 15, 2020

skriesch commented Feb 1, 2021

jmertic commented Feb 1, 2021 via email

siddhesh commented Feb 1, 2021

membphis commented Feb 22, 2021

iii-i commented Feb 22, 2021

Sarah-Kriesch commented Mar 2, 2021

teward commented Apr 3, 2022

LoganDark commented May 6, 2022

glaubitz commented May 12, 2022

nealef commented May 12, 2022

Bisht13 commented Jun 21, 2022 •

edited

skriesch commented Aug 8, 2023 •

edited

s390x support for Luajit #395

Are you sure you want to change the base?

s390x support for Luajit #395

Conversation

ketank-new commented Feb 14, 2018

sharkcz commented Apr 17, 2019

jmertic commented Apr 17, 2019

sharkcz commented Apr 18, 2019

siddhesh commented Apr 18, 2019

siddhesh commented Apr 24, 2019

sharkcz commented Apr 24, 2019

siddhesh commented Apr 24, 2019

kamiyaa commented Jan 31, 2020

yselkowitz commented Mar 25, 2020 • edited

iii-i commented Mar 31, 2020

ccorley commented Oct 8, 2020

rinaldou commented Oct 13, 2020

ccorley commented Oct 15, 2020

skriesch commented Feb 1, 2021

jmertic commented Feb 1, 2021 via email

siddhesh commented Feb 1, 2021

membphis commented Feb 22, 2021

iii-i commented Feb 22, 2021

Sarah-Kriesch commented Mar 2, 2021

teward commented Apr 3, 2022

LoganDark commented May 6, 2022

glaubitz commented May 12, 2022

nealef commented May 12, 2022

Bisht13 commented Jun 21, 2022 • edited

skriesch commented Aug 8, 2023 • edited

yselkowitz commented Mar 25, 2020 •

edited

Bisht13 commented Jun 21, 2022 •

edited

skriesch commented Aug 8, 2023 •

edited