The GC compaction mechanism implements a kind of read barrier by marking
some (OS) pages as unreadable, and installing a SIGBUS/SIGSEGV handler
to detect when they're accessed and invalidate an attempt to move the
object.
Unfortunately, when a debugger is attached to the Ruby interpreter on
Mac OS, the debugger will trap the EXC_BAD_ACCES mach exception before
the runtime can transform that into a SIGBUS signal and dispatch it.
Thus, execution gets stuck; any attempt to continue from the debugger
re-executes the line that caused the exception and no forward progress
can be made.
This makes it impossible to debug either the Ruby interpreter or a C
extension whilst compaction is in use.
To fix this, we disable the EXC_BAD_ACCESS handler when installing the
SIGBUS/SIGSEGV handlers, and re-enable them once the compaction is done.
The debugger will still trap on the attempt to read the bad page, but it
will be trapping the SIGBUS signal, rather than the EXC_BAD_ACCESS mach
exception. It's possible to continue from this in the debugger, which
invokes the signal handler and allows forward progress to be made.
THREAD_MODEL is exported already, so this matches that. Exporting this
is simpler than inspecting configure_args and arch and matching that up
with a specific configure.ac.
Fix GH-5976
* add coroutines for ppc & ppc64
* fix universal coroutine to include ppc & ppc64
* add powerpc*-darwin to configure.ac
* fix thread_pthread for older systems
Note this change is only for `configure.ac`, not for Windows using
`win32/configure.bat`.
```
$ ./configure --help | grep mkmf
--enable-mkmf-verbose enable verbose in mkmf
```
Run the following command to enable the mkmf verbose mode.
```
$ ./configure --enable-mkmf-verbose
$ grep MKMF_VERBOSE config.status
S["MKMF_VERBOSE"]="1"
```
In this mkmf verbose mode, when compiling a native extension, the
`rake compile` prints the compiling commands such as
"gcc -I. <...> path/to/file" instead of "compiling path/to/file".
```
$ git clone https://github.com/deivid-rodriguez/byebug.git
$ cd byebug
$ bundle install --standalone
$ bundle exec rake compile
...
gcc -I. <...> path/to/file
...
```
This fixes a bug where Ruby on macOS running on ARM would try to look in
`/usr/local/lib` for things to link against, but the libraries in that
directory are from the x86 installation of Homebrew
[ruby-core:108424]
In December 2021, we opened an [issue] to solicit feedback regarding the
porting of the YJIT codebase from C99 to Rust. There were some
reservations, but this project was given the go ahead by Ruby core
developers and Matz. Since then, we have successfully completed the port
of YJIT to Rust.
The new Rust version of YJIT has reached parity with the C version, in
that it passes all the CRuby tests, is able to run all of the YJIT
benchmarks, and performs similarly to the C version (because it works
the same way and largely generates the same machine code). We've even
incorporated some design improvements, such as a more fine-grained
constant invalidation mechanism which we expect will make a big
difference in Ruby on Rails applications.
Because we want to be careful, YJIT is guarded behind a configure
option:
```shell
./configure --enable-yjit # Build YJIT in release mode
./configure --enable-yjit=dev # Build YJIT in dev/debug mode
```
By default, YJIT does not get compiled and cargo/rustc is not required.
If YJIT is built in dev mode, then `cargo` is used to fetch development
dependencies, but when building in release, `cargo` is not required,
only `rustc`. At the moment YJIT requires Rust 1.60.0 or newer.
The YJIT command-line options remain mostly unchanged, and more details
about the build process are documented in `doc/yjit/yjit.md`.
The CI tests have been updated and do not take any more resources than
before.
The development history of the Rust port is available at the following
commit for interested parties:
1fd9573d8b
Our hope is that Rust YJIT will be compiled and included as a part of
system packages and compiled binaries of the Ruby 3.2 release. We do not
anticipate any major problems as Rust is well supported on every
platform which YJIT supports, but to make sure that this process works
smoothly, we would like to reach out to those who take care of building
systems packages before the 3.2 release is shipped and resolve any
issues that may come up.
[issue]: https://bugs.ruby-lang.org/issues/18481
Co-authored-by: Maxime Chevalier-Boisvert <maximechevalierb@gmail.com>
Co-authored-by: Noah Gibbs <the.codefolio.guy@gmail.com>
Co-authored-by: Kevin Newton <kddnewton@gmail.com>
We have received reports of build failures due to this configuration
check modifying compile flags. Since only YJIT devs use this library
we can remove it to make Ruby easier to build for users.
See: https://github.com/rbenv/ruby-build/discussions/1933
The `CC` found by `AC_CHECK_TOOL` is prefixed by the host triplet
when cross compiling. To search for commands with `AC_CHECK_TOOL`
based on that `CC` means to search also doubly prefixed names.
As MinGW has the declaration, the `dllimport` attribute difference
is warned when compiling missing/*.c without including ruby/win32.h.
```
../src/include/ruby/missing.h:316:17: warning: 'execv' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
316 | RUBY_EXTERN int execv(const char *, char *const []);
| ^~~~~
```
Winsock's `shutdown` is incompatible with the other platforms.
And autoconf fails to detect WINAPI functions on 32bit Windows,
probably due to the argument size suffixes.
configure.ac: setup build tools and register objects
main.c: wrap main with rb_wasm_rt_start to handle asyncify unwinds
tool/m4/ruby_wasm_tools.m4: setup default command based on WASI_SDK_PATH
environment variable. checks wasm-opt which is used for asyncify.
tool/wasm-clangw wasm/wasm-opt: a clang wrapper which replaces real
wasm-opt with do-nothing wasm-opt to avoid misoptimization before
asyncify. asyncify is performed at POSTLINK, but clang linker driver
tries to run optimization by wasm-opt unconditionally. inlining pass
at wasm level breaks asyncify's assumption, so should not optimize
before POSTLIK.
wasm/GNUmakefile.in: wasm specific rules to compile objects
These flags are very wasi-libc version specific, so updating wasi-libc
may break the build. But supporting multiple wasi-libc versions in ruby
doesn't have much benefit because wasi-libc is not installed in most
systems.
The madvise() declaration should always be compiled on Solaris
to check whether the declaration is good on the environment.
For the purpose, the #if line is unnecessary.
(There was also a trivial typo that the #if was not closed
by #endif and the check always failed with preprocessor error.)
SunC
```
"cont.c", line 24: identifier redeclared: madvise
current : function(pointer to char, unsigned int, int) returning int
previous: function(pointer to void, unsigned int, int) returning int : "/usr/include/sys/mman.h", line 232
```
GCC
```
cont.c:24:12: error: conflicting types for 'madvise'
24 | extern int madvise(caddr_t, size_t, int);
| ^~~~~~~
In file included from cont.c:16:
/usr/include/sys/mman.h:232:12: note: previous declaration of 'madvise' was here
232 | extern int madvise(void *, size_t, int);
| ^~~~~~~
```
On Solaris, madvise(3C) is NOT defined for SUS (XPG4v2) or later,
but MADV_* macros are defined when __EXTENSIONS__ is defined.
This may cause compile error on Solaris 10 with GCC when
"-Werror=implicit-function-declaration" and "-D_XOPEN_SOURCE=600"
are added by configure.
This allows easy differentiation between ABI incompatible platforms like MSWIN64 and MSVCRT-based MINGW32.
This also implicates a distinct rubygem platform which is also "x64-mingw-ucrt".
Although the term "mingw32" is the OS-part for 64 bit systems as well, the "32" is misleading and confusing for many users.
Therefore the new platform string drops the "32" from the OS part to just "mingw".
This conforms to the common practice of windows platform testing per RUBY_PLATFORM=~/mswin|mingw/ .
Find jemalloc header first, then using the found header, try [with
mangle, without mangle] x [no more additional libraries, adding
jemalloc] combination.
It is reported that combination of `--enable-shared --with-jemalloc`
breaks on Debian bullseye (testig). Deeper investigation revealed that
this system's `ld(1)` is patched, to turn `ld --as-needed` on by
default.
This linker flag strips "unnecessary" library dependencies from an
executable. In case of `ruby(1)` (of `--enable-shared`), because
everything is in `libruby.so`, the binary itself doesn't include any
calls to `malloc(3)` at all. So in spite of our explicit `-ljemalloc`
flag, it is ignored. Libc's one is chosen instead.
This is not what we want. Let's force our `ruby(1)` link what we want.
Fixes https://github.com/ruby/ruby/pull/4627
The author would like to acknowledge
Akihiko Odaki <akihiko.odaki@gmail.com> for their contributions.
On darwin we avoid including sys/user.h to avoid a conflict. Previously
we still ended up with PAGE_SIZE being defined because the headers for
system malloc define it. However, when compiling with jemalloc nothing
would define PAGE_SIZE.
This commit changes configure.ac so that we never use the PAGE_SIZE
constant on darwin and to always use the sysconf fallback.
The current fix for PAGE_SIZE macro detection in autoconf does not work
correctly. I see the following output with running configure on Linux:
```
checking PAGE_SIZE is defined... no
```
Linux has PAGE_SIZE macro. This is happening because the macro exists in
sys/user.h and not in the malloc headers.
include/ruby/internal/has/builtin.h uses HAVE_BUILTIN___BUILTIN_EXPECT
for icc but previously it was not defined.
This is a follow up of 8b32de2ec9 and this
will fix the following failures:
http://rubyci.s3.amazonaws.com/icc-x64/ruby-master/log/20210505T030003Z.fail.html.gz
```
1) Failure:
TestMkmf::TestConvertible#test_typeof_builtin [/home/chkbuild/chkbuild/tmp/build/20210505T030003Z/ruby/test/mkmf/test_convertible.rb:9]:
convertible_int: checking for convertible type of short... -------------------- short
--------------------
convertible_int: checking for convertible type of int... -------------------- int
--------------------
convertible_int: checking for convertible type of long... -------------------- long
--------------------
convertible_int: checking for convertible type of signed short... -------------------- failed
"icc -std=gnu99 -o conftest -I. -I/home/chkbuild/chkbuild/tmp/build/20210505T030003Z/ruby/.ext/include/x86_64-linux -I/home/chkbuild/chkbuild/tmp/build/20210505T030003Z/ruby/include -I./test -O3 -ggdb -Wall -Wextra -Wdeprecated-declarations -Wimplicit-function-declaration -Wimplicit-int -Wpointer-arith -Wshorten-64-to-32 -Wwrite-strings -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-unused-parameter -Wunused-variable -diag-disable=175,188,1684,2259,2312 -Wextra-tokens -Wundef conftest.c -L. -L/home/chkbuild/chkbuild/tmp/build/20210505T030003Z/ruby -Wl,-rpath,/home/chkbuild/chkbuild/tmp/build/20210505T030003Z/ruby -L. -fstack-protector-strong -rdynamic -Wl,-export-dynamic -Wl,-rpath,/home/chkbuild/chkbuild/tmp/build/20210505T030003Z/lib -L/home/chkbuild/chkbuild/tmp/build/20210505T030003Z/lib -lruby-static -lz -lpthread -lrt -lrt -ldl -lcrypt -lm -lm -lc"
In file included from /home/chkbuild/chkbuild/tmp/build/20210505T030003Z/ruby/include/ruby/defines.h(72),
from /home/chkbuild/chkbuild/tmp/build/20210505T030003Z/ruby/include/ruby/ruby.h(23),
from /home/chkbuild/chkbuild/tmp/build/20210505T030003Z/ruby/include/ruby.h(39),
from conftest.c(1):
/home/chkbuild/chkbuild/tmp/build/20210505T030003Z/ruby/include/ruby/backward/2/assume.h(34): warning #193: zero used for undefined preprocessing identifier "HAVE_BUILTIN___BUILTIN_EXPECT"
#if RBIMPL_HAS_BUILTIN(__builtin_expect)
...
```
KJ Tsanaktsidis
Jeremiah Gowdy
Jeremiah Gowdy
Takashi Kokubun
Nobuyoshi Nakada
nick evans
Sergey Fedorov
Jun Aruga
Aaron Patterson
Alan Wu
S-H-GAMELINKS
Alan Wu
Yuta Saito
Peter Zhu
Naohisa Goto
Yusuke Endoh
David CARLIER
Jeremy Evans
Lars Kanis
xtkoba (Tee KOBAYASHI)
卜部昌平
Samuel Williams
John Hawthorn
Benoit Daloze
Kazuhiro NISHIYAMA
Rick Mark