[Bug translator/17073] New: SystemTap doesn't support module given by full path

[Bug translator/17073] New: SystemTap doesn't support module given by full path

[jlebon at redhat dot com]

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

            Bug ID: 17073
           Summary: SystemTap doesn't support module given by full path
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: jlebon at redhat dot com

Trying to probe a module by providing the full path to it in the 'module' probe
component does not work:

$ cat mymodule.c
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>

static int __init mymodule_init(void)
{
    printk(KERN_INFO "Hello world!\n");
    return 0;
}

static void __exit mymodule_cleanup(void)
{
    printk(KERN_INFO "Cleaning up module.\n");
}

module_init(mymodule_init);
module_exit(mymodule_cleanup);
$ make
$ stap -e 'probe
module("/home/vm/codebase/systemtap/systemtap/tmp/mymodule.ko").function("mymodule_init")
{ println(ppfunc()) }' -c 'sudo insmod mymodule.ko && sudo rmmod mymodule.ko'
$

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

[Bug translator/17073] SystemTap doesn't support module given by full path

[jlebon at redhat dot com]

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

--- Comment #1 from Jonathan Lebon <jlebon at redhat dot com> ---
Created attachment 7645
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7645&action=edit
potential patch

This occurs because of name mismatches:
- Both the .name and .path members of the corresponding _stp_module struct are
set to the full path of the module.
- When the module notifier is called from the kernel, only the module name is
passed, path information is lost. So when we try to update section addresses,
we fail to match against any of the structs and thus fail to update.
- Even if the above is fixed, the dwarf_derived_probe_group emits in the
corresponding stap_dwarf_probe the full path for the .module member. This also
causes a mismatch to occur when trying to relocate the probe address.

The patch given fixes these issues by retrieving the actual module name from
the .gnu.linkonce.this_module section and using that name when emitting the
_stp_module struct and stap_dwarf_probe structs.

NB: note the TODO item in the patch re. calculating the proper offset for the
module name.

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

[Bug translator/17073] SystemTap doesn't support module given by full path

[fche at redhat dot com]

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

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Jeff.Haran at citrix dot com

--- Comment #2 from Frank Ch. Eigler <fche at redhat dot com> ---
*** Bug 14596 has been marked as a duplicate of this bug. ***

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

[Bug translator/17073] SystemTap doesn't support module given by full path

[jlebon at redhat dot com]

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

--- Comment #3 from Jonathan Lebon <jlebon at redhat dot com> ---
(In reply to Jonathan Lebon from comment #1)
> NB: note the TODO item in the patch re. calculating the proper offset for
> the module name.

Looking at this more deeply now, this is not as easy as it seems. The struct is
defined in <linux/module.h> but clearly userspace apps shouldn't include that.

We could instead simply rely on DWARF information and retrieve the
DW_AT_data_member_location attribute from the name DW_TAG_member. But this
assumes we have DWARF info to begin with. Since we are now able to probe
functions without DWARF info, this would be a sad requirement to add.

Another way would be to defer this work until runtime, at which point we can
directly use offsetof(), although I'm not too sure how feasible ELF inspection
is there. The deferring also adds complexity which I'd rather avoid.

The easy way out is to go the 'heuristicky' way and simply assume that the
module name is the $(basename $path .ko). This is more or less what elfutils
does but in reverse (i.e. find the ko file from the module name, see
libdwfl/linux-kernel-module.c).

We can also do a combination of the two, i.e. if we have DWARF, then use that,
otherwise just use the basename.

Thoughts?

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

[Bug translator/17073] SystemTap doesn't support module given by full path

[jlebon at redhat dot com]

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

Jonathan Lebon <jlebon at redhat dot com> changed:

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

--- Comment #4 from Jonathan Lebon <jlebon at redhat dot com> ---
(In reply to Jonathan Lebon from comment #3)
> The easy way out is to go the 'heuristicky' way and simply assume that the
> module name is the $(basename $path .ko). This is more or less what elfutils
> does but in reverse (i.e. find the ko file from the module name, see
> libdwfl/linux-kernel-module.c).

Done in commit 4766b1e.

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