Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

On Tue, Jul 15, 2008 at 03:24:22PM -0500, James Bottomley wrote:
> [...]
> > > > > This is highly undesirable because it represents a subversion of the
> > > > > kernel API to gain access to unexported symbols.
> > [...]
> > Maybe, but what "subversion" are you talking about?
> 
> using a hand crafted relocation function to gain access to kernel
> symbols instead of the provided API.

Please choose your words more carefully.  We don't "subvert" anything,
where one would mean sneaking around some sort of protection.  We use
an established, existing facility (placing kprobes by address).  We
compute addresses correctly (an error would be obvious), and is
conceptually not so different from an address being passed in at run
time from /proc/kallsyms.


> > Of course, but for our purposes, the kernel will be just one amongst
> > many probing targets.  We will be tracking multiple symbol tables and
> > unwind data for user-space.
> 
> You're going to hand roll your own symbol resolution for user space too?
> Isn't it pretty easy simply to get ld.so to do that for you?

I don't see how.  We can't call into ld.so from kernel space.  One may
need to probe ld.so itself.


> [...] I made sure that pure addressed based kprobes still work even
> when they have to use the symbol_name/offset resolution method
> ... the new code just works out the closest symbol and applies an
> offset.

(Not important, but did you consider the possibility that this chosen
reference symbol may, for whatever reason, not be listed in the
kernel's kprobe-assisting symbol table?)


> > Again, please consider user-space.  The runtime will need similar
> > symbol resolution code *for user space* anyway.  Keeping it in there
> > for the kernel is no incremental complexity - if anything, the
> > opposite.
>
> I really think there might have to be separate runtime pieces for
> user space and for the kernel.  Trying to build a single scheme that
> works in both places looks cumbersome.  In the separate case, the
> kernel piece, which is potentially movable inside the kernel,
> becomes a lot simpler. [...]

It may just be in the eye of the beholder.  To me, a single scheme
that supports all the various address spaces (and kernel versions and
configurations!) we deal with is just as appealing to me as increasing
kernel specialization is to you.


> OK, with -ffunction-sections you can't offset from _stext which
> seems to be what _stp_module_relocate() uses.  [...]  That means
> that each function address can potentially move depending on the
> number of relocation stubs embedded between it and the next
> function.

I may be missing something, but doesn't all that happen during
linking?  We process linked executables, not object files subject to
further run-time relaxation/shrinkage.


- FChE