Bug 17696 - Systemtap fails to find kernel tracepoints when kernel is built in a separate directory from source tree
Summary: Systemtap fails to find kernel tracepoints when kernel is built in a separate...
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: runtime (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-11 02:58 UTC by Zhuo QL
Modified: 2015-01-12 20:43 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Ignore kernel DW_AT_comp_dir if it's the same as the build tree (563 bytes, patch)
2015-01-09 17:28 UTC, Josh Stone
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Zhuo QL 2014-12-11 02:58:33 UTC
* A:

When kernel is built in a separate directory from the kernel source tree:

1) before building:

export BUILDDIR=/a/separate/path/
export KBUILD_OUTPUT=${BUILDDIR}/build

2) after building and installing:

   /lib/modules/`uname -r`/build links to /a/separate/path/
   /lib/modules/`uname -r`/source links to /kernel/source/tree/

Under this situation, stap -L 'kernel.trace("*")' lists nothing.

* B:

When kernel is built directly in kernel source tree directory,

   /lib/modules/`uname -r`/build links to /kernel/source/tree/
   /lib/modules/`uname -r`/source links to /kernel/source/tree/

Under this situation, stap -L 'kernel.trace("*")' lists all available tracepoints.
Comment 1 Josh Stone 2015-01-08 23:03:51 UTC
Please let me know if this commit fixed it for you:

commit b19a43768009076de3aea638922dfaebb687e3e9
Author: Josh Stone <jistone@redhat.com>
Date:   Thu Jan 8 14:47:20 2015 -0800

    Use the kernel source symlink for tracepoints
    
    When the source symlink is different than the build symlink, as for
    out-of-tree kernel builds and Debian linux-headers, then we should use
    that path as a prefix for finding tracepoint headers.
Comment 2 Zhuo QL 2015-01-09 12:45:36 UTC
(In reply to Josh Stone from comment #1)
> Please let me know if this commit fixed it for you:
> 
> commit b19a43768009076de3aea638922dfaebb687e3e9
> Author: Josh Stone <jistone@redhat.com>
> Date:   Thu Jan 8 14:47:20 2015 -0800
> 
>     Use the kernel source symlink for tracepoints
>     
>     When the source symlink is different than the build symlink, as for
>     out-of-tree kernel builds and Debian linux-headers, then we should use
>     that path as a prefix for finding tracepoint headers.

Thanks for your work, it works well with the debian system provided kernel!

But, it still does not work with my self-built kernel(built with a seperate KBUILD_OUTPUT).

I read the lines around your commit and some logs, then found line 11132 of tapsets.cxx: 

const char* name = dwarf_formstring (dwarf_attr (cudie, DW_AT_comp_dir, &attr));

Here we still get the dir to /lib/modules/${uname -r}/build  under this situation.

----------8<-------------
diff --git a/tapsets.cxx b/tapsets.cxx
index 85fd76b..1b82f55 100644
--- a/tapsets.cxx
+++ b/tapsets.cxx
@@ -11153,7 +11153,8 @@ tracepoint_builder::init_dw(systemtap_session& s)
     }

   // find kernel_source_tree from a source link, when different from build
-  if (s.kernel_source_tree == "" && endswith(s.kernel_build_tree, "/build"))
+  if ((s.kernel_source_tree == "" || endswith(s.kernel_source_tree, "/build"))
+      && endswith(s.kernel_build_tree, "/build"))
     {
       string source_tree = s.kernel_build_tree;
       source_tree.replace(source_tree.length() - 5, 5, "source");
---------->8--------------

This patch fixes it, could you consider applying it? 

Thanks again.
Comment 3 Josh Stone 2015-01-09 17:24:49 UTC
(In reply to Zhuo QL from comment #2)
> Thanks for your work, it works well with the debian system provided kernel!

And thank your for testing!

> But, it still does not work with my self-built kernel(built with a seperate
> KBUILD_OUTPUT).
> 
> I read the lines around your commit and some logs, then found line 11132 of
> tapsets.cxx: 
> 
> const char* name = dwarf_formstring (dwarf_attr (cudie, DW_AT_comp_dir, &attr));
> 
> Here we still get the dir to /lib/modules/${uname -r}/build  under this
> situation.

Ah, I see.  I think it would be better in this case if we avoid using the DW_AT_comp_dir at all when it is equal to the known s.kernel_build_tree.  I'll attach a patch to this effect.
Comment 4 Josh Stone 2015-01-09 17:28:46 UTC
Created attachment 8058 [details]
Ignore kernel DW_AT_comp_dir if it's the same as the build tree

Another alternative would be to add a new field to the session, so we can track all three possible trees separately: build, source, and DW_AT_comp_dir.  But I think this patch will suffice for now.
Comment 5 Zhuo QL 2015-01-10 01:24:36 UTC
(In reply to Josh Stone from comment #4)
> Created attachment 8058 [details]
> Ignore kernel DW_AT_comp_dir if it's the same as the build tree
> 
> Another alternative would be to add a new field to the session, so we can
> track all three possible trees separately: build, source, and
> DW_AT_comp_dir.  But I think this patch will suffice for now.

Cool! It works now :).

I think this issue can be marked as RESOLVED after the patch is committed.

Thank you.
Comment 6 Josh Stone 2015-01-12 20:43:42 UTC
commit f27496f3bbfd678cfde0a33dbc0ed2d13ab6a396