Skip to content

query: Extract tracepoint & k(ret)probe from perf_event links #1213

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

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Jongy
Copy link
Contributor

@Jongy Jongy commented Aug 12, 2025

heavily inspired by matching bpftool code

/// A tracepoint event.
Tracepoint {
/// The tracepoint name.
name: Option<CString>,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the other link type that has strings to return is RawTracepointLinkInfo and it returns String but I think it's saner to return a CString/OsString` and let the user decode if needed

@Jongy Jongy force-pushed the add-link-perf-event branch from 1e610b0 to a451904 Compare August 12, 2025 08:00
@Jongy Jongy force-pushed the add-link-perf-event branch from a451904 to 2c37073 Compare August 12, 2025 08:30
Copy link
Collaborator

@danielocfb danielocfb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this seems fine, thanks. Would it be possible to add a test for this functionality?

Comment on lines +762 to +763
/// TODO: Add support for `BPF_PERF_EVENT_EVENT`, `BPF_PERF_EVENT_UPROBE`
/// `BPF_PERF_EVENT_URETPROBE`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should be using doc comments for TODOs; please add proper documentation instead.

Suggested change
/// TODO: Add support for `BPF_PERF_EVENT_EVENT`, `BPF_PERF_EVENT_UPROBE`
/// `BPF_PERF_EVENT_URETPROBE`
// TODO: Add support for `BPF_PERF_EVENT_EVENT`, `BPF_PERF_EVENT_UPROBE`
// `BPF_PERF_EVENT_URETPROBE`


print!(" {probe_type}");
if *addr != 0 {
print!(" addr={addr:x}");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be

Suggested change
print!(" addr={addr:x}");
print!(" addr={addr:#x}");

?

Comment on lines +922 to +923
// Handle two-phase call for perf event string data if needed (this mimics the
// behavior of bpftool).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Comment (and naming of need_second_call) seems a bit bogus: there is no first call in scope. It could conceptually have been called from anywhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(the first call is from the gen_info_impl macro, but I'll rename to something clearer :) )

.cookie
};
let name = (tp_name != 0).then(|| unsafe {
CStr::from_ptr(tp_name as *const c_char).to_owned()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't the typical contract that the kernel would set the actual name length? Or is this not the case here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It actually has the length - but I followed bpftool here, which just prints the string. If I have to guess - the returned length is the full one and the provided name is the null-terminated string (truncated), but i'll make sure and comment.

@Jongy
Copy link
Contributor Author

Jongy commented Aug 12, 2025

Would it be possible to add a test for this functionality?

I'll try. There are no tests for link infos from query.rs as far as I can see, but I can add some tests that load BPF objects from the existing ones that we have, and then query them and expect the matching types/parameters etc.

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

Successfully merging this pull request may close these issues.

2 participants