4 ms·

Shouldn’t it use eBPF on Linux instead of system tap?

tjfontaine 7y ago
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
- anelson 7y ago
  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.
  - jen20 7y ago
    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=58091 https://www.microsoft.com/en-us/download/details.aspx?id=580... [2]: https://github.com/microsoft/DTrace-on-Windows https://github.com/microsoft/DTrace-on-Windows
    - anelson 7y ago
      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.
      - jen20 7y ago
        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).
anelson 7y ago
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.
- fnord123 7y ago
  >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.
  - anelson 7y ago
    Yes absolutely. Better docs are a top priority right now.

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

anelson 7y ago
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.
- jen20 7y ago
  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=58091 https://www.microsoft.com/en-us/download/details.aspx?id=580... [2]: https://github.com/microsoft/DTrace-on-Windows https://github.com/microsoft/DTrace-on-Windows
  - anelson 7y ago
    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.
    - jen20 7y ago
      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).

anelson 7y ago

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.

fnord123 7y ago
>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.
- anelson 7y ago
  Yes absolutely. Better docs are a top priority right now.