| Age | Commit message (Collapse) | Author |
|---|
|
46e4c8673747de96838d2c5dec37446d23d99d88:
Fix redefinition of `clock_gettime` and `clock_getres`
winpthreads-git 12.0.0.r720 provides `clock_gettime` and
`clock_getres` as inline functions.
Detect `clock_gettime` and `clock_getres` for winpthreads
|
|
|
|
safe profiling (#11090)
**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.
This is a backport of #11036 to Ruby 3.3 .
**Motivation:**
The `vm_push_frame` was specifically tweaked in
https://github.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).
|
|
[Bug #20499] Use Xcode owned tools for Xcode clang
Xcode has its own version tools that may be incompatible with genuine
LLVM tools, use the tools in the same directory.
|
|
[Bug #20500] Search non-default directories for jemalloc
Co-Authored-by: lish82 (Hiroki Katagiri)
|
|
[Bug #20494] Search non-default directories for GMP
Co-Authored-by: lish82 (Hiroki Katagiri)
|
|
`-mbranch-protection` (#9385)
[Bug #20085] Use consistent default options for `-mbranch-protection`
We need to use the same options for both C compiler and assembler
when `-mbranch-protection` is guessed by configure. Otherwise,
`coroutine/arm64/Context.{h,S}` will use incompatible PAC strategies.
|
|
* Allows macOS users to use M:N threads (and technically FreeBSD, though it has not been verified on FreeBSD)
* Include sys/event.h header check for macros, and include sys/event.h when present
* Rename epoll_fd to more generic kq_fd (Kernel event Queue) for use by both epoll and kqueue
* MAP_STACK is not available on macOS so conditionall apply it to mmap flags
* Set fd to close on exec
* Log debug messages specific to kqueue and epoll on creation
* close_invalidate raises an error for the kqueue fd on child process fork. It's unclear rn if that's a bug, or if it's kqueue specific behavior
Use kq with rb_thread_wait_for_single_fd
* Only platforms with `USE_POLL` (linux) had changes applied to take advantage of kernel event queues. It needed to be applied to the `select` so that kqueue could be properly applied
* Clean up kqueue specific code and make sure only flags that were actually set are removed (or an error is raised)
* Also handle kevent specific errnos, since most don't apply from epoll to kqueue
* Use the more platform standard close-on-exec approach of `fcntl` and `FD_CLOEXEC`. The io-event gem uses `ioctl`, but fcntl seems to be the recommended choice. It is also what Go, Bun, and Libuv use
* We're making changes in this file anyways - may as well fix a couple spelling mistakes while here
Make sure FD_CLOEXEC carries over in dup
* Otherwise the kqueue descriptor should have FD_CLOEXEC, but doesn't and fails in assert_close_on_exec
|
|
Previously, the embedded semicolon in BASERUBY if BASERUBY is
not available breaks tarball builds without BASERUBY when using
OpenBSD make, due to the inability to escape MFLAGS correctly.
This moves the same BASERUBY code into a separate file, avoiding
the MFLAGS quoting issue.
BASERUBY must be passed to build-ext because it is required
by ripper since the introduction of lrama.
Fixes [Bug #19683]
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
|
|
|
|
|
|
|
|
|
|
|
|
* [win32] fix compilation for windows-arm64
Credits to MSYS2 Ruby package using this patch.
* [win32] nm use full options
Fix compilation error when using MSYS2 environment.
Credits to MSYS2 Ruby package using this patch.
* [win32] detect llvm-windres (used for windows-arm64)
When adding preprocessor option for llvm-windres (using clang as
parameter), it fails. Thus, do not add this.
It's needed to be able to compile windows-arm64 version, because MSYS2
toolchain is LLVM based (instead of GCC/binutils).
* [win32] pioinfo detection for windows-arm64
This fixes "unexpected ucrtbase.dll" for native windows-arm64 ruby
binary. It does not solve issue with x64 version emulated on this
platform.
Value of pioinfo pointer can be found in ucrtbase.dll at latest adrp/add
sequence before return of _isatty function. This works for both release
and debug ucrt.
Due to the nature of aarch64 ISA (vs x86 or x64), it's needed to
disassemble instructions to retrieve offset value, which is a bit more
complicated than matching specific string patterns.
Details about adrp/add usage can be found in this blog post:
https://devblogs.microsoft.com/oldnewthing/20220809-00/?p=106955
For instruction decoding, the Arm documentation was used as a reference.
|
|
This reverts commit 9694445051c4192c8f659529133acab253bd0bc3.
This change broke our release CI.
https://github.com/ruby/actions/actions/runs/6599016994/job/17927644579#step:16:44
Invoking `/Users/runner/work/actions/actions/snapshot-master/ruby -rrubygems /Users/runner/work/actions/actions/snapshot-master/bin/gem --backtrace build lib/bundler/bundler.gemspec` failed with output:
----------------------------------------------------------------------
dyld[42417]: Library not loaded: '/usr/local/lib/libruby.3.3.dylib'
Referenced from: '/Users/runner/work/actions/actions/snapshot-master/ruby'
Reason: tried: '/usr/local/lib/libruby.3.3.dylib' (no such file), '/usr/lib/libruby.3.3.dylib' (no such file)
----------------------------------------------------------------------
|
|
|
|
This reverts commit 1d5598fe0d3470e7cab06a756d40a9221fcd501b.
|
|
During the build, Ruby has special logic to serialize its own builtin
module to disk using the binary iseq format during the build (I assume
for speed so it doesn't have to parse builtin every time it starts
up).
However, since iseq format is architecture-specific, when building on
x86_64 for universal x86_64 + arm64, the serialized builtin module is
written with the x86_64 architecture of the build machine, which fails
this check whenever ruby imports the builtin module on arm64:
https://github.com/ruby/ruby/blob/1fdaa0666086529b3aae2d509a2e71c4247c3a12/compile.c#L13243
Thankfully, there's logic to disable this feature for cross-compiled builds:
https://github.com/ruby/ruby/blob/1fdaa0666086529b3aae2d509a2e71c4247c3a12/builtin.c#L6
This disables the iseq logic for universal builds as well.
Fixes [Bug #18286]
|
|
|
|
|
|
This reverts commit 1961c786aab243b3eb60e7238224e87975d88056. These
environment variables should no longer propagate to child processes.
|
|
|
|
I check the s390s-linux/Ubuntu system and I found that MN threads
doesn't work with:
* function inlining (-O0 doesn't repro)
* Thread local specifier (`_Thread_local`.
With `pthread_get_specific works)
(it is not an issue of `__tls_get_addr()` written in thread.c)
* swap context with ucontext (coroutine/ucontext)
I couldn't find out what is the root cause of this issue but
disable MN threads to make CI healthy.
|
|
On some platforms, such as FreeBSD and Oracle Linux, symbols defined
in the crt0 setup routine are exported from shared libraries. So
ignore the symbols that would be exported even in an empty shared
library.
|
|
|
|
This patch introduce M:N thread scheduler for Ractor system.
In general, M:N thread scheduler employs N native threads (OS threads)
to manage M user-level threads (Ruby threads in this case).
On the Ruby interpreter, 1 native thread is provided for 1 Ractor
and all Ruby threads are managed by the native thread.
From Ruby 1.9, the interpreter uses 1:1 thread scheduler which means
1 Ruby thread has 1 native thread. M:N scheduler change this strategy.
Because of compatibility issue (and stableness issue of the implementation)
main Ractor doesn't use M:N scheduler on default. On the other words,
threads on the main Ractor will be managed with 1:1 thread scheduler.
There are additional settings by environment variables:
`RUBY_MN_THREADS=1` enables M:N thread scheduler on the main ractor.
Note that non-main ractors use the M:N scheduler without this
configuration. With this configuration, single ractor applications
run threads on M:1 thread scheduler (green threads, user-level threads).
`RUBY_MAX_CPU=n` specifies maximum number of native threads for
M:N scheduler (default: 8).
This patch will be reverted soon if non-easy issues are found.
[Bug #19842]
|
|
|
|
Similar to releasing free GC pages, releasing free malloc pages
reduce the amount of page faults post fork.
|
|
These options have been separated from `$CFLAGS` already in the
other places.
|
|
That option may be triggered wrongly by pre-processed files.
Notes:
Merged: https://github.com/ruby/ruby/pull/8382
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/8301
|
|
Fixes [Bug #17646]
Patch from xtkoba (Tee KOBAYASHI)
Notes:
Merged: https://github.com/ruby/ruby/pull/8288
|
|
`$(LIBRUBYARG_SHARED)` is included in `$(LIBS)` in extension
libraries.
Notes:
Merged: https://github.com/ruby/ruby/pull/8235
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/8224
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/8223
|
|
|
|
Revert "Disable YJIT if objcopy command is old"
This reverts commit 75f8781c08da421d6bcfb2c3c8b7b74efea3bec2.
|
|
Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>
Notes:
Merged: https://github.com/ruby/ruby/pull/8034
Merged-By: nobu <nobu@ruby-lang.org>
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/8007
|
|
|
|
Workaround for https://github.com/ruby/setup-ruby/pull/501#issuecomment-1520722486
|
|
To get rid of mysterious errors such as:
```
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: error: libruby.3.3-static.a(/): The end of the file was unexpectedly encountered
```
and
```
ld: warning: ignoring file ../../libruby.3.3-static.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64
Undefined symbols for architecture x86_64:
"_rb_rational_num", referenced from:
```
Notes:
Merged: https://github.com/ruby/ruby/pull/7678
Merged-By: nobu <nobu@ruby-lang.org>
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7677
|
|
Checking by `__STDC_VERSION__` is unreliable because old gcc 4.8
supports `-std=gnu11` option but does not implement `_Thread_local`.
Check the implementation directly instead.
Notes:
Merged: https://github.com/ruby/ruby/pull/7669
|
|
This is useful for passing directory file descriptors over UNIX
sockets or to child processes to avoid TOCTOU vulnerabilities.
The implementation follows the Dir.chdir code.
This will raise NotImplementedError on platforms not supporting
both fchdir and dirfd.
Implements [Feature #19347]
Notes:
Merged: https://github.com/ruby/ruby/pull/7135
|
|
This macro is used in `ruby_init_loadpath()`, but was removed
mistakenly at 31f4b2d86bfbc753cec9be376719acc4b120e944.
|
|
Notes:
Merged-By: k0kubun <takashikkbn@gmail.com>
|
|
RUBY_DEBUG is too slow.
|
|
[Misc #16671]
I'd like to bump it to 2.7 to use pattern matching in
tool/mk_builtin_loader.rb.
However, I experienced a few blockers. 2.5 seems like the closest
version that is easy enough to use on CIs, so let me bump the version to
it as an intermediate step for it. I want to use &. and <<~ in 2.3 too.
Known blockers:
* AppVeyor Visual Studio 2015 doesn't have Ruby 2.7. You'd need to bump
the version to Visual Studio 2019.
* GitHub Actions windows-2019 doesn't have Ruby 2.7 either. You
can use ruby/setup-ruby, but configure doesn't seem to work with it.
* For ruby/ruby-ci-imaage, bionic doesn't have Ruby 2.7. I tried using
ruby-build to build Ruby 2.7 from package, but the build on its CI
seems to somehow loop forever when I do that. So I gave it up for now.
We might want to wait until bionic becomes EOL.
Note:
* AppVeyor Visual Studio 2015 has Ruby <= 2.6.3
https://www.appveyor.com/docs/windows-images-software/#ruby
* GitHub Actions windows-2019 uses Ruby 2.5.9
https://github.com/actions/runner-images/blob/main/images/win/Windows2019-Readme.md
Notes:
Merged-By: k0kubun <takashikkbn@gmail.com>
|
