capi: Add callback for symbolizer by sensille · Pull Request #1535 · libbpf/blazesym

sensille · 2026-04-14T06:36:17Z

Expose parts of set_process_dispatcher in the capi to enable users to provide alternative ELF file paths for symbolization (e.g., fetched via debuginfod).

As discussed in #1443.

Please let me know if this goes in the direction you had in mind.

codecov · 2026-04-14T22:33:05Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.65%. Comparing base (c8db293) to head (8d0de88).
⚠️ Report is 7 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1535      +/-   ##
==========================================
+ Coverage   95.52%   95.65%   +0.13%     
==========================================
  Files          56       56              
  Lines        9534     9562      +28     
==========================================
+ Hits         9107     9147      +40     
+ Misses        427      415      -12

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

d-e-s-o

Thanks for the pull request! Left a few comments. Can you check what you think?

d-e-s-o · 2026-04-15T17:45:33Z

    /// the underlying language does not mangle symbols (such as C).
    pub demangle: bool,
+    /// Explicit pad to avoid implicit gaps.
+    pub _pad_a: [u8; 4],


Can we rename this to _reserved1 or so?

d-e-s-o · 2026-04-15T17:46:59Z

    /// languages are Rust and C++ and the flag will have no effect if
    /// the underlying language does not mangle symbols (such as C).
    pub demangle: bool,
+    /// Explicit pad to avoid implicit gaps.


Can you please make it clear that this should be initialized to zero like other unused fields?

d-e-s-o · 2026-04-15T17:52:39Z

    /// Unused member available for future expansion. Must be initialized
    /// to zero.
-    pub reserved: [u8; 20],
+    pub reserved: [u8; 24],


I think the size of the struct should stay constant. So we should decrease instead of increase. It's a bit annoying that this change alone brings us to the limit, basically. Perhaps we'd should just embed a single pointer to a struct containing the two pointers in question...? Given that it's a niche case and can be stack allocated, it's probably okay, would be my take.

d-e-s-o · 2026-04-15T17:59:48Z


+    let builder = if let Some(cb) = process_dispatch_cb {
+        // Cast the context pointer to usize so the closure is Send.
+        // The caller is responsible for thread safety of the context.


Okay, but that should be mentioned in the corresponding part of the documentation then, I'd say.

I eliminated the cast, as it doesn't really gain anything in the current thread model, if I understand it correctly.

d-e-s-o · 2026-04-15T18:09:01Z

+                    //         NUL-terminated, `malloc`'d C string.
+                    let path_cstr = unsafe { CStr::from_ptr(result) };
+                    let path = Path::new(OsStr::from_bytes(path_cstr.to_bytes()));
+                    let resolver = ElfResolver::open(path);


This constructor doesn't honor any custom debug directories that may have been configured. I feel like this can be confusing to users relying on that.

I see. I also found that the caching behavior is different, it cannot de-duplicate between processes anymore if I read this correctly. so how do we solve this? I see

Just document the behavior.

Add another constructor to ElfResolver that also passes debug_dirs and leave caching as-is.

Somehow pass the path back to the symbolizer and let it construct the resolver the same way it would without the dispatch callback. This would handle both issues.

I find 3 to be the most appealing, but also the most intrusive. What do you think?

Yeah, I think the caching story is unfortunate but non-trivial to solve. Given that it's not really a correctness issue, I'd say we leave it as-is (a solution is on the roadmap for 0.3). For debug_dirs, I think an additional constructor for ElfResolver is fine.

Expose parts of set_process_dispatcher in the capi to enable users to provide alternative ELF file paths for symbolization (e.g., fetched via debuginfod). Signed-off-by: Arne Jansen <arne@die-jansens.de>

Signed-off-by: Arne Jansen <arne@die-jansens.de>

sensille · 2026-04-23T05:48:59Z

Thanks for the review. I hope I addressed everything. Pushed the changes as a fixup commit.

d-e-s-o

Overall this looks good to me now, thanks. Can you take a look at two more comments below?

d-e-s-o · 2026-04-24T16:32:42Z

+
+    /// Symbolize `addr` in the current process using the given dispatch
+    /// callback.
+    unsafe fn symbolize_with_dispatch(


I fail to see why this function needs to be unsafe?

d-e-s-o · 2026-04-24T16:35:12Z

+    /// Create an `ElfResolver` that loads data from the provided file,
+    /// using the given directories to search for split debug
+    /// information.
+    pub fn open_with_debug_dirs<P, D, DP>(path: P, debug_dirs: D) -> Result<Self>


I think this should be only available if the dwarf feature is enabled, same as https://docs.rs/blazesym/latest/blazesym/symbolize/struct.Builder.html#method.set_debug_dirs.

d-e-s-o

Two more comments, actually.

d-e-s-o · 2026-04-24T16:39:52Z

-        }
+        // SAFETY: The caller ensures that the pointer is valid and the count
+        //         matches.
+        let slice = unsafe { slice_from_user_array(debug_dirs, _debug_dirs_len) };


Please also rename _debug_dirs_len to debug_dirs_len given that it's now used.

d-e-s-o · 2026-04-24T16:42:48Z

+#[derive(Debug)]
+pub struct blaze_symbolizer_dispatch {
+    /// The dispatch callback function. Must not be `NULL`.
+    pub dispatch_cb: unsafe extern "C" fn(


I think this should still be wrapped in an Option to be NULL-able, no?

I'm not sure I get that. If the callback is not needed, process_dispatch is allowed to be NULL. Is that something about FFI semantics?

Yes, a fn cannot safely be NULL. It's like a reference; can't create it from a NULL ptr. At least that is my understanding.

See https://doc.rust-lang.org/nomicon/ffi.html#the-nullable-pointer-optimization

I get that if we want to allow the callback to be NULL, or even be able to check if it is NULL, we are required to add the Option. But as we don't allow a NULL cb here, is there still any advantage? As it doesn't have any downsides, I'll just add Option. Just curious.

Ah, I see now what you are saying. You are correct. You were referring to the "outer pointer" being NULL. Then we can keep things as-is on this front. Sorry for the confusion.

Signed-off-by: Arne Jansen <arne@die-jansens.de>

sensille · 2026-04-25T07:58:16Z

Pushed fixup 2

d-e-s-o self-requested a review April 15, 2026 17:45

d-e-s-o self-assigned this Apr 15, 2026

d-e-s-o reviewed Apr 15, 2026

View reviewed changes

d-e-s-o mentioned this pull request Apr 17, 2026

Path to 0.3... #1320

Open

6 tasks

sensille added 2 commits April 22, 2026 12:38

capi: Add callback for symbolizer

c6e2742

Expose parts of set_process_dispatcher in the capi to enable users to provide alternative ELF file paths for symbolization (e.g., fetched via debuginfod). Signed-off-by: Arne Jansen <arne@die-jansens.de>

review fixup

34d5997

Signed-off-by: Arne Jansen <arne@die-jansens.de>

sensille force-pushed the symbolizer branch from 501ba9d to 34d5997 Compare April 23, 2026 05:20

d-e-s-o approved these changes Apr 24, 2026

View reviewed changes

d-e-s-o reviewed Apr 24, 2026

View reviewed changes

d-e-s-o linked an issue Apr 24, 2026 that may be closed by this pull request

Expose set_process_dispatcher to capi #1443

Open

review fixup round 2

8d0de88

Signed-off-by: Arne Jansen <arne@die-jansens.de>

Conversation

sensille commented Apr 14, 2026

Uh oh!

codecov Bot commented Apr 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

d-e-s-o left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sensille Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

d-e-s-o Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sensille commented Apr 23, 2026

Uh oh!

d-e-s-o left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

d-e-s-o left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

d-e-s-o Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sensille commented Apr 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

codecov Bot commented Apr 14, 2026 •

edited

Loading

d-e-s-o left a comment •

edited

Loading

sensille Apr 17, 2026 •

edited

Loading

d-e-s-o Apr 17, 2026 •

edited

Loading

d-e-s-o Apr 24, 2026 •

edited

Loading