| Age | Commit message (Collapse) | Author |
|---|
| 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' ``` Notes: Merged: https://.com/ruby/ruby/pull/13509 |
| Notes: Merged-By: k0kubun <[email protected]> |
| |
| Co-authored-by: Alan Wu <[email protected]> Notes: Merged-By: k0kubun <[email protected]> |
| 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 s 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. Notes: Merged: https://.com/ruby/ruby/pull/13262 |
| Notes: Merged: https://.com/ruby/ruby/pull/13304 |
| 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. Notes: Merged: https://.com/ruby/ruby/pull/13229 |
| Notes: Merged: https://.com/ruby/ruby/pull/13131 |
| Notes: Merged: https://.com/ruby/ruby/pull/13131 |
| Notes: Merged: https://.com/ruby/ruby/pull/13131 |
| Notes: Merged: https://.com/ruby/ruby/pull/13131 |
| Notes: Merged: https://.com/ruby/ruby/pull/13131 |
| Notes: Merged: https://.com/ruby/ruby/pull/13131 |
| When the path of `CC` contains the target program name, e.g., clang, the replaced program names were unexpected. Replace basename part only. Notes: Merged: https://.com/ruby/ruby/pull/12762 |
| Notes: Merged: https://.com/ruby/ruby/pull/12740 |
| Notes: Merged: https://.com/ruby/ruby/pull/12534 |
| Notes: Merged: https://.com/ruby/ruby/pull/12532 |
| |
| 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". Notes: Merged: https://.com/ruby/ruby/pull/12261 |
| Notes: Merged: https://.com/ruby/ruby/pull/12165 |
| 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. Notes: Merged: https://.com/ruby/ruby/pull/12043 |
| "libexec" means the directory for executable or binary files already. Notes: Merged: https://.com/ruby/ruby/pull/12043 |
| Notes: Merged: https://.com/ruby/ruby/pull/12034 |
| 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 ``` Notes: Merged: https://.com/ruby/ruby/pull/11928 |
| 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`. Notes: Merged: https://.com/ruby/ruby/pull/11866 |
| Notes: Merged: https://.com/ruby/ruby/pull/11852 |
| So that the closing bracket does not look like commented out. |
| Notes: Merged: https://.com/ruby/ruby/pull/11797 |
| Join with a space in `MakeMakefile#libpathflag` instead. Notes: Merged: https://.com/ruby/ruby/pull/11724 |
| There is nothing endianness-related in ppc64le and all the tests pass on both ucontext and ppc64le coroutines on powerpc64-freebsd14.0 Notes: Merged: https://.com/ruby/ruby/pull/10595 |
| Only one ractor-related test fails, but it also fails with ucontext. Notes: Merged: https://.com/ruby/ruby/pull/10595 |
| 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. Notes: Merged: https://.com/ruby/ruby/pull/11548 |
| This reverts commit 6a746e1bc902d4245aac58db4e9ffc2f72d79629. This breaks the C level backtrace on macOS ARM machines. Notes: Merged: https://.com/ruby/ruby/pull/11548 |
| Linux calls it aarch64, but MacOS calls it arm64; pac-ret works on both. Notes: Merged: https://.com/ruby/ruby/pull/11405 |
| Notes: Merged: https://.com/ruby/ruby/pull/11419 |
| - only i386-ucrt soname is changed to fix building on x86 clang - fix detection of x86intrin.h on x86 system - mingw does not have LIBRUBY_SONAME Notes: Merged: https://.com/ruby/ruby/pull/11362 |
| ... of commit 00176cd40fe9f385231e9c20b956fc4a84d240b9. The reverted change was made only for constistency, as discussed in https://.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 576b2e64cdc5ea42ad345dd3c1c215e006c06fca. Related to GH-11358 Notes: Merged: https://.com/ruby/ruby/pull/11364 Merged-By: XrXr |
| Notes: Merged: https://.com/ruby/ruby/pull/11358 |
| * YJIT: Allow dev_nodebug to disasm release-mode code * Revert "YJIT: Squash canary before falling back" This reverts commit f05ad373d84909da7541bd6d6ace38b48eaf24a1. The stray canary issue should have been solved by def7023ee4a3fc6eeba9d3a34c31a5bcff315fac, alleviating this codegen accommodation. * s/runtime_assertions/runtime_checks/ --------- Co-authored-by: Alan Wu <[email protected]> Notes: Merged-By: k0kubun <[email protected]> |
| It already has been dead code. Follow up of 65d3eacc80bbefb29e5cd0f3f9661d886f2e4cee. |
| [Misc #20636] |
| This partially reverts https://.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. |
| **What does this PR do?** This PR tweaks the `vm_push_frame` function to add an explicit compiler fence (`atomic_signal_fence`) to ensure profilers that use signals to interrupt applications (stackprof, vernier, pf2, Datadog profiler) can safely sample from the signal handler. **Motivation:** The `vm_push_frame` was specifically tweaked in https://.com/ruby/ruby/pull/3296 to initialize the a frame before updating the `cfp` pointer. But since there's nothing stopping the compiler from reordering the initialization of a frame (`*cfp =`) with the update of the cfp pointer (`ec->cfp = cfp`) we've been hesitant to rely on this on the Datadog profiler. In practice, after some experimentation + talking to folks, this reordering does not seem to happen. But since modern compilers have a way for us to exactly tell them not to do the reordering (`atomic_signal_fence`), this seems even better. I've actually extracted `vm_push_frame` into the "Compiler Explorer" website, which you can use to see the assembly output of this function across many compilers and architectures: https://godbolt.org/z/3oxd1446K On that link you can observe two things across many compilers: 1. The compilers are not reordering the writes 2. The barrier does not change the generated assembly output (== has no cost in practice) **Additional Notes:** The checks added in `configure.ac` define two new macros: * `HAVE_STDATOMIC_H` * `HAVE_DECL_ATOMIC_SIGNAL_FENCE` Since Ruby generates an arch-specific `config.h` header with these macros upon installation, this can be used by profilers and other libraries to test if Ruby was compiled with the fence enabled. **How to test the change?** As I mentioned above, you can check https://godbolt.org/z/3oxd1446K to confirm the compiled output of `vm_push_frame` does not change in most compilers (at least all that I've checked on that site). |
| |
| `ac_abs_builddir` can be empty when the build is top-level (not subdirs, and Ruby is usually the case). In such case, the MINIRUBY is expanded to `$RUBY -I -r'$(arch)-fake'`, which interprets `-r$(arch)-fake` as an argument to `-I` option. This led to: - Not loading the fake config file - Then not setting `CROSS_COMPILING` constant during extmk.rb execution - Then misusing cross-compiled `./miniruby` instead of baseruby to generate files used in exts. This commit fixes the issue by handling the empty `ac_abs_builddir` case properly. |
| Also executing variable containing an option may not be portable. Follow up of dd378c5a2483002d50053cf81d00004c1fb3c8bd. |
| |
| LCOV 2.0, a GCOV frontend, seems to have stricter error checking |
