Systemtap Upcoming Feature: Address to File:Line Mapping

Systemtap Upcoming Feature: Address to File:Line Mapping

[Abe Jakop]

Hello everyone,

I have been working on a new feature for SystemTap to provide
address to file:line mappings. The goal of this email is to
provide details and demonstrate how to use the new feature.

To implement this feature, line debugging information is
retrieved and stored in a generated header for processing
during runtime. The line data is used to determine an
approximate line number to match the given address.

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.

These functions return a string containing the file and line
number based on the provided address.

Similar to [u]symname(), if the address given cannot be
mapped to a line number or filename, the given address is
returned as a hexadecimal number. 

For testing purposes, see branch ajakop/12276 on the
SystemTap repo:
https://sourceware.org/git/gitweb.cgi?p=systemtap.git

____
NOTE

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

_____
USAGE

A basic example of the feature is to print out a list of
what statements are executed.

Take the c program below, for example, which will just
call a few functions.

linenumbers2.c
===============
 1  void func4 () {
 2    return;
 3  }
 4 
 5  void func3 () {
 6    func4();
 7  }

linenumbers1.c
===============
 1  #include "linenumbers2.c"
 2 
 3  void func2 () {
 4    func4();
 5  }
 6 
 7  void func1 (int num) {
 8    for(; num > 0; num--)
 9      func2();
10    func3();
11  }
12 
13  int main () {
14    func1 (2);
15  }


The stap script below will print out the file name and 
line number for each statement the probe hits.

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


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
addr: 0x400507, file and line: linenumbers1.c:3
addr: 0x4004f0, file and line: linenumbers2.c:1
addr: 0x400507, file and line: linenumbers1.c:3
addr: 0x4004f0, file and line: linenumbers2.c:1
addr: 0x4004f7, file and line: linenumbers2.c:5
addr: 0x4004f0, file and line: linenumbers2.c:1

===============

This addition to SystemTap's tapset library will
hopefully be beneficial to users for gathering
and printing out relevant information.

Comments and feedback are always welcome.

Abegail Jakop

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

[Frank Ch. Eigler]

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

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

[Abe Jakop]

----- Original Message -----
> From: "Frank Ch. Eigler" <fche@redhat.com>

> > [...]  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.

Yes. I will add those functions into the tapset library.

> > 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.

That's definitely on the list things to do for this feature.

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

Oops. Good catch. 

> 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

Would this not cause backwards compatibility issues? Or were you thinking
this change would be effective for SystemTap versions >=2.7?

Should I open a PR for this change and another for the feature below?

> 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

Thanks for the feedback,

Abegail

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

[Frank Ch. Eigler]

ajakop wrote:

> [...]
>> 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. [...]
>
> Would this not cause backwards compatibility issues? Or were you thinking
> this change would be effective for SystemTap versions >=2.7?

Yes & yes - akin to what we did earlier in PR15044.

> Should I open a PR for this change and another for the feature below?

Yes, please!

- FChE

PS.  Yes.