News for hackers. Stuff that matters.
Re:Tracers – Rust Instrumentation Library by brian_herman__ on Tuesday November 19, 2019 @08:28PM (#21580298)
Shouldn’t it use eBPF on Linux instead of system tap?
Re:Tracers – Rust Instrumentation Library by anelson on Wednesday November 20, 2019 @01:38AM (#21581604)
This crate is for enabling low-overhead tracing of userland Rust code. To that end it supports both systemtap and ltt-ng.

Systemtap probes are available to eBPF instrumentation, so in that sense this does indirectly use eBPF. I know this isn't obvious, I haven't had a chance to get the docs up to my standard.

In fact I went to great lengths to ensure that the eBPF tracing tools can discover the trace points generated by this implementation. This even required submitting an upstream bug to the BCC toolchain. But now it works great for primitive types that have some meaningful equivalent in eBPF terms.

Re:Tracers – Rust Instrumentation Library by fnord123 on Wednesday November 20, 2019 @05:03AM (#21582517)
>Systemtap probes are available to eBPF instrumentation, so in that sense this does indirectly use eBPF. I know this isn't obvious, I haven't had a chance to get the docs up to my standard.

Sounds like a great use case to document.

Re:Tracers – Rust Instrumentation Library by anelson on Wednesday November 20, 2019 @07:11AM (#21583172)
Yes absolutely. Better docs are a top priority right now.
Re:Tracers – Rust Instrumentation Library by tjfontaine on Wednesday November 20, 2019 @01:35AM (#21581591)
You can use eBPF tooling to attach to User SDT probes; this library is a way to instrument your code once and have those probes available via the appropriate tracing infrastructure on the running platform
Re:Tracers – Rust Instrumentation Library by anelson on Wednesday November 20, 2019 @01:41AM (#21581615)
Yes exactly. The goal of this project is to let authors put trace points in their code and at compile time target whatever tracing system makes sense. On Linux that's either systemtap or ltt-ng. On Windows it (will be; not implemented yet) the event tracing API, on MacOS and FreeBSD it would be dtrace. There's also an option to completely disable tracing at compile time, which removes all tracing code and imposes absolutely zero runtime overhead.
Re:Tracers – Rust Instrumentation Library by jen20 on Wednesday November 20, 2019 @12:02PM (#21585712)
Worth noting that DTrace is now available on Windows too as of "recently" [1][2]. It would be great to support that also!

[1]: https://www.microsoft.com/en-us/download/details.aspx?id=580...

[2]: https://github.com/microsoft/DTrace-on-Windows

Re:Tracers – Rust Instrumentation Library by anelson on Thursday November 21, 2019 @12:40AM (#21591720)
Cool! Assuming it's a faithful port with source-level compatibility, it should work with the existing DTrace implementation I'm building. The differences between compiler toolchains are already abstracted away by the excellent `cc` crate.

In any case I already have a Windows CI build; when DTrace is ready I'll add DTrace on Windows there and see what happens.

Re:Tracers – Rust Instrumentation Library by jen20 on Thursday November 21, 2019 @02:02AM (#21591999)
Great news, I'm very much looking forward to being able to use this crate! Thanks for your work (and that of those upstream of you).