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

[Amit Margalit]

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


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