-
Notifications
You must be signed in to change notification settings - Fork 25
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
Misc tracing improvements #906
Commits on Nov 14, 2024
-
Adjust Debug representation of ElfResolver
The Debug representation of ElfResolver looks awkward and not in line with how objects are generally represented. Fix it up to make traces somewhat more appealing to the eye. Signed-off-by: Daniel Müller <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 79810f4 - Browse repository at this point
Copy the full SHA 79810f4View commit details -
Make Resolver enum transparent in traces
From the point of view of a user, the Resolver enum has no meaning: it's pretty much just an implementation detail of how we manage memory. As such, all the current representation in traces does is add clutter. Simplify it by only printing the inner value (i.e., the resolver). Signed-off-by: Daniel Müller <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for c73ee2a - Browse repository at this point
Copy the full SHA c73ee2aView commit details -
Add BPF programs to "format" matrix in Symbolizer documentation
We document supported "formats" not just in the README but also in the Symbolizer type's documentation. Mirror what commit a9d9811 ("Add BPF programs to "format" matrix in README") did to the README there as well, to keep both matrices in sync. Signed-off-by: Daniel Müller <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 5db0315 - Browse repository at this point
Copy the full SHA 5db0315View commit details -
Remove ElfResolver::find_sym trace
The ElfResolver::find_sym trace point doesn't really buy us anything: other resolvers don't have it and we effectively already have the functionality captured by the trace in Symbolizer::symbolize_with_resolver. As such, let's just remove it. Signed-off-by: Daniel Müller <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 9636c03 - Browse repository at this point
Copy the full SHA 9636c03View commit details -
Trace errors on relevant entry points
The occurrence of errors is generally something that we should include in our traces, but doing so requires special annotation. Add it to relevant entry points to the crate. The created spans/events will be emitted at log level ERROR by default, which is what we want. Signed-off-by: Daniel Müller <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 0084f88 - Browse repository at this point
Copy the full SHA 0084f88View commit details -
Emit trace span for handle_entry_addr
It can be useful for introspection matters to get a quick understanding of what /proc/<pid>/maps entry an address gets mapped to as part of process symbolization. Attach a span to the handle_entry_addr() method to emit this information. Signed-off-by: Daniel Müller <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 20a0aae - Browse repository at this point
Copy the full SHA 20a0aaeView commit details -
Capture reason for "unknown" symbolization in traces
Make sure that we capture the reason why a symbolization maps to "unknown" in traces, as that can be relevant information when trying to understand what the library is reporting. Signed-off-by: Daniel Müller <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 6b39bf2 - Browse repository at this point
Copy the full SHA 6b39bf2View commit details