From: Eric Wong <normalperson@...>
Date: 2018-06-06T08:40:07+00:00
Subject: [ruby-core:87424] systemtap usage (was gc.c: make gc_enter+gc_exit	pairs dtrace probes)

> https://bugs.ruby-lang.org/issues/14813

Fwiw, I'm still learning systemtap myself; and I made r63581
the dtrace tests to work with systemtap.

I played around with systemtap ~5 years ago for other projects
and forgot much of it :x

For Debian/Ubuntu users:

	# as root:
	apt-get install systemtap systemtap-sdt-dev
	stap-prep # should install necessary kernel headers + debug symbol(*)
	adduser $YOUR_USER stapusr
	adduser $YOUR_USER stapdev

Red Hat-based systems should be similar; and most of the
systemtap team works for Red Hat.  There's also dyninst support
which won't require special privileges (or kernel context
switch), but current Debian stable doesn't enable it, yet.

	# (re-)login as regular user:

	# rebuild Ruby with --enable-dtrace
	# (make sure probes.h has SDT stuff and isn't a dummy file)

	# trace a new command
	$ stap -v script.stp -c "$RUBY_CMD"

	# trace running command
	$ stap -v script.stp -x $PID_OF_RUBY

My original example with:

	probe process("/path/to/ruby").mark("foo")

was a bit strict since it requires the path of executable.
Now I favor "-x $PID" or "-c $CMD" so I can use:

	probe process.mark("foo")

There is also "systemtap-doc" package
I look at docs + *.stp examples in their git tree:

	git://sourceware.org/git/systemtap.git


(*) I never tested `stap-prep' myself since I build my own kernels
    from source.  For people like me who run the latest kernels;
    be prepared to backport patches from systemtap.git or
    build+install from that yourself.  Users of distro-provided
    kernels get things working out-of-the-box in my experience.

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>