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

Support for C-style string arguments #10

Open
jonhoo opened this issue Mar 5, 2019 · 7 comments
Open

Support for C-style string arguments #10

jonhoo opened this issue Mar 5, 2019 · 7 comments

Comments

@jonhoo
Copy link

jonhoo commented Mar 5, 2019

While all probe arguments do have to be i64, it seems like addresses to null-terminated strings are supported both by the kernel and by bpftrace. We may want to make users' lives a little easier by also accepting CStr arguments and turning them into their own address.

@cuviper
Copy link
Owner

cuviper commented Mar 6, 2019

I could see this as some kind of ProbeArg trait which casts as necessary -- CStr would just need to call as_ptr(). It might even be possible to add an associated const for the sign+size, so we don't have to force everything to i64. See also:
https://github.com/cuviper/rust-libprobe/blob/431ac2999eb88e3a8ba5ee15df13557e234d9775/src/platform/systemtap.rs#L33-L54

@Zheaoli
Copy link

Zheaoli commented Jan 22, 2024

So, should we pass the str or String in Rust to the probe right now?

@Zheaoli
Copy link

Zheaoli commented Jan 22, 2024

Seems the following code is ok

        let c_str= CString::new(path).unwrap();

        probe::probe_lazy!(opendal, write_start, c_str.as_ptr());

@cuviper
Copy link
Owner

cuviper commented Jan 22, 2024

Yeah, right now it will work with any argument that can cast as isize -- so CString and CStr won't work directly, but their as_ptr() should be fine. You could do that with str and String too, or any other slice, but you'll probably want to pass another argument for the length in that case.

@bobrik
Copy link

bobrik commented Jun 7, 2024

A native support via something like ProbeArg would indeed be nice. Currently with probe_lazy the CString created lazily are dropped and scrambled before they can be read:

probe_lazy!(proxy, h1, {
    let uri = CString::new("/lol.txt").unwrap();
    uri.as_ptr()
});
$ sudo bpftrace -e 'usdt:target/debug/examples/load_balancer:proxy:h1 { printf("uri = %s\n", str(arg0)); }'
Attaching 1 probe...
uri = �d�s�

This happens with both probe! and probe_lazy! and can be avoided by creating the CString before a call to the probe, but that defies the purpose of lazy evaluation:

let uri = CString::new("/lol.txt").unwrap();
probe_lazy!(proxy, h1, { uri.as_ptr() });
$ sudo bpftrace -e 'usdt:target/debug/examples/load_balancer:proxy:h1 { printf("uri = %s\n", str(arg0)); }'
Attaching 1 probe...
uri = /lol.txt

@cuviper
Copy link
Owner

cuviper commented Jun 7, 2024

I think you can do this and still be lazy:

let uri;
probe_lazy!(proxy, h1, {
    uri = CString::new("/lol.txt").unwrap();
    uri.as_ptr()
});

It doesn't even need mut because there's only one (conditional) initialization.

@bobrik
Copy link

bobrik commented Jun 7, 2024

Indeed that does the trick, thanks!

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