This is the mail archive of the
mailing list for the systemtap project.
Re: kallsyms_lookup_name not exported
- From: Li Guanglei <guanglei at cn dot ibm dot com>
- To: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- Cc: fche at redhat dot com, David Wilder <dwilder at us dot ibm dot com>, systemtap at sourceware dot org
- Date: Thu, 28 Sep 2006 09:28:12 +0800
- Subject: Re: kallsyms_lookup_name not exported
- Organization: IBM CSTL
- References: <C56DB814FAA30B418C75310AC4BB279DAEA5C3@scsmsx413.amr.corp.intel.com>
Stone, Joshua I wrote:
On Tuesday, September 26, 2006 5:53 PM, firstname.lastname@example.org wrote:
[...] The symbol is still exported in the main git tree...
Not for long.
Either we will need to reopen this issue on LKML, or the runtime will
need to stop trying to use kallsyms* and instead rely in the symbol
table provided by the systemtap translator.
From what I can see, we use kallsyms_lookup_name in a few places to
locate functions that aren't exported. That's not behavior that good
kernel citizens should follow! We're hooking __kernel_text_address and
kallsyms_lookup, so we can map an address back to a function name. So
shouldn't we be asking for those exports instead?
We are trying to do legitimate things, and we could ask for the tools to
help us. But right now we're using kallsyms_lookup_name to hack our way
into the kernel, and I don't blame anyone if that isn't well received.
Currently LKET supports 3 timing methods: get_cycles(), sched_clock()
and do_gettimeofday(). sched_clock() is not exported by Kernel so I
use kallsyms_lookup_name to locate it. So I either ask Kernel to
export sched_clock() or delete sched_clock() timing method from LKET.
But anyway, at present I have to comment out sched_clock() relate
codes from LKET to avoid a compiling error