public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* Userspace probes on library functions ?
@ 2010-10-21 16:20 Daniel P. Berrange
  2010-10-21 17:34 ` Mark Wielaard
  2010-10-21 17:58 ` Steve Fink
  0 siblings, 2 replies; 6+ messages in thread
From: Daniel P. Berrange @ 2010-10-21 16:20 UTC (permalink / raw)
  To: systemtap

I'm trying to use userspace probes to trace public API calls into the
libvirt.so library. While I can trace functions in the virsh executable
without trouble, eg

  probe process("/usr/bin/virsh").function("vshInit") {
      printf("init %p", $ctl)
  }

I'm unable to trace functions that are defined in the libvirt.so

  probe process("/usr/bin/virsh").function("virConnectOpen") {
      printf("Open %p", $name)
  }

  semantic error: no match while resolving probe point process("/usr/bin/virsh").function("virConnectOpen")

I thought it might be symbol versioning that's confusing things,
so I've also tried

  probe process("/usr/bin/virsh").function("virConnectOpen@@LIBVIRT_0.0.3") {
      printf("Open %p", $name)
  }
  semantic error: no match while resolving probe point process("/usr/bin/virsh").function("virConnectOpen@@LIBVIRT_0.0.3")

Nor do I seem to be able to use function() matches in combination
with a library() statement

  probe process("/usr/bin/virsh").library("libvirt.so").function("virConnectOpen") {
      printf("Open %s", $name)
  }

  semantic error: probe point mismatch at position 2 (alternatives:
    mark(string) provider(string)): keyword at demo.stp:9:55 while
    resolving probe point process("/usr/bin/virsh").library("libvirt.so").function("virConnectOpen")
        source: probe process("/usr/bin/virsh").library("libvirt.so").function("virConnectOpen") {

I'm using  systemtap-1.3-2.fc13.x86_64, and have got the -debuginfo 
installed for the libvirt.so library & virsh tool. Am I simply trying
todo something that isn't supported ? If so, I'll just switch to adding
static probe markers to the public API entry/exit points instead..

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 :|

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Userspace probes on library functions ?
  2010-10-21 16:20 Userspace probes on library functions ? Daniel P. Berrange
@ 2010-10-21 17:34 ` Mark Wielaard
  2010-10-22  8:43   ` Daniel P. Berrange
  2010-10-21 17:58 ` Steve Fink
  1 sibling, 1 reply; 6+ messages in thread
From: Mark Wielaard @ 2010-10-21 17:34 UTC (permalink / raw)
  To: Daniel P. Berrange; +Cc: systemtap

On Thu, 2010-10-21 at 17:20 +0100, Daniel P. Berrange wrote:
> I'm trying to use userspace probes to trace public API calls into the
> libvirt.so library. While I can trace functions in the virsh executable
> without trouble, eg
> 
>   probe process("/usr/bin/virsh").function("vshInit") {
>       printf("init %p", $ctl)
>   }
> 
> I'm unable to trace functions that are defined in the libvirt.so
> 
>   probe process("/usr/bin/virsh").function("virConnectOpen") {
>       printf("Open %p", $name)
>   }
> 
>   semantic error: no match while resolving probe point process("/usr/bin/virsh").function("virConnectOpen")

You can use the slightly non-intuitive:

  probe process("/usr/lib64/libvirt.so.0").function("virConnectOpen") {
    printf("Open %p\n", $name)
  }

> Nor do I seem to be able to use function() matches in combination
> with a library() statement
> 
>   probe process("/usr/bin/virsh").library("libvirt.so").function("virConnectOpen") {
>       printf("Open %s", $name)
>   }
> 
>   semantic error: probe point mismatch at position 2 (alternatives:
>     mark(string) provider(string)): keyword at demo.stp:9:55 while
>     resolving probe point process("/usr/bin/virsh").library("libvirt.so").function("virConnectOpen")
>         source: probe process("/usr/bin/virsh").library("libvirt.so").function("virConnectOpen") {
> 

Apparently process().library() probes only work for static markers in
the current translator. Would be nice to extend it to function and
statement too.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Userspace probes on library functions ?
  2010-10-21 16:20 Userspace probes on library functions ? Daniel P. Berrange
  2010-10-21 17:34 ` Mark Wielaard
@ 2010-10-21 17:58 ` Steve Fink
  2010-10-22  8:46   ` Daniel P. Berrange
  1 sibling, 1 reply; 6+ messages in thread
From: Steve Fink @ 2010-10-21 17:58 UTC (permalink / raw)
  To: Daniel P. Berrange; +Cc: systemtap

Does ltrace work in this case? It may be a more appropriate tool for
what you're doing. (Not that stap shouldn't be able to handle it too.)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Userspace probes on library functions ?
  2010-10-21 17:34 ` Mark Wielaard
@ 2010-10-22  8:43   ` Daniel P. Berrange
  2010-10-22  9:34     ` Mark Wielaard
  0 siblings, 1 reply; 6+ messages in thread
From: Daniel P. Berrange @ 2010-10-22  8:43 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: systemtap

On Thu, Oct 21, 2010 at 07:34:39PM +0200, Mark Wielaard wrote:
> On Thu, 2010-10-21 at 17:20 +0100, Daniel P. Berrange wrote:
> > I'm trying to use userspace probes to trace public API calls into the
> > libvirt.so library. While I can trace functions in the virsh executable
> > without trouble, eg
> > 
> >   probe process("/usr/bin/virsh").function("vshInit") {
> >       printf("init %p", $ctl)
> >   }
> > 
> > I'm unable to trace functions that are defined in the libvirt.so
> > 
> >   probe process("/usr/bin/virsh").function("virConnectOpen") {
> >       printf("Open %p", $name)
> >   }
> > 
> >   semantic error: no match while resolving probe point process("/usr/bin/virsh").function("virConnectOpen")
> 
> You can use the slightly non-intuitive:
> 
>   probe process("/usr/lib64/libvirt.so.0").function("virConnectOpen") {
>     printf("Open %p\n", $name)
>   }

Ha, I should have thought of that one! That works, but there's the slight
issue of having to include path (/usr/lib64) in the tapset, because that
prevents it working on i686. I could of course auto-generate the path bit
at build time, but I'm wondering how to make it work on a multilib x86_64
platform where you can have both the 32 & 64 bit libraries installed at
the same time in /usr/lib & /usr/lib64. 

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 :|

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Userspace probes on library functions ?
  2010-10-21 17:58 ` Steve Fink
@ 2010-10-22  8:46   ` Daniel P. Berrange
  0 siblings, 0 replies; 6+ messages in thread
From: Daniel P. Berrange @ 2010-10-22  8:46 UTC (permalink / raw)
  To: Steve Fink; +Cc: systemtap

On Thu, Oct 21, 2010 at 10:57:57AM -0700, Steve Fink wrote:
> Does ltrace work in this case? It may be a more appropriate tool for
> what you're doing. (Not that stap shouldn't be able to handle it too.)

It probably would for this specific case, but my final goal is to be able
to write systemtap tracing scripts that can cross the entire virtualization
stack from virt-manager (python), through libvirt & libvirtd, down to qemu,
kvm and the kernel. Being able to collect data this way will be very useful
because it avoids the need to correlate & re-order data from multiple
application specific log files / trace files which is what we currently
do for most debugging.

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 :|

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Userspace probes on library functions ?
  2010-10-22  8:43   ` Daniel P. Berrange
@ 2010-10-22  9:34     ` Mark Wielaard
  0 siblings, 0 replies; 6+ messages in thread
From: Mark Wielaard @ 2010-10-22  9:34 UTC (permalink / raw)
  To: Daniel P. Berrange; +Cc: systemtap

On Fri, 2010-10-22 at 09:43 +0100, Daniel P. Berrange wrote:
> On Thu, Oct 21, 2010 at 07:34:39PM +0200, Mark Wielaard wrote:
> > You can use the slightly non-intuitive:
> > 
> >   probe process("/usr/lib64/libvirt.so.0").function("virConnectOpen") {
> >     printf("Open %p\n", $name)
> >   }
> 
> Ha, I should have thought of that one! That works, but there's the slight
> issue of having to include path (/usr/lib64) in the tapset, because that
> prevents it working on i686. I could of course auto-generate the path bit
> at build time, but I'm wondering how to make it work on a multilib x86_64
> platform where you can have both the 32 & 64 bit libraries installed at
> the same time in /usr/lib & /usr/lib64. 

Frank just added basic process("/path/*/glob") support to git that
should probably take care of it when you write it as:
probe process("/usr/lib*/libvirt.so.0")

With the latest release you can do something like:

probe process("/usr/lib/libvirt.so.0").function("virConnectOpen")?,
      process("/usr/lib64/libvirt.so.0").function("virConnectOpen")?
  {
    printf("Open %p\n", $name);
  }

Which makes each probe point optional, so it matches either or both.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2010-10-22  9:34 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-21 16:20 Userspace probes on library functions ? Daniel P. Berrange
2010-10-21 17:34 ` Mark Wielaard
2010-10-22  8:43   ` Daniel P. Berrange
2010-10-22  9:34     ` Mark Wielaard
2010-10-21 17:58 ` Steve Fink
2010-10-22  8:46   ` Daniel P. Berrange

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).