Re: SystemTap fails to find kernel tracepoints

[KDr2 <killy dot draw at gmail dot com>]

I did compile a kernel from source myself, but like what was done on
debian, I used a separate build directory from the source tree:

export BUILDDIR=/opt/kernel/build/3.10
export KBUILD_OUTPUT=${BUILDDIR}/build
export INSTALL_PATH=${BUILDDIR}/boot
export INSTALL_MOD_PATH=${BUILDDIR}/modules

stap can not find the tracepoint for this kernel either.

I'll try a kernel built directly in the source tree later when I get some time.

On Tue, Dec 9, 2014 at 9:37 AM, Josh Stone <jistone@redhat.com> wrote:
> On 12/08/2014 07:51 AM, David Smith wrote:
>> Systemtap is probably having problems with finding the tracepoint
>> header files (which would be in kernel-devel on a fedora system).
>
> Looking at a jessie VM I have laying around, I see:
>
>   /lib/modules/3.16.0-4-amd64
>     build -> /usr/src/linux-headers-3.16.0-4-amd64
>     source -> /usr/src/linux-headers-3.16.0-4-common
>
> That is, they're pointing to different locations, whereas on Fedora we
> have "source -> build".  And Debian's source/ has a lot more in it than
> build/ does, including the headers in include/trace/events/ that we use
> to figure out tracepoints and their precise types.
>
> It appears to be this way on wheezy too.  Does this mean debian users
> have never been able to use systemtap with tracepoints?  Does anybody
> have past experience here?
>
> In stap, we do have separate variables for kernel_build_tree and
> kernel_source_tree.  On Fedora, build_tree has just the headers
> (including trace/events), and source_tree is used for reading the full
> kernel sources in /usr/src/debug/kernel-$VERSION, from the
> kernel-debuginfo rpm.  Debian's source link isn't really that -- it's
> still just headers -- but we could probably use it that way to get
> tracepoints working.  AFAIK Debian doesn't have full debuginfo sources
> in a package anyway.



-- 
-- 

KDr2, http://kdr2.com