[lttng-dev] Getting function names with lttng-ust-cyg-profile.so

[Woegerer, Paul]

On 09/11/2013 11:12 AM, Amit Margalit wrote:
> 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.

We could provide a solution to this problem with my approach by emitting
an update of the shared object state info every n x K events (configurable).

Assuming we have a 10GB trace data set, we could emit a full shared
object state dump after every 100K events of regular trace data (with
the same baddr_init events we emit at session_start time). By doing so
you don't need to start reading the entire trace from the beginning.
Just start reading 100K events before the events you are interested in,
and you can guarantee to find a "key frame" for shared object state info.

Note that this is the same concept as used by video compression/streaming:
I-frame, P-frame, P-frame, P-frame, ..., I-frame, P-frame, P-frame,
P-frame, ...*
*See: http://en.wikipedia.org/wiki/Video_compression_picture_types

Best,
Paul*
**
*
> *
> **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" <Paul_Woegerer at mentor.com>****
> **To:        **Matthew Khouzam <matthew.khouzam at ericsson.com>****
> **Cc:        **lttng-dev <lttng-dev at lists.lttng.org>, Mathieu
> Desnoyers <mathieu.desnoyers at efficios.com>****
> **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
> lttng-dev at lists.lttng.org
> **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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20130911/1b1ea16c/attachment-0001.html>