This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Tapsets with wildcards in the process() statement ?


I'm working on a SystemTap based DTrace impl for QEMU:

 http://lists.gnu.org/archive/html/qemu-devel/2010-10/msg01184.html

I have QEMU's build system generating a master dtrace provider 
that looks like

 $ cat trace-dtrace.d
  provider qemu {

        probe qemu_malloc(size_t size, void *ptr);

        probe qemu_realloc(void *ptr, size_t size, void *newptr);

        probe qemu_free(void *ptr);

        probe virtqueue_fill(void *vq, const void *elem, unsigned int len, unsigned int idx);

        probe virtqueue_flush(void *vq, unsigned int count);

        probe virtqueue_pop(void *vq, void *elem, unsigned int in_num, unsigned int out_num);

       ....more...
  }

and using systemtap's dtrace tool I can  successfully build this
into QEMU and use the probes. To make it easier to use though, I
also want to generate a simple tapset eg

$ cat /usr/share/systemtap/tapset/qemu.stp

  probe qemu.qemu_malloc = process("qemu").mark("qemu_malloc")
  {
    size = $arg1;
    ptr = $arg2;
  }

  probe qemu.qemu_realloc = process("qemu").mark("qemu_realloc")
  {
    ptr = $arg1;
    size = $arg2;
    newptr = $arg3;
  }

  probe qemu.qemu_free = process("qemu").mark("qemu_free")
  {
    ptr = $arg1;
  }
  ...

The problem I'm facing is that QEMU generates a separate binary for each
architecture it emulates, eg

  qemu (i386 emulator)
  qemu-system-x86_64
  qemu-system-ppc
  qemu-system-ppc64
  ...
  qemu-kvm (a KVM enabled version of qemu-system-x86_64)

All of these binaries will contain the same probe points, give or take
a handful which may be architecture specific.

The 'process("qemu")' statement in my qemu.stp file will only match
one of the binaries though. I would like todo 'process("qemu*")'
but systemtap doesn't seem to like that wildcard syntax here:

semantic error: no match while resolving probe point process("qemu*").mark("qemu_malloc")
semantic error: no match while resolving probe point qemu.qemu_malloc
Pass 2: analysis failed.  Try again with another '--vp 01' option.

Is there a better way to approach this problem, which lets the tapset
easily work with any of the QEMU architecture binaries that are present ?

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]