<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 09/11/2013 11:12 AM, Amit Margalit
wrote:<br>
</div>
<blockquote
cite="mid:OFD1B4818C.1C2E4DBC-ONC2257BE3.002FD513-C2257BE3.00328DCA@il.ibm.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<font size="2" face="sans-serif">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.</font>
<br>
<br>
<font size="2" face="sans-serif">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.</font>
<br>
<br>
<font size="2" face="sans-serif">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.</font>
<br>
</blockquote>
<br>
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).<br>
<br>
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.<br>
<br>
Note that this is the same concept as used by video
compression/streaming:<br>
I‑frame, P‑frame, P‑frame, P‑frame, ..., I‑frame, P‑frame, P‑frame,
P‑frame, ...<b><br>
</b>See:
<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Video_compression_picture_types">http://en.wikipedia.org/wiki/Video_compression_picture_types</a><br>
<br>
Best,<br>
Paul<b><br>
</b><b><br>
</b>
<blockquote
cite="mid:OFD1B4818C.1C2E4DBC-ONC2257BE3.002FD513-C2257BE3.00328DCA@il.ibm.com"
type="cite">
<b><br>
</b><b><font size="2" face="sans-serif">I have a different
solution, which I
think I have explained here before: </font></b><b><a
moz-do-not-send="true"
href="http://lists.lttng.org/pipermail/lttng-dev/2013-August/021263.html"><font
size="3" color="blue"><u>http://lists.lttng.org/pipermail/lttng-dev/2013-August/021263.html</u></font></a></b><b><font
size="3">
</font></b><b>
</b><b><br>
</b>
<b><br>
</b><b><font size="2" face="sans-serif">I vote for adding this to
the metadata.
It can be in addition to the ust_baddr events suggeted by
Paul.</font></b><b>
</b><b><br>
</b>
<b><br>
</b><b><font size="2" face="sans-serif">Amit</font></b><b>
</b><b><br>
</b>
<b><br>
</b><b><font size="2" color="#000080" face="sans-serif">Amit
Margalit</font></b><b>
</b><b><br>
</b><b><font size="2" color="#808000" face="sans-serif">IBM XIV </font></b><b><font
size="2" face="sans-serif">-
<i>Storage Reinvented</i></font></b><b>
</b><b><br>
</b><b><font size="2" face="sans-serif">XIV-NAS Development Team</font></b><b>
</b><b><br>
</b><b><font size="2" face="sans-serif">Tel. 03</font></b><b><font
size="2" face="Arial">-689-7774</font></b><b>
</b><b><br>
</b><b><font size="2" face="Arial">Fax. 03-689-7230</font></b><b>
</b><b><br>
</b>
<b><br>
</b>
<b><br>
</b>
<b><br>
</b><b><font size="1" color="#5f5f5f" face="sans-serif">From:
</font></b><b><font size="1" face="sans-serif">"Woegerer,
Paul"
<a class="moz-txt-link-rfc2396E" href="mailto:Paul_Woegerer@mentor.com"><Paul_Woegerer@mentor.com></a></font></b><b>
</b><b><br>
</b><b><font size="1" color="#5f5f5f" face="sans-serif">To:
</font></b><b><font size="1" face="sans-serif">Matthew
Khouzam <a class="moz-txt-link-rfc2396E" href="mailto:matthew.khouzam@ericsson.com"><matthew.khouzam@ericsson.com></a></font></b><b>
</b><b><br>
</b><b><font size="1" color="#5f5f5f" face="sans-serif">Cc:
</font></b><b><font size="1" face="sans-serif">lttng-dev
<a class="moz-txt-link-rfc2396E" href="mailto:lttng-dev@lists.lttng.org"><lttng-dev@lists.lttng.org></a>,
Mathieu Desnoyers <a class="moz-txt-link-rfc2396E" href="mailto:mathieu.desnoyers@efficios.com"><mathieu.desnoyers@efficios.com></a></font></b><b>
</b><b><br>
</b><b><font size="1" color="#5f5f5f" face="sans-serif">Date:
</font></b><b><font size="1" face="sans-serif">09/10/2013
06:47 PM</font></b><b>
</b><b><br>
</b><b><font size="1" color="#5f5f5f" face="sans-serif">Subject:
</font></b><b><font size="1" face="sans-serif">Re:
[lttng-dev]
Getting function names with lttng-ust-cyg-profile.so</font></b><b>
</b><b><br>
</b>
<hr noshade="noshade">
<b><br>
</b>
<b><br>
</b>
<b><br>
</b><b><tt><font size="2">On 09/10/2013 05:37 PM, Matthew Khouzam
wrote:<br>
> On 13-09-10 03:00 AM, Woegerer, Paul wrote:<br>
>> Hi Alexandre,<br>
>><br>
>> For trivial examples you can go with 'nm -CS' (or
the like), but
when<br>
>> you start to use liblttng-ust-cyg-profile.so in
combination with
shared<br>
>> objects you will need to record base address
information as well
(to<br>
>> allow you map a virtual memory address at a given
point in time
to<br>
>> offset and path of a shared object (or
executable)).<br>
>><br>
>> That is one of the reasons why I have submitted:<br>
>> </font></tt></b><b><a moz-do-not-send="true"
href="http://lists.lttng.org/pipermail/lttng-dev/2013-August/021264.html"><tt><font
size="2">http://lists.lttng.org/pipermail/lttng-dev/2013-August/021264.html</font></tt></a></b><b><tt><font
size="2"><br>
> This is a very interesting approach, +1 from me on
that.<br>
<br>
Thanks.<br>
<br>
With that approach no redundant data (that is already
available as<br>
debuginfo) gets replicated in the actual trace data.<br>
Only the bare minimum of information gets traced to allow
you at any<br>
time to map a VM address to a debuginfo address + debuginfo
location.<br>
<br>
-- <br>
Paul Woegerer, SW Development Engineer<br>
Sourcery Analyzer <</font></tt></b><b><a
moz-do-not-send="true"
href="http://go.mentor.com/sourceryanalyzer"><tt><font
size="2">http://go.mentor.com/sourceryanalyzer</font></tt></a></b><b><tt><font
size="2">><br>
Mentor Graphics, Embedded Software Division<br>
<br>
<br>
_______________________________________________<br>
lttng-dev mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:lttng-dev@lists.lttng.org">lttng-dev@lists.lttng.org</a><br>
</font></tt></b><b><a moz-do-not-send="true"
href="http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev"><tt><font
size="2">http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev</font></tt></a></b><b><tt><font
size="2"><br>
<br>
</font></tt></b>
<b><br>
</b>
</blockquote>
<b><br>
</b><b><br>
</b>
<pre class="moz-signature" cols="72">--
Paul Woegerer, SW Development Engineer
Sourcery Analyzer <a class="moz-txt-link-rfc2396E" href="http://go.mentor.com/sourceryanalyzer"><http://go.mentor.com/sourceryanalyzer></a>
Mentor Graphics, Embedded Software Division</pre>
</body>
</html>