Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Poor error message when BPF is stripped #116

Open
nickalcock opened this issue Dec 11, 2024 · 3 comments
Open

Poor error message when BPF is stripped #116

nickalcock opened this issue Dec 11, 2024 · 3 comments

Comments

@nickalcock
Copy link
Member

(Reported by Leah Neukirchen.)

If the bpf in /usr/lib64/dtrace is stripped, it is wrecked (we need the symbol table to figure out what to load), but we don't diagnose this: instead, we just emit a 'could not enable tracing' message.

It should be easy enough to validate that the bpf library has at least one known symbol in it and fail with a better error if not :)

@kvanhees
Copy link
Member

I am confused... since the BPF library code is built when DTrace is built, how does it get stripped? And why would one want to strip it, since it is a .o file rather than an executable. So I would expect that one would want to keep the symbol table, etc.

This does not seem to be an issue with DTrace but rather with the way it is being built and installed. The makefiles as they are now would not cause this as far as I can see.

@thesamesam
Copy link

Package managers often strip all ELF objects being installed unless opted-out.

@ezannoni
Copy link
Member

Nick has implemented this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants