From: "Eregon (Benoit Daloze) via ruby-core" <ruby-core@...>
Date: 2026-10-28T22:05:32+00:00
Subject: [ruby-core:127271] [Ruby Feature#21539] Export symbols for external profiling of stripped shared Ruby builds

Issue #21539 has been updated by Eregon (Benoit Daloze).


@dalehamel Could you update the dev-meeting summary at https://bugs.ruby-lang.org/issues/22417#note-2 to reflect the latest patch?

I think opening a PR to ruby/ruby would also be helpful to help review.

----------------------------------------
Feature #21539: Export symbols for external profiling of stripped shared Ruby builds
https://bugs.ruby-lang.org/issues/21539#change-119692

* Author: dalehamel (Dale Hamel)
* Status: Open
----------------------------------------
## Motivation

External profilers such as [OpenTelemetry's eBPF profiler](https://github.com/open-telemetry/opentelemetry-ebpf-profiler) collect Ruby stacks from outside the Ruby process.

Distribution packages commonly ship shared libruby but strip the full symbol table (`.symtab`) and debug information. Some of the symbols needed to discover Ruby's execution state are currently local symbols, so they
disappear when stripped. Public dynamic symbols in `.dynsym` survive normal stripping.

I'd like to narrow this proposal to making the necessary discovery symbols available in these stripped shared builds.

## Proposed exports

Please export these three existing symbols from shared libruby:

| Symbol | Purpose |
| --- | --- |
| `ruby_current_ec` | Locate the sampled native thread's execution context through TLS, providing access to its Ruby stack. |
| `rb_vm_exec` | Identify the function's address range, where native stack unwinding should hand off to Ruby stack unwinding. The profiler does not call this function. |
| `ruby_global_symbols` | Resolve Ruby method IDs to names for methods implemented in C. Stack walking can work without this, but those method names become `<unknown cfunc>`. |

The profiler also needs `ruby_version`, which is already exported and requires no change.

The requested outcome is that these symbols are available through `.dynsym` in installed shared builds, without requiring distributions to retain the full symbol table or users to install debug information just to locate     them.

## Scope

This is a symbol-visibility request, not a request for a general out-of-process profiling API:

- No requirement to stabilize internal struct layouts or make these internals a supported C-extension API.
- No additional profiling stack, per-frame bookkeeping, or in-process profiling machinery.
- The profiler remains responsible for supporting version-specific layouts and interpreter/JIT behavior.

This would address the symbol-discovery obstacle for stripped distribution builds without taking on the broader API design discussed in #19119.

Related profiler discussion: https://github.com/open-telemetry/opentelemetry-ebpf-profiler/issues/202


---Files--------------------------------
protected.patch (1.55 KB)
exported.patch (1.21 KB)
debug-aliases.patch (1.88 KB)
debug-export.patch (1.83 KB)


-- 
https://bugs.ruby-lang.org/
______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/