Search /usr/lib/debug/.build-id for debug files by bobrik · Pull Request #1415 · libbpf/blazesym

bobrik · 2026-01-08T06:45:20Z

This takes a stab at #1401. It works on Debian with libc6-dbg installed:

$ cargo build --package blazecli && ./target/debug/blazecli symbolize elf --path /lib/x86_64-linux-gnu/libc.so.6 0x29c30
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.09s
0x00000000029c30: __libc_start_call_main @ 0x29c30+0x0 ./csu/../sysdeps/nptl/libc_start_call_main.h:29:1

It does not work without the change:

ivan@cube:~/projects/blazesym$ cargo build --package blazecli && ./target/debug/blazecli symbolize elf --path /lib/x86_64-linux-gnu/libc.so.6 0x29c30
   Compiling blazesym v0.2.1 (/mnt/data/homes/ivan/projects/blazesym)
   Compiling blazecli v0.1.12 (/mnt/data/homes/ivan/projects/blazesym/cli)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.88s
2026-01-08T06:44:20.381871Z  WARN debug link references destination `f5460e3cee00bfee25b429c97bcc4853e5b3a8.debug` which was not found in any known location
0x00000000029c30: <no-symbol>

Let me know if it's the right approach before I go about adding a test.

codecov · 2026-01-08T06:53:34Z

Codecov Report

❌ Patch coverage is 97.87234% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 95.78%. Comparing base (808157f) to head (7c45a75).
⚠️ Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
src/dwarf/debug_link.rs	97.67%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1415   +/-   ##
=======================================
  Coverage   95.78%   95.78%           
=======================================
  Files          61       61           
  Lines       11075    11115   +40     
=======================================
+ Hits        10608    10647   +39     
- Misses        467      468    +1

☔ 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 · 2026-01-08T17:44:47Z

Thanks for working on this feature. I will take a look tomorrow.

d-e-s-o

It's a good addition, but I think the way it's written will make testing close to impossible. Please take a look at my comments/suggestions and let me know what you think.

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

src/dwarf/debug_link.rs

+                    return self.next()
+                };
+
+                let Ok(Some(build_id)) = read_elf_build_id(linker) else {


I really don't like that we are just papering over errors here -- it is unclear from the context whether that is or is not acceptable and so the decision shouldn't be forced here. The iterator is also meant to be independent of system state, so it shouldn't be doing any file system operations.

My suggestion would be to move build ID reading into find_debug_file and then pass an optional build ID to DebugFileIter::new, that will also basically be a requirement for testing purposes. It's a bit unfortunate that it means eager build ID reading, but given that we check it first anyway that seems fine and we can revisit that part later.

I really don't like that we are just papering over errors here -- it unclear from the context whether that is or is not acceptable and so the decision shouldn't be forced here.

How do you think I should deal with errors? Just log them with warn!() or do something else?

My suggestion would be to move build ID reading into find_debug_file and then pass an optional build ID to DebugFileIter::new, that will also basically be a requirement for testing purposes.

I moved it there.

that will also basically be a requirement for testing purposes

How do you see testing this? I'm thinking of using DrarfResolver::from_parser() and passing an argument to override the build id directory, but let me know if you have something else in mind.

I amended DebugFileIter tests. Let me know if that's sufficient (it feels like it is to me).

src/dwarf/debug_link.rs

d-e-s-o · 2026-01-09T19:16:40Z

src/dwarf/debug_link.rs

+                let first = build_id
+                    .iter()
+                    .take(1)
+                    .map(|byte| format!("{byte:02x}"))
+                    .collect::<String>();
+                let rest = build_id
+                    .iter()
+                    .skip(1)
+                    .map(|byte| format!("{byte:02x}"))
+                    .collect::<String>();


Nitpicky, but please dont iterate twice. Just create an iterator, take a first element and format it as a byte as you do, then consume the rest as you also do.

That will also make it more obvious that the logic is actually not handling the case of an empty build ID in a way I'd intend (while that is b/s input, it also is effectively user controlled input, so we should probably deal with it properly instead of potentially opening files in directories we don't intend to). I think it's legitimate to just skip the BuildId state if the build ID is not of the expected format, i.e., missing the first byte (I think it's fine to not assert length of the remainder, but a check that it is not empty may also be in order; for the most part I am concerned about staying in the intended directory, though).

It would also be great if you were to add a test for such a case.

I moved it to one iterator + length check with a comment.

I added a test for the length as well.

Signed-off-by: Ivan Babrou <[email protected]>

d-e-s-o

Looks good to me, thanks!

d-e-s-o · 2026-01-20T17:53:40Z

src/dwarf/debug_link.rs

+use crate::BuildId;
 use crate::Result;

-


Please avoid spurious changes like this in the future. Thanks!

Add a CHANGELOG entry for pull request libbpf#1415, which added support for the /usr/lib/debug/.build-id directory for debug link targets. Also extend the DebugFileIter tests marginally, to cover one more case. Signed-off-by: Daniel Müller <[email protected]>

Add a CHANGELOG entry for pull request libbpf#1415, which added support for the /usr/lib/debug/.build-id directory for debug link targets. Also adjust the DebugFileIter logic marginally. Signed-off-by: Daniel Müller <[email protected]>

Add a CHANGELOG entry for pull request #1415, which added support for the /usr/lib/debug/.build-id directory for debug link targets. Also adjust the DebugFileIter logic marginally. Signed-off-by: Daniel Müller <[email protected]>

bobrik force-pushed the ivan/build-id branch from 0240cd4 to 2209568 Compare January 8, 2026 06:45

bobrik force-pushed the ivan/build-id branch from 2209568 to ab42b96 Compare January 8, 2026 06:58

d-e-s-o self-requested a review January 9, 2026 18:19

d-e-s-o reviewed Jan 9, 2026

View reviewed changes

bobrik force-pushed the ivan/build-id branch 4 times, most recently from 70bbc6c to 4afb1c6 Compare January 17, 2026 06:20

Search /usr/lib/debug/.build-id for debug files

7c45a75

Signed-off-by: Ivan Babrou <[email protected]>

bobrik force-pushed the ivan/build-id branch from 4afb1c6 to 7c45a75 Compare January 17, 2026 06:24

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

View reviewed changes

d-e-s-o merged commit 8db66bc into libbpf:main Jan 20, 2026
45 checks passed

d-e-s-o mentioned this pull request Jan 20, 2026

Add CHANGELOG entry for #1415 #1436

Merged

This was referenced Feb 28, 2026

Update blazesym to >= 0.2.3 for build-id based debug file lookup DataDog/ddprof#502

Closed

chore(deps): bump blazesym to 0.2.3 for build-id debug file lookup DataDog/libdatadog#1637

Closed

Conversation

bobrik commented Jan 8, 2026

Uh oh!

codecov bot commented Jan 8, 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 commented Jan 8, 2026

Uh oh!

d-e-s-o left a comment

Choose a reason for hiding this comment

Uh oh!

d-e-s-o Jan 9, 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!

bobrik Jan 17, 2026

Choose a reason for hiding this comment

Uh oh!

bobrik Jan 17, 2026

Choose a reason for hiding this comment

Uh oh!

bobrik Jan 17, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

d-e-s-o Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

bobrik Jan 17, 2026

Choose a reason for hiding this comment

Uh oh!

bobrik Jan 17, 2026

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!

d-e-s-o Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

codecov bot commented Jan 8, 2026 •

edited

Loading

d-e-s-o Jan 9, 2026 •

edited

Loading