[PATCH 0 of 3] Add support for dtrace compatible sdt probes on GNU/Linux

[David Holmes]

On 22/05/2012 9:45 PM, Mark Wielaard wrote:
> On Tue, 2012-05-22 at 21:25 +1000, David Holmes wrote:
>> On 22/05/2012 9:11 PM, Mark Wielaard wrote:
>>> But really the SDT markers themselves
>>> are independent from any program that consumes them (on Solaris you
>>> would use dtrace, on GNU/Linux you can also use GDB or just list them
>>> with readelf -n).
>>
>> I need to understand this aspect a bit better.
>
> SDT markers are defined by simple macros. e.g:
> DTRACE_PROBE5(provider,probe,parm1,parm2,parm3,parm4,parm5)
> Which is a marker for a named provider with a probe name and 5
> arguments. Of course in the hotspot source code there are macros around
> these macros, and some convenience functions. All the patches really do
> is make sure that if a sys/sdt.h file is found on a GNU/Linux system it
> is included and the macros are used. These macros expand to a little bit
> of code that just puts those names and where the arguments can be found
> in a little ELF notes section.

Many thanks for the explanation Mark.

Do you know what the effect of this is on the static size of libjvm.so?

I think we would need a way to disable this even if sys/sdt.h is present 
- just as dtrace support can be disabled.

David
-----

> So with the patch applied and compiled on a system that has sys/sdt.h
> you will get a libjvm.so that contains:
>
> $ eu-readelf -n libjvm.so
>
> Note section [29] '.note.stapsdt' of 53916 bytes at offset 0x99fac8:
>    Owner          Data size  Type
>    stapsdt               77  Version: 3
>      PC: 0x35612f, Base: 0x7f2378, Semaphore: 0
>      Provider: hotspot, Name: class__loaded, Args: '8@%r13 -4@%r14d 8@%rax 1@%r12b'
>    stapsdt               76  Version: 3
>      PC: 0x3561e5, Base: 0x7f2378, Semaphore: 0
>      Provider: hotspot, Name: class__unloaded, Args: '8@%rbx -4@%r12d 8@%rax 1@$0'
>
> [etc.]
>
> That ELF notes section can then be used by programs like stap or gdb to
> put breakpoints/probes on those locations and retrieve the arguments
> found.
>
> A more technical explanation with some more details I left out can be
> found at:
> http://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
> Another high level overview from one of the GDB maintainers is here:
> http://tromey.com/blog/?p=687
>
> It works similar for SDT probes on Solaris and dtrace, though they use
> different conventions for storing the addresses/names/arguments. The
> main difference is that on solaris a different ELF section is used and
> the arguments are assumed to follow function calling conventions, while
> on gnu/linux they can just be "anywhere".
>
> Hope that helps,
>
> Mark