dtrace probes

[graydon]

I think rust should expose dtrace userland probes

Links:
http://www.solarisinternals.com/wiki/index.php/DTrace_Topics_USDT
https://wikis.oracle.com/display/DTrace/Statically+Defined+Tracing+for+User+Applications
https://wiki.freebsd.org/DTrace/userland

Some specific providers (including some dynamic):
https://github.com/chrisa/libusdt
https://github.com/chrisa/node-dtrace-provider
http://prefetch.net/projects/apache_modtrace/index.html
https://bugzilla.mozilla.org/show_bug.cgi?id=370906

Probably at least some for pervasive / standard-library actions:

• per-task CPU time, coroutine switches, lifecycle events
• heap allocations, GC, segmented stack growth
• message passing, IO ops / byte volumes
• conditions raised

Note that the "USDT" mechanism provides static probes whereas things like libusdt (above) provide an API for dynamically registering probes at runtime. This is probably important, possibly even a good place to start, though it's slightly more expensive; ideally of course we should be able to provide both.

See also #6810 concerning metrics. I think there's some potential design-informing between the two. Possibly libusdt as a reporting sink for metrics?

[metajack]

Visiting for triage. I think at this point, probes like this should be standard in new languages. They are becoming an important tool for application performance testing and diagnostic work.

Nominating feature complete.

[No9]

Making rust build on illumos / solaris would make dtrace integration a lot easier to develop

[catamorphism]

Accepted for milestone 4, well-covered

[pnkfelix]

P-low, not 1.0.

[cuviper]

Hi - I'm a SystemTap developer, and I've created a prototype of our flavor of SDT for Rust on Linux:

Rust SDT probe!() macro

This would be very similar in concept to dtrace USDT, but AIUI the implementations are quite different. Conceivably, dtrace platforms could implement the same macro with different guts though, which is why I decided to share mine here.

The macro inserts just a single NOP in the code, then ELF notes describe the probe and its arguments. SystemTap knows how to parse these, of course, and I gave a tiny example in the gist. GDB 7.5 gained support for SDT too, with info probes to list them and break -probe name to place a breakpoint. You can also see the probe metadata using readelf -n.

I'm very new to rust, but the asm! and concat! macros made this fairly straightforward. Solving types more completely might take some expert help though - I made notes in the file about that.

Thanks, and any feedback is welcome!

[alexcrichton]

Wow, that's awesome! Very nice work @cuviper!

[cuviper]

Thanks @alexcrichton! Do you think this could go in the standard library? If so, where should I put it, right in libstd/macros.rs? (With target_os guards and an empty implementation for non-linux, of course.)

[alexcrichton]

If you want to upstream it for now, these macros should probably reside in a separate library libprobe, perhaps?

I think that unfortunately any crate using the probe! macro will also be forced to opt-in to the asm feature, which is in theory just an implementation detail of the macro itself. Hopefully we can get that fixed soon, though!

[cuviper]

Does it make sense to be a separate library even if core parts will be using it? That's the only reason I thought it should be in libstd. I'm also not sure how a macro-only library would function. Ideally, you'd want it to be present just for compilation, but there's nothing that needs to be linked at runtime. (But perhaps other platforms might need runtime stuff.)

For the asm feature, yes I would hope the library hosting probe! could mask that detail, but I understand if that's yet to be handled.

[alexcrichton]

As a macro-only library, it could likely get built before libstd (so libstd could depend on it if necessary), as it wouldn't have any runtime dependencies. We currently support macro-only libraries through:

#[phase(syntax)] // don't link to this crate, just get some macros
extern crate probe;

fn main() {
    probe!(...)
}

[cuviper]

Great, thanks, I'll play with it and send a PR.

[steveklabnik]

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#875