Previously this was listed as a suppression, but we actually want this
permanently unsanitized. This should be faster and more reliable since
TASN won't have to match against symbolicated backtraces.
This is so that e.g. building with `--enable-zjit=dev` will test with the
disassembly feature. It makes more sense, saves on build time and
reveals that
`backend::arm64::tests::sp_movements_are_single_instruction` was in
fact failing with the `disasm` feature.
```
configure.ac:2803: warning: AC_CHECK_FUNCS(\
): you should use literals
../autoconf-2.72/lib/autoconf/functions.m4:117: AC_CHECK_FUNCS is expanded from...
../autoconf-2.72/lib/m4sugar/m4sh.m4:697: AS_IF is expanded from...
```
May not be supported on some 32bit architectures.
```
/usr/lib/gcc-cross/m68k-linux-gnu/14/../../../../m68k-linux-gnu/bin/ld: ../../libruby-static.a(vm.o): in function `rbimpl_atomic_u64_set_relaxed':
/home/ubuntu/build/ruby/master/m68k-linux/../src/ruby_atomic.h:60:(.text+0x2468): undefined reference to `__atomic_store_8'
/usr/lib/gcc-cross/m68k-linux-gnu/14/../../../../m68k-linux-gnu/bin/ld: ../../libruby-static.a(vm.o): in function `rbimpl_atomic_u64_load_relaxed':
/home/ubuntu/build/ruby/master/m68k-linux/../src/ruby_atomic.h:43:(.text+0x2950):
undefined reference to `__atomic_load_8'
```
This commit allows building YJIT and ZJIT simultaneously, a "combo
build". Previously, `./configure --enable-yjit --enable-zjit` failed. At
runtime, though, only one of the two can be enabled at a time.
Add a root Cargo workspace that contains both the yjit and zjit crate.
The common Rust build integration mechanisms are factored out into
defs/jit.mk.
Combo YJIT+ZJIT dev builds are supported; if either JIT uses
`--enable-*=dev`, both of them are built in dev mode.
The combo build requires Cargo, but building one JIT at a time with only
rustc in release build remains supported.
Working towards having YJIT and ZJIT in the same build, we need to
deduplicate some glue code that would otherwise cause name collision.
Add jit.c for this and build it for YJIT and ZJIT builds. Update bindgen
to look at jit.c; some shuffling of functions in the output, but the set
of functions shouldn't have changed.
We have name fragmentation for this feature, including "shared GC",
"modular GC", and "external GC". This commit standardizes the feature
name to "modular GC" and the implementation to "GC library".
The "target" in `RbConfig::CONFIG` is being changed from config.sub to
align to the system `uname`. Use the value modified by config.sub, and
make the directory same as GNU utilities, such as binutils.
With `-pipe` option, gcc of Homebrew on macOS results in a mysterious
error.
```
$ command -v gcc-14
/opt/homebrew/bin/gcc-14
$ gcc-14 --version
gcc-14 (Homebrew GCC 14.2.0) 14.2.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc-14 -c -pipe conftest.c
clang: error: no input files
```
Instead of passing the full GC SO file name to RUBY_GC_LIBRARY, we now
only need to pass the GC name.
For example, before we needed to pass `RUBY_GC_LIBRARY=librubygc.default.so`
but now we only need to pass `RUBY_GC_LIBRARY=default`.
Libunwind as packaged in MacOS cannot actually unwind code which has
pointer authentication on, because _LIBUNWIND_IS_NATIVE_ONLY is not
defined. Add a check for this, and prefer building with working
unwinding over pointer authentication if we must make a choice.
... of commit 00176cd40f.
The reverted change was made only for constistency, as discussed in
https://github.com/ruby/ruby/pull/11358#issuecomment-2282222369
But the platform string "mingw-ucrt" should not be changed.
It is used as RUBY_PLATFORM and as the rubygems platform, so that there should
be a good reason to change the name of an established platform.
"mingw-ucrt" was introduced intentionally in commit
576b2e64cd.
Related to GH-11358
* YJIT: Allow dev_nodebug to disasm release-mode code
* Revert "YJIT: Squash canary before falling back"
This reverts commit f05ad373d8.
The stray canary issue should have been solved by
def7023ee4, alleviating this codegen
accommodation.
* s/runtime_assertions/runtime_checks/
---------
Co-authored-by: Alan Wu <XrXr@users.noreply.github.com>
This partially reverts https://github.com/ruby/ruby/pull/10944; now that
we decided to pass CFLAGS to $(CC) when assembling .S files, we don't
need these autoconf macros that capture the state of
__ARM_FEATURE{PAC|BTI}_DEFAULT.
[Bug #20601]
We already assemble our assembly files using the $(CC) compiler driver,
rather than the actual $(AS) assembler. This means that
* The C preprocessor gets run on the assembly file
* It's valid to pass gcc-style flags to it, like e.g.
-mbranch-protection or -fcf-protection
* If you do so, the relevant preprocessor macros like __CET__ get set
* If you really wanted to pass assembler flags, you would need to do
that using -Wa,... anyway
So I think it makes sense to pass "$(XCFLAGS) $(CFLAGS) $(CPPFLAGS)" to
gcc/clang/etc when assembling, rather than passing $(ASFLAGS) (since
the flags are not actually passed to `as`, but `cc`!).
The side effect of this is that if there are mitigation flags like
-fcf-protection in $CFLAGS, then the relevant macros like __CET__ will
be defined when assembling the files.
[Bug #20601]
This commit changes the external GC API to use `--with-shared-gc=DIR` at
configure time with a directory of the external GC and uses
`RUBY_GC_LIBRARY` environment variable to load the external GC at
runtime.
