You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 :)
The text was updated successfully, but these errors were encountered:
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.
(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 :)
The text was updated successfully, but these errors were encountered: