This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/17073] SystemTap doesn't support module given by full path
- From: "jlebon at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Thu, 03 Jul 2014 22:06:29 +0000
- Subject: [Bug translator/17073] SystemTap doesn't support module given by full path
- Auto-submitted: auto-generated
- References: <bug-17073-6586 at http dot sourceware dot org/bugzilla/>
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.