Re: [RFC] fix kallsyms to allow discrimination of local symbols

[fche@redhat.com (Frank Ch. Eigler)]

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