feat: add macro LUA_USE_LIBC_JUMP_PSX

[RodrigoDornelles]

this adjustment makes it easier for those using PSn00bSDK, or some libc implementation for longjmp and setjmp #2

[RodrigoDornelles]

@nicolasnoble If you are interested I can make some customization macros, like LUA_USE_PSN00BSDK_PSX (something I solved with cmake, but I can do with macros), and LUA_USE_FLOAT32 (for those interested in floatpoint via software using the GCC mips compiler)

[nicolasnoble]

Several thoughts here:

• I don't understand how this is a problem to begin with. The whole setjmp/longjmp context is solely within the scope of the ldo.c file, and all abstracted through luai_jmpbuf, LUAI_THROW and LUAI_TRY, none of which leak outside of this file. How can there be any sort of mixup?
• If a third party library is implementing its own incompatible version of setjmp/longjmp with the rest of the operating system of the machine, that's on them, not on users.
• The whole point of this code is to be fully independent and not rely on any third party customization. Adding customizations makes things a lot harder to maintain, debug, and support. What sort of customizations would be desired, aside from the 3 required imports?

[RodrigoDornelles]

I don't understand how this is a problem to begin with. The whole setjmp/longjmp context is solely within the scope of the ldo.c file, and all abstracted through luai_jmpbuf, LUAI_THROW and LUAI_TRY, none of which leak outside of this file. How can there be any sort of mixup?

I believe that the fact that there is another setjmp table may end up conflicting with existing code.

If a third party library is implementing its own incompatible version of setjmp/longjmp with the rest of the operating system of the machine, that's on them, not on users.

I want to use the third-party solution for setjmp, because in my case it worked better, just as you made it possible to customize realloc, sprintf and free, it would be interesting to give the user the option to work with this.

The whole point of this code is to be fully independent and not rely on any third party customization. Adding customizations makes things a lot harder to maintain, debug, and support. What sort of customizations would be desired, aside from the 3 required imports?

if LUA_USE_PSN00BSDK_PSX and LUA_USE_FLOAT32 are out of scope of the project that's fine, I won't send a PR about it, and will create my own luaconf.h for float supporting.

---

The LUA_USE_LIBC_JUMP_PSX is just a line of code that adds an opt-in flag, anyone can use it, and anyone intends to modify the library's behavior, it doesn't involve future maintenance, the small community for this niche lib and if it's something that helps two programmers it has already helped its user base.

[jorgerezen]

Several thoughts here:

• I don't understand how this is a problem to begin with. The whole setjmp/longjmp context is solely within the scope of the ldo.c file, and all abstracted through luai_jmpbuf, LUAI_THROW and LUAI_TRY, none of which leak outside of this file. How can there be any sort of mixup?
• If a third party library is implementing its own incompatible version of setjmp/longjmp with the rest of the operating system of the machine, that's on them, not on users.
• The whole point of this code is to be fully independent and not rely on any third party customization. Adding customizations makes things a lot harder to maintain, debug, and support. What sort of customizations would be desired, aside from the 3 required imports?

I did not understand your point. how could this turn the project harder to maintain?

[nicolasnoble]

So, in the absolute, setjmp/longjmp is totally independent and local. You can absolutely have two different implementations side-by-side with different registers mapping, as long as they get used in a properly balanced fashion, which is why I'm confused about how this is a problem to begin with. There are no global tables, no global state, it's just a single local holder of data which, in the case of Lua, stays on the stack temporarily for the duration of a protected call, and no interaction should happen with anything else outside of this scope.

If you had to modify this to make something work, it means there's a deeper problem somewhere else is what I'm getting at, and doing this change feels like a bandaid to hide a real issue underneath.

[nicolasnoble]

I did not understand your point. how could this turn the project harder to maintain?

Whenever you're introducing new targets into a projects, it means the test matrix augments. Supporting 1, 2, 5, 23 different combinations of build variants means doing all these tests too. No external dependencies means no heavy test matrix, and no special setup to reproduce problems. It also means if a problem arises, if the code is 100% contained and has little to no external interactions, it should be reproducible regardless of the rest of the environment that problem appears on.

[RodrigoDornelles]

I had severe memory problems both in the game and the emulator itself crashing using the self-contained version setjmp, when ended up using a third-party SDK its works, the solution seems a little different to me, after the change had no more problems.

If you want to take a look, I'm starting on the PS1 when it comes to homebrew, my experience is with other consoles, I'm interested in this lib to port my multi-platform engine.

setjmp:
	sw   $ra, 0x00($a0)
	sw   $sp, 0x04($a0)
	sw   $fp, 0x08($a0)
	sw   $s0, 0x0c($a0)
	sw   $s1, 0x10($a0)
	sw   $s2, 0x14($a0)
	sw   $s3, 0x18($a0)
	sw   $s4, 0x1c($a0)
	sw   $s5, 0x20($a0)
	sw   $s6, 0x24($a0)
	sw   $s7, 0x28($a0)
	sw   $gp, 0x2c($a0)

	jr   $ra
	li   $v0, 0

longjmp:
	lw   $ra, 0x00($a0)
	lw   $sp, 0x04($a0)
	lw   $fp, 0x08($a0)
	lw   $s0, 0x0c($a0)
	lw   $s1, 0x10($a0)
	lw   $s2, 0x14($a0)
	lw   $s3, 0x18($a0)
	lw   $s4, 0x1c($a0)
	lw   $s5, 0x20($a0)
	lw   $s6, 0x24($a0)
	lw   $s7, 0x28($a0)
	lw   $gp, 0x2c($a0)

	jr   $ra
	move $v0, $a1

[nicolasnoble]

If you're having memory issues while using a third party library, I would first consider the possibility that the library's memory allocator has an issue. I've been using this psxlua project on several kilobytes, complex Lua files without issues. In fact, I have luac running on the psx directly, able to compile bytecode out from large Lua files. Having a corrupted setjmp context might be an indication a loose pointer got used.

Maybe start from the beginning, use the official psyq libraries, with its known to be working memory allocator, and verify the behavior there is correct or not, in order to try and narrow further the troubleshooting.

[RodrigoDornelles]

I'm not very interested in using the original SDK, as it is for Windows, and I would have to use Wine, currently my development environment only needs cmake and make and I made a buildsystem manifest where it downloads all the dependencies including compilers and libs in a local folder for the project, when I made this change to setjmp, a very large lua bytecode started to work without problems, and also luac for codes inserted by the engine user.

[nicolasnoble]

I'm not very interested in using the original SDK, as it is for Windows, and I would have to use Wine

That is not correct. The libraries have been converted to modern gcc, and can be used on any modern operating system. See https://github.com/ABelliqueux/nolibgs_hello_worlds with some examples, https://github.com/Ay91169/PSGame, or other similar projects and documentation.

when I made this change to setjmp, a very large lua bytecode started to work without problems, and also luac for codes inserted by the engine user.

I highly suspect the problem is elsewhere, honestly, and that you've only displaced it.

[nicolasnoble]

when I made this change to setjmp, a very large lua bytecode started to work without problems, and also luac for codes inserted by the engine user.

The other question I have is how did you narrow it down to setjmp / longjmp exactly? What was your troubleshooting process?

[RodrigoDornelles]

The other question I have is how did you narrow it down to setjmp / longjmp exactly? What was your troubleshooting process?

I was doing eliminations and testing different combinations of Lua and C code, I tested different allocators, among other things that the port modifies, in the end I got good results using I started changing the setjmp syscall.

If you want to see the project I'm working on, you just need to have cmake so the dependencies are managed locally.
https://github.com/gamelly/core-native-ps1

https://github.com/gamelly/core-native-ps1/blob/2785bcc02e9f41a364ae0e7709e1a319f4bac26f/CMakeLists.txt#L122-L132