To stop Ruby's garbage collector from freeing Ruby `VALUE`s while we're
in the middle of using them in libretro builds, we need to make sure all
the `VALUE`s we use are on the sandbox's stack.
Also, to allow Ruby to recognize `VALUE`s on the sandbox's stack on
big-endian targets, I've changed the serialization of `VALUE`s. Before,
any `VALUE`s returned by a sandbox function were always converted to the
target's endian, and any `VALUE`s passed to sandbox functions as
argument were then converted back to WebAssembly's endianness,
little-endian. Now, `VALUE`s are always little-endian; they are no
longer converted to the target's endianness. That should be fine since
`VALUE`s are supposed to be opaque values.
I've decided to stop gambling with ways to make `-e` not crash Ruby on
startup in libretro builds (see commit
1473416a5a for context). Making Ruby load
a dummy script seems to work better.
It has come to light that the global bindings generated by wasm2c are
not the globals themselves, but rather pointers to the memory locations
where the globals are stored. I've updated sandbox-bindgen.rb to take
this into account.
Now that GitHub has finished upgrading the `ubuntu-latest` image to
Ubuntu 24.04, we can just use `ubuntu-latest`. We need at least Ubuntu
24.04 because the version of WABT from earlier versions of Ubuntu is too
old.
Guys, I think I'm going insane. Every time I build the libretro Ruby
sandbox with a different version of Ruby, or even when I build Ruby at a
different path on my computer, there's some chance that the builds
produced with that version of Ruby and/or that path on my computer
result in Ruby crashing on startup in libretro builds. I've been
tweaking these command-line arguments that are passed to Ruby for a
while now, and I *think* these are the correct ones that will stop Ruby
from crashing.
I'll also add PlayStation Vita and Xbox once I figure out how.
Other than that, I think that's all the game consoles RetroArch supports
that aren't Linux-based!
This executor has the advantage of being able to work correctly when
there are Ruby stack frames underneath C/C++ stack frames in the stack.
Still need to implement handling Ruby fibers.
Apparently passing extra tools into `NATIVE_TOOLCHAIN` and
`WASI_TOOLCHAIN` in the phase 1 Makefile breaks libretro builds in
GitHub Actions - binaries built using those phase 1 files are unable to
start up the Ruby VM, although there are no compilation errors. Doesn't
happen when I build phase 1 on my computer though... Nonetheless, I've
removed the extra stuff from `NATIVE_TOOLCHAIN` and `WASI_TOOLCHAIN` in
the Makefile.
Also I've added code into the GitHub Actions workflows to strip the
libretro cores. Enabling LTO in GitHub Actions caused the libretro cores
produced to swell to enormous size compared to when built without LTO
due to the extra debug information added by LTO. However, with stripping
enabled, stripped binaries built with LTO are actually somewhat smaller
than stripped binaries built without LTO.
We can't have them as normal functions because reentrant calls into the
Ruby API don't work if you do that, i.e. calling into the Ruby API and
that calls mkxp-z's bindings and that calls back into the Ruby API.
* Ruby is no longer required to be already installed to build phase 1
* Commands and versions for everything are now configurable
* The `-j` Make flag is now respected
The old arguments were invoking undefined behaviour that may or may not
cause crashes when initializing Ruby depending on which path on the
build machine Ruby was built on!
WebAssembly is little-endian regardless of what machine you run it on,
so the WebAssembly implementation needs to know if the machine is
big-endian or little-endian to function properly.
Apparently `environ` is some kind of reserved word in MSYS2's build
environment, which caused hard-to-understand linking errors on Windows
due to one of the functions in wasi.cpp having an argument named
`environ`. I've changed the name of the offending argument to `env`.
I've also added `extern "C"` to all exported functions to make sure
something like this doesn't happen again - the compiler should now
refuse to compile the code if there are function signature mismatches in
exported functions.
