linux-usdt / libstapsdt Goto Github PK

Systemtap's USDT probes accept parameters, and this library should accept parameters too.

I'm struggling to understand how libstapsdt supports is-enabled.

It would appear that it relies on something, somewhere, overwriting the data at the address of the probe, but It's not clear to me where this is.

The only hint that i see is the magic number 0x90, which appears to be what systemtap depends on as a TRAP instruction. Is something further down in the kernel or in libbcc handling this?

It is clear to me that libbcc supports USDT probes that rely on a semaphore for their implementation of is-enabled, and that codepath makes sense.

Yet, when I run the python example of libstapsdt it appears to somehow correctly indicate to the userspace program when a probe is enabled - so perhaps there is no need or benefit to the semaphore at the moment.

One obvious benefit I can think of is that semaphores by their nature should allow for handling multiple observers attaching to a trace point, and correctly disabling it when the last one de-registers.

My assumption is that adding semaphore support would require allocating an unsigned short within the stubbed library, and putting the address of this value within the elf notes. I would need to verify exactly how this is done in conventional systemtap SDT macros, but it doesn't seem too difficult in theory.

@mmarchini when you have a moment, I would very much appreciate if you could shed a light on how is-enabled currently works, and weigh-in on any possible value of adding support for semaphores.

I asked about this in the iovisor irc, so i'll copy my questions and investigation from there to here:

i've been reading through mmarchini's work on libstapsdt, and I'm struggling to understand how it implements checking if a probe is enabled 
https://github.com/sthima/libstapsdt/blob/99911c5a44ea40fd14d99c52c5dacf4328aa463c/src/libstapsdt.c#L185-L193
in http://www.brendangregg.com/blog/2015-07-03/hacking-linux-usdt-ftrace.html, i understand how the code in bcc basically implements this same approach to increment the
semaphore, and so it makes sense that this is a way to signal to the process that it's enabled
when i read the ELF notes for the dynamic stub library produced by libstapsdt though, it clearly doesn't use a semaphore
checking the code in bcc, it's clear that this bypasses the semaphore code altogether
yet, it works somehow to check if a probe is enabled. It appears to be checking the address where the probe is defined
https://github.com/sthima/libstapsdt/blob/99911c5a44ea40fd14d99c52c5dacf4328aa463c/src/libstapsdt.c#L111-L119
is there a place somewhere that the probe address is modified when attached to, and disabled when detached? 
https://github.com/iovisor/bcc/blob/ba41501bb2ca89312061b31c08e570a11c092370/src/cc/usdt/usdt.cc#L121-L135 this would appear to nothing for these types of probes

There is a copy/paste issue on the documentation, file how-to-use.rst

The loop on the example (first code block) tries to fire a probe from an unknown array (probeFire(probes[idx], i++, j--);)

It says

  while(i) {
    printf("Firing probe...\n");
    if(probeIsEnabled(probe)) {
      probeFire(probes[idx], i++, j--);
      printf("Probe fired!\n");
      i = 0;
    }
    sleep(1);
  }

It should rather say

while(i) {
  printf("Firing probe...\n");
  if(probeIsEnabled(probe)) {
    probeFire(probe, "I'm a runner!");
    printf("Probe fired!\n");
    i = 0;
  }
  sleep(1);
}

Hope this helps

If the hash from dynamic symbols collides, the linker can't handle the collision because our implementation is wrong.

The correct implementation is described here:
http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#hash

LLD (from LLVM) has a very clean and concise implementation of the right algorithm:
https://github.com/llvm-mirror/lld/blob/c9f8e5737d94cc60c8cbdac79716f04fdeaff43f/ELF/SyntheticSections.cpp#L1650

Hello,

I have written some bindings for LuaJIT to libstapsdt available here: https://git.sr.ht/~sm2n/luajit-stapsdt

Hopefully someone may find them useful.

Thanks.

Write integration tests that use the library and use readelf/objdump/etc. to ensure that the generated file is correct.

Provide a is enabled API similar to the one from chrisa/libusdt. This will allow users to take actions whenever a tracepoint is enabled at the probe's address and will provide an interface more similar to the one provided by libusdt.

Loading one shared library per probe can easily become overkill on projects with multiple probes. To avoid that, we should allow registering multiple probes before creating/loading the shared library on memory. One shared library could hold all probes related to a provider.

A typical workflow for this would be:

1. Create new provider
2. Register probe
3. Repeat 2 until all probes are registered
4. Enable provider

After enabled, the provider shouldn't be editable, as it would generate another shared library.

Sometimes probes may be used only during a short period of time, for a specific context. In that case, there's no reason to keep the entire provider/shared library alive after its lifetime ended, so there must be a way to unload it.

Unloading a provider should unload the shared library (dlclose()), delete its file and free all related structures.

Related: mmarchini/libstapsdt#2

The hash table is defined statically, and because of that it's not possible to change the symbol's name referring to the probe code. This blocks #2