[Bug runtime/17696] New: Systemtap fails to find kernel tracepoints when kernel is built in a separate directory from source tree

[Bug runtime/17696] New: Systemtap fails to find kernel tracepoints when kernel is built in a separate directory from source tree

[zhuo at bitoasis dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17696

            Bug ID: 17696
           Summary: Systemtap fails to find kernel tracepoints when kernel
                    is built in a separate directory from source tree
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: zhuo at bitoasis dot com

* 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/17696] Systemtap fails to find kernel tracepoints when kernel is built in a separate directory from source tree

[zhuo at bitoasis dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17696

Zhuo QL <zhuo at bitoasis dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zhuo at bitoasis dot com

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/17696] Systemtap fails to find kernel tracepoints when kernel is built in a separate directory from source tree

[jistone at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17696

Josh Stone <jistone at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING
                 CC|                            |jistone at redhat dot com

--- Comment #1 from Josh Stone <jistone at redhat dot com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/17696] Systemtap fails to find kernel tracepoints when kernel is built in a separate directory from source tree

[zhuo at bitoasis dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17696

--- Comment #2 from Zhuo QL <zhuo at bitoasis dot com> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/17696] Systemtap fails to find kernel tracepoints when kernel is built in a separate directory from source tree

[jistone at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17696

--- Comment #3 from Josh Stone <jistone at redhat dot com> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/17696] Systemtap fails to find kernel tracepoints when kernel is built in a separate directory from source tree

[jistone at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17696

--- Comment #4 from Josh Stone <jistone at redhat dot com> ---
Created attachment 8058
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8058&action=edit
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/17696] Systemtap fails to find kernel tracepoints when kernel is built in a separate directory from source tree

[zhuo at bitoasis dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17696

--- Comment #5 from Zhuo QL <zhuo at bitoasis dot com> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/17696] Systemtap fails to find kernel tracepoints when kernel is built in a separate directory from source tree

[jistone at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17696

Josh Stone <jistone at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Josh Stone <jistone at redhat dot com> ---
commit f27496f3bbfd678cfde0a33dbc0ed2d13ab6a396

-- 
You are receiving this mail because:
You are the assignee for the bug.