+1 on that. I think we should have a way for UST to store the function names in the metadata, so the trace remains valid for any viewer that correctly supports CTF.
I think Mathieu Desnoyers said once that this requires a modification to the CTF spec, so let's start raising out voice for this... As Paul mentioned, he has a solution, and I have a somewhat different solution (which I will share sometime in the near future), but I still think that having the function names in the metadata is better. Amit Margalit IBM XIV - Storage Reinvented XIV-NAS Development Team Tel. 03-689-7774 Fax. 03-689-7230 From: "Woegerer, Paul" <[email protected]> To: <[email protected]>, Mathieu Desnoyers <[email protected]> Cc: lttng-dev <[email protected]> Date: 09/10/2013 10:01 AM Subject: Re: [lttng-dev] Getting function names with lttng-ust-cyg-profile.so Hi Alexandre, For trivial examples you can go with 'nm -CS' (or the like), but when you start to use liblttng-ust-cyg-profile.so in combination with shared objects you will need to record base address information as well (to allow you map a virtual memory address at a given point in time to offset and path of a shared object (or executable)). That is one of the reasons why I have submitted: http://lists.lttng.org/pipermail/lttng-dev/2013-August/021264.html Thanks, Paul On 09/10/2013 01:44 AM, Mathieu Desnoyers wrote: > We might want to investigate doing a side-program that gathers the > executables on the system, and lookup the symbols from the ELF. We could > save those in a bin/ subdirectory of a CTF trace. All we need is > instrumentation of the dynamic linker, and to know the executable names > associated with PIDs. There is a UST feature request for dynamic linker > instrumentation. > > Thanks, > > Mathieu > > * Alexandre Montplaisir ([email protected]) wrote: >> Hi all, >> >> I've recently started playing with liblttng-ust-cyg-profile.so (aka, >> getting UST events from -finstrument-functions), and I have to say it's >> pretty nifty! I haven't done any benchmarks, but it's certainly faster >> than the typical printf() that people use with it... >> >> However, in the resulting trace, one only gets the addresses of the >> functions. I understand how it's relatively "easy" for the seasoned user >> to use nm or addr2line to get the actual function names, but would it >> possible - and how hard would it be - to have this information (function >> names) directly in the trace? >> >> >> I'm trying to leverage this feature in Eclipse TMF to display a call >> stack for such UST traces. And to be honest, displaying a call stack >> with only the function addresses is completely useless, we need the >> function names. >> >> We could have the user import a text file (which he can generate with >> "nm appname > file.txt" for example). But then he needs the original >> binary, which he might not have. And that binary needs to be compiled >> with debugging symbols. If the function name information was already in >> the trace, it would make the user experience much better, and our job >> much easier! ;) >> >> >> Thoughts? >> >> Thanks, >> Alex >> >> _______________________________________________ >> lttng-dev mailing list >> [email protected] >> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Paul Woegerer, SW Development Engineer Sourcery Analyzer <http://go.mentor.com/sourceryanalyzer> Mentor Graphics, Embedded Software Division _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
_______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
