This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]