Add a basic Go library that wraps blazesym-c #1402

bobrik · 2025-12-30T03:53:27Z

As discussed in facebook/dns#116, this adds a Go library in the same repo as blazesym itself.

I only added two methods for the symbolizer: one for pid based resolution and one for ELF based one. There's also a cli tool that I used to compare against blazecli. The output seems to match. The README explains how to build this.

I think it's reasonable to start with this small API surface area and then expand to more of it later.

If this makes sense, I can add tests and general CI scaffolding. Let me know if there's anything else you'd like to see before this is good to merge.

codecov · 2025-12-30T03:59:39Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.73%. Comparing base (035b712) to head (af54fa6).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1402      +/-   ##
==========================================
- Coverage   95.85%   95.73%   -0.12%     
==========================================
  Files          61       61              
  Lines       11076    11076              
==========================================
- Hits        10617    10604      -13     
- Misses        459      472      +13

☔ 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! Overall this looks mostly good to me. Left a first set of comments. Let me know what you think. Will probably give it another pass early next year.

I believe the current setup of requiring manual installation + flags setting etc. is probably fairly cumbersome for users, but we can revisit this down the line.

The one thing I think we will need is tests for the bindings and then hook that up to CI. This doesn't have to be super comprehensive, but at last something like

blazesym/tests/suite/symbolize.rs

Lines 935 to 937 in cf1a03e

    
           /// Check that we can symbolize addresses inside our own process. 
        
           #[test] 
        
           fn symbolize_process() {

blazesym/tests/suite/symbolize.rs

Lines 449 to 453 in cf1a03e

    
           /// Check that we "fail" symbolization as expected on a stripped ELF 
        
           /// binary. 
        
           #[tag(other_os)] 
        
           #[test] 
        
           fn symbolize_elf_stripped() {

A simplified ELF + DWARF variation of:

blazesym/tests/suite/symbolize.rs

Lines 96 to 99 in cf1a03e

    
           /// Check that we can symbolize an address using ELF, DWARF, and GSYM. 
        
           #[tag(other_os)] 
        
           #[test] 
        
           fn symbolize_elf_dwarf_gsym() {

I think it's fine to rely on the Rust created test binaries. You can create them using cargo check --package blazesym-dev --features=generate-unit-test-files.

Let me know if you need help with any of that.

blazesym-go/symbolizer.go

d-e-s-o · 2025-12-30T17:48:16Z

go/symbolizer.go

+}
+
+func (s *Symbolizer) processSyms(syms *C.blaze_syms, stack []uint64) ([]Sym, error) {
+	lastErr := BlazeErr(C.blaze_err_last())


This pattern of checking last error here seems dangerous, as there is no guarantee that syms hasn't been stored anywhere and other blazesym calls have happened in between. I'd rather we move this check to the call site.

This is an internal helper that is not a part of accessible API.

I understand that, but that only makes it marginally better, in my opinion. Anyway, it's not super critical.

It feels wrong to me to add duplicate error handling in each processSyms caller.

go/symbolizer.go

d-e-s-o · 2025-12-30T17:52:45Z

go/cmd/cli/main.go

@@ -0,0 +1,145 @@
+package main


I'd really not want to have a CLI like this floating around, as it will cause confusion with the Rust one. Can we make this an example of sorts instead? I.e., move it into the newly created examples/ or so and then adjust the README accordingly.

Personally I'd also rather split it into two examples, one for process symbolization and one for ELF stuff and then provide suitable example inputs that "just work", but it's not a must.

I moved it to an example. This is how it looks like locally with go doc -C go -http:

go/README.md

bobrik · 2025-12-31T06:32:23Z

I believe the current setup of requiring manual installation + flags setting etc. is probably fairly cumbersome for users, but we can revisit this down the line.

It's what libbpfgo does and I use it in my own ebpf_exporter to provide both static and dynamic builds. It is fully transparent if the library is installed in the regular system paths.

The trouble with all the env variables comes when the C library is not installed globally, so you have to tell the C compiler and the linker where the things are. I'm not aware of a way to make Go toolchain compile a C library for you and use that transparently.

The one thing I think we will need is tests for the bindings and then hook that up to CI. This doesn't have to be super comprehensive, but at last something like

I added the tests you mentioned and hooked them up to CI and it only took 7 attempts to get it right!

d-e-s-o

Looks great to me now, thanks! One last comment below.

Also, I am curious why did you opt to make blazeErr internal only? I guess it's fine to just work with error, but it would seem good to have the additional info that the error code provides available in general.

go/README.md

d-e-s-o · 2026-01-02T18:01:44Z

I just noticed that CI also prints this warning:

Restore cache failed: Dependencies file is not found in /home/runner/work/blazesym/blazesym. Supported file pattern: go.sum

Is this something we can address easily by any chance or is that just inherent given how we do things?

Signed-off-by: Ivan Babrou <github@ivan.computer>

bobrik · 2026-01-02T22:06:51Z

Also, I am curious why did you opt to make blazeErr internal only? I guess it's fine to just work with error, but it would seem good to have the additional info that the error code provides available in general.

I'm not using the error for anything other than to bail and I think it would be best to make it public when there's a clear user need for it. That way if I mess things up it won't be a breaking change.

I just noticed that CI also prints this warning:

Restore cache failed: Dependencies file is not found in /home/runner/work/blazesym/blazesym. Supported file pattern: go.sum

Is this something we can address easily by any chance or is that just inherent given how we do things?

I tried fixing it by adding the following:

cache-dependency-path: go/go.sum

But then it hit me that we don't have go.sum because we don't have dependencies.

bobrik · 2026-01-02T22:54:51Z

Let me know if I missed anything. I tested it manually with a patched Grafana Alloy and it looks right:

d-e-s-o · 2026-01-03T13:59:26Z

Seems all fine to me now, thanks again!

bobrik mentioned this pull request Dec 30, 2025

Account for inlined frames from blazesym facebook/dns#116

Closed

5 tasks

d-e-s-o reviewed Dec 30, 2025

View reviewed changes

bobrik force-pushed the ivan/go branch 8 times, most recently from f76c3c3 to 615ac6d Compare December 31, 2025 06:23

d-e-s-o approved these changes Jan 2, 2026

View reviewed changes

go/README.md Outdated Show resolved Hide resolved

bobrik force-pushed the ivan/go branch 2 times, most recently from e447e16 to 84779da Compare January 2, 2026 21:59

Add a basic Go library that wraps blazesym-c

af54fa6

Signed-off-by: Ivan Babrou <github@ivan.computer>

bobrik force-pushed the ivan/go branch from 84779da to af54fa6 Compare January 2, 2026 22:03

d-e-s-o merged commit 7b3ccd3 into libbpf:main Jan 3, 2026
45 checks passed

bobrik deleted the ivan/go branch January 6, 2026 19:23

	/// Check that we can symbolize addresses inside our own process.
	#[test]
	fn symbolize_process() {

	/// Check that we "fail" symbolization as expected on a stripped ELF
	/// binary.
	#[tag(other_os)]
	#[test]
	fn symbolize_elf_stripped() {

	/// Check that we can symbolize an address using ELF, DWARF, and GSYM.
	#[tag(other_os)]
	#[test]
	fn symbolize_elf_dwarf_gsym() {

Add a basic Go library that wraps blazesym-c #1402

Add a basic Go library that wraps blazesym-c #1402

Uh oh!

Conversation

bobrik commented Dec 30, 2025

Uh oh!

codecov bot commented Dec 30, 2025 • 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

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

d-e-s-o Dec 30, 2025

Choose a reason for hiding this comment

Uh oh!

bobrik Dec 30, 2025

Choose a reason for hiding this comment

Uh oh!

d-e-s-o Jan 2, 2026

Choose a reason for hiding this comment

Uh oh!

bobrik Jan 2, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

d-e-s-o Dec 30, 2025

Choose a reason for hiding this comment

Uh oh!

bobrik Dec 31, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bobrik commented Dec 31, 2025

Uh oh!

d-e-s-o left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

d-e-s-o commented Jan 2, 2026

Uh oh!

bobrik commented Jan 2, 2026

Uh oh!

bobrik commented Jan 2, 2026

Uh oh!

d-e-s-o commented Jan 3, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

codecov bot commented Dec 30, 2025 •

edited

Loading