Re: [RFC] fix kallsyms to allow discrimination of local symbols
From: Frank Ch. Eigler
Date: Mon Jul 21 2008 - 21:46:21 EST
James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> 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. [...]
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
- 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
- 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/