* Systemtap Upcoming Feature: Address to File:Line Mapping [not found] <252539308.11641276.1418658500370.JavaMail.zimbra@redhat.com> @ 2014-12-18 21:52 ` Abe Jakop 2014-12-19 15:21 ` Frank Ch. Eigler 0 siblings, 1 reply; 4+ messages in thread From: Abe Jakop @ 2014-12-18 21:52 UTC (permalink / raw) To: systemtap 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Systemtap Upcoming Feature: Address to File:Line Mapping 2014-12-18 21:52 ` Systemtap Upcoming Feature: Address to File:Line Mapping Abe Jakop @ 2014-12-19 15:21 ` Frank Ch. Eigler 2014-12-19 23:19 ` Abe Jakop 0 siblings, 1 reply; 4+ messages in thread From: Frank Ch. Eigler @ 2014-12-19 15:21 UTC (permalink / raw) To: Abe Jakop; +Cc: systemtap 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Systemtap Upcoming Feature: Address to File:Line Mapping 2014-12-19 15:21 ` Frank Ch. Eigler @ 2014-12-19 23:19 ` Abe Jakop 2014-12-20 12:58 ` Frank Ch. Eigler 0 siblings, 1 reply; 4+ messages in thread From: Abe Jakop @ 2014-12-19 23:19 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: systemtap ----- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Systemtap Upcoming Feature: Address to File:Line Mapping 2014-12-19 23:19 ` Abe Jakop @ 2014-12-20 12:58 ` Frank Ch. Eigler 0 siblings, 0 replies; 4+ messages in thread From: Frank Ch. Eigler @ 2014-12-20 12:58 UTC (permalink / raw) To: Abe Jakop; +Cc: systemtap 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-12-20 12:58 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <252539308.11641276.1418658500370.JavaMail.zimbra@redhat.com> 2014-12-18 21:52 ` Systemtap Upcoming Feature: Address to File:Line Mapping Abe Jakop 2014-12-19 15:21 ` Frank Ch. Eigler 2014-12-19 23:19 ` Abe Jakop 2014-12-20 12:58 ` Frank Ch. Eigler
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).