This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC] fix kallsyms to allow discrimination of local symbols
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: James Bottomley <James dot Bottomley at HansenPartnership dot com>
- Cc: linux-kernel <linux-kernel at vger dot kernel dot org>, systemtap at sourceware dot org
- Date: Mon, 21 Jul 2008 21:44:38 -0400
- Subject: Re: [RFC] fix kallsyms to allow discrimination of local symbols
- References: <1216676595.3433.80.camel@localhost.localdomain>
James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> [...] Fix all of this by prefixing local symbols with the actual C
> file name they occur in separated by '|' (I had to use '|' since ':'
> is already in use for module prefixes in kallsyms lookups. [...]
> Comments?
Can we take some time to review how we got here?
- You disprefer systemtap's use of an established, non-deprecated API
for placing kernel probes. (We calculate addresses by a mixture of
elf-analysis and runtime user-space lookup means. That's partly
since kallsyms_lookup was unexported over our objections.) There is
nothing outright broken (e.g. incorrect numbers) with what systemtap
has been doing for years.
- You argue that symbols+offset kprobing is better. We can see that,
in some sense, but ...
- I explain that we are used to final address calculating, as we'll
have to do that regardless for user-space probes. Plus we need to
work with kernels that predate the symbol+offset kprobe api
extension. So this change would not simplify systemtap in any way.
You do not respond.
- I offer _stext+offset (for the kernel) and (.text*)+offset (for
modules) kprobes: basically to use the "better" symbol+offset
kprobes api, but use the same single reference addresses we already
do, and leaving just the final addition to the kernel. You do not
respond materially.
- You argue that it cannot only be any symbol+offset ... but the actual
nearest symbol+offset. But that doesn't work for local symbols. So
you fix that to the nearest globally visible symbol+offset. But this
requires:
- yet more extra work and code from systemtap
- extension to the kernel build system, and kallsyms runtime data to
fix the current local-symbol-ambiguity problem
- storage of all that new file name data in permanent unswappable
kernel data (>>100kB, if done simply prefixing local symbol names
file file names).
- possible further complications related to filename string matching
- You have yet to invent a scheme to allow offloading *data* address
calculations to the kernel. Without that (and perhaps more),
systemtap will *still* have to fetch same base _stext etc.
addresses at run time that it currently does -- even if it did not
use them to compute kprobes addresses.
In total, this path would end up with both systemtap and the kernel
more complex, larger and a bit slower too. Does that still seem an
acceptable cost, just to get systemtap to change its preferred kprobes
api?
- FChE