This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Systemtap Upcoming Feature: Address to File:Line Mapping


ajakop wrote:

> [...]
> I have been working on a new feature for SystemTap to provide
> address to file:line mappings. [...]

Nice, I can hardly wait.

> [...]  As for using this new feature, there are two new tapset
> functions, usymfileline() and symfileline(). The former requires a
> user-space address, and a kernel address for the the latter.

Could we also have [u]symfile and/or [u]symline?  That way, script
code wouldn't need to parse [u]symfileline if they only wanted one
or the other. 

> Since this feature stores line data for runtime access,
> using this feature may result in large probe modules.

Looking forward to advice as to whether further data
compression may significantly help.


> [...]
> linenumbers.stp
> ===============
>  1 probe process.statement("*") {
>  2   printf("addr: %#x, file and line: %s\n",
>  3          addr(), usymfileline(addr()) )
>  4 }

(uaddr() in this case.)

> Running the script from above, this is the output.
>
> $ stap linenumbers.stp -c ./linenumbers
> addr: 0x400544, file and line: linenumbers1.c:13
> addr: 0x400517, file and line: linenumbers1.c:7
> [...]

So to that extent, it's kind of like decomposing pn(), which should
have the function / line number stuff expanded from the statement("*")
wildcard.  Another way this could be used is a more detailed version
of the pf3.stp sample, logging [u]symfileline in addition to the other
stuff.


Glancing at that pf3.stp sample, maybe [u]sym* family of functions
should more regularly throw catchable errors in case of errors,
instead of hard-coding a policy of returning a hexified parameter.
That way the caller can more easily omit the info in its report.  So,

before:

    try { // modname() can throw
      fn = "k:".modname(addr()).":".symname(addr()).":".symfileline(addr())
    } catch {
      fn = "k:<unknown>:".symname(addr()).":".symfileline(addr())
    }

after:

  try { part_1 = "k:".modname(addr()) }
  catch { part_1 = sprintf("k:%p",addr()) }
  try { part_2 = ":".symname(addr()) }
  catch { part_2 = "" }
  try { part_3 = ":".symfileline(addr()) }
  catch { part3 = "" }
  fn = part_1.part_2.part_3

It's a little wordier, but limits noise from unavailable information.

Hm, what if we had an expression-context try/catch?  (Maybe a
generalization of ? : ... sort of like @choose_defined()?)

  part_1 = "k:" . try_catch(modname(addr()), sprintf("%p",addr()))
  part_2 = try_catch(":".symname(addr()), "")
  part_3 = try_catch(":".symfilename(addr()), "")
  fn = part_1.part_2.part_3

- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]