qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 0/8] [RfC] fix tracing for modules


From: Gerd Hoffmann
Subject: Re: [PATCH v3 0/8] [RfC] fix tracing for modules
Date: Wed, 31 Mar 2021 12:55:32 +0200

  Hi,

> > Well, "make install" with --prefix=$HOME/qemu-install fixed that for the 
> > time
> > being.
> > 
> > Now I have this:
> > 
> > kraxel@sirius ~/qemu-install/bin# sudo ./qemu-trace-stap -v run 
> > ./qemu-system-x86_64 "qxl_soft_reset"
> > Using tapset dir '/home/kraxel/qemu-install/share/systemtap/tapset' for 
> > binary './qemu-system-x86_64'
> > Compiling script 'probe qemu.system.x86_64.log.qxl_soft_reset {}'
> > semantic error: unresolved function pid: identifier 'pid' at 
> > /home/kraxel/qemu-install/share/systemtap/tapset/qemu-system-x86_64-log.stp:5451:41
> >         source:     printf("%d@%d qxl_soft_reset %d\n", pid(), 
> > gettimeofday_ns(), qid)
> >                                                         ^
> > 
> > Pass 2: analysis failed.  [man error::pass2]
> > 
> > Any clue why pid() isn't known?
> 
> Hmm, strange, makes me think we have a bug causing it to not pull in
> global functions.

Hmm.  5.1.0 fails the same way.  5.2.0 fails in a different way.  Seems
we had temporary breakage in 5.2.0 (was that the module thing which
needed some workaround?).  Given 5.1.0 fails too I suspect this is a
systemtap change (/me runs fedora 33).  Googling didn't found much,
other than indicating pid() is used frequently in examples and
tutorials.

stap-prep asked for kernel-debuginfo, but installing that (huge package
with 3.5G(!) installed size) hasn't changed the situation.  Guess I only
actually need that if I want trace the kernel not userspace?

take care,
  Gerd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]