I agree with Paul, that no redundant data gets replicated with his approach, and my only concern is that this approach really forces a viewer to be sequential.
Maybe "forces" is too strong a word - but a viewer than wants to let you "roam" the trace freely will have to read the entire trace to figure out the mapping between address and symbol at each point in time. At this time, we keep 10GB worth of LTTng traces in our system, but future models will certainly use more. A user asking to go to the end of the trace will have to wait until the entire trace is read in order to see correct translations. I have a different solution, which I think I have explained here before: http://lists.lttng.org/pipermail/lttng-dev/2013-August/021263.html I vote for adding this to the metadata. It can be in addition to the ust_baddr events suggeted by Paul. Amit Amit Margalit IBM XIV - Storage Reinvented XIV-NAS Development Team Tel. 03-689-7774 Fax. 03-689-7230 From: "Woegerer, Paul" <[email protected]> To: Matthew Khouzam <[email protected]> Cc: lttng-dev <[email protected]>, Mathieu Desnoyers <[email protected]> Date: 09/10/2013 06:47 PM Subject: Re: [lttng-dev] Getting function names with lttng-ust-cyg-profile.so On 09/10/2013 05:37 PM, Matthew Khouzam wrote: > On 13-09-10 03:00 AM, Woegerer, Paul wrote: >> 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 > This is a very interesting approach, +1 from me on that. Thanks. With that approach no redundant data (that is already available as debuginfo) gets replicated in the actual trace data. Only the bare minimum of information gets traced to allow you at any time to map a VM address to a debuginfo address + debuginfo location. -- 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
