<font size=2 face="sans-serif">Absolutely wonderful idea, IMHO.</font>
<br>
<br><font size=2 face="sans-serif">I encountered the same problem, and
partially solved it, differently. I think your idea complements my solution,
so perhaps together we can come up with something even better.</font>
<br>
<br><font size=2 face="sans-serif">There are a couple of requirements that
are still hard to meet with your solution:</font>
<ol>
<li value=1><font size=2 face="sans-serif">If I seek to an arbitrary position
in the trace, I have no easy way to find which shared object the address
belongs to.</font>
<li value=2><font size=2 face="sans-serif">If I read the trace on a different
system than where it was generated, I may not have access to the same shared
objects, so "</font><tt><font size=2>/lib64/libc-2.17.so</font></tt><font size=2 face="sans-serif">"
may not be valid, or worse - may be valid but different architecture and
therefore the symbol addresses would be different.</font></ol>
<br><font size=2 face="sans-serif">Solving the first problem required me
to emit something that would identify the shared object with every tracepoint
that includes a function pointer that needs translation.</font>
<br>
<br><font size=2 face="sans-serif">Saving the base address of the shared
object that the address belongs to plus the path or name of the shared
object was too expensive, and didn't solve the second problem.</font>
<br>
<br><font size=2 face="sans-serif">What I did was this:</font>
<ul>
<li><font size=2 face="sans-serif">Make a map of the loaded shared objects
and their base addresses - called before anything can generate any trace</font>
<li><font size=2 face="sans-serif">For each shared object, also keep a
"signature" that uniquely identifies this shared object</font>
<li><font size=2 face="sans-serif">Emit the signature and the function
address (with the base address subtracted already)</font>
<li><font size=2 face="sans-serif">Created a script that reads the shared
objects to create a map of signature-to-(address-to-symbol) nested map,
and post-process babeltrace output to provide the translation</font></ul>
<br><font size=2 face="sans-serif">For signature, I took the first 8 bytes
of the unique build-id that GCC stores for every executable and shared
object (SHA1) in the .note.build-id ELF section.</font>
<br>
<br><font size=2 face="sans-serif">The problems with my approach are:</font>
<br><font size=2 face="sans-serif">1. I wasn't handling dlopen/dlclose
calls</font>
<br><font size=2 face="sans-serif">2. Relying on external tools and post-processing</font>
<br>
<br><font size=2 face="sans-serif">Combining the 2 sugestions gives a good
solution - i.e. track dlopen/dlclose to generate the shared object maps
during runtime so that we can emit signature+function-pointer(relative
to its shared object).</font>
<br>
<br><font size=2 face="sans-serif">Moreover, I suggest further improvement
- a TP_FIELDS macro "ctf_symbol" that will automatically do exactly
this, and store the signature+address-to-name mapping in the metadata...</font>
<br>
<br><font size=2 face="sans-serif">What do you think?</font>
<br>
<br><font size=2 color=#000080 face="sans-serif">Amit Margalit</font>
<br><font size=2 color=#808000 face="sans-serif">IBM XIV </font><font size=2 face="sans-serif">-
<i>Storage Reinvented</i></font>
<br><font size=2 face="sans-serif">XIV-NAS Development Team</font>
<br><font size=2 face="sans-serif">Tel. 03</font><font size=2 face="Arial">-689-7774</font>
<br><font size=2 face="Arial">Fax. 03-689-7230</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif"><Paul_Woegerer@mentor.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif"><lttng-dev@lists.lttng.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">08/27/2013 09:33 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">[lttng-dev]
[RFC PATCH lttng-ust] Make lttng-ust aware of shared
object base addresses (issue #474)</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Hello,<br>
<br>
To allow graphical trace viewers to provide features like address-to-symbol
resolution or source lookup (address-to-lineinfo), information about the
shared object base address mappings are required. These mappings are inherently
time based and potentially change during the application runtime (dlopen,
dlcose, dlopen, ...). It's even possible that at a later point in the program
the same shared object gets mapped to a different base address (I saw that
once on ARM or PPC)<br>
<br>
The patch set below provides an initial (prof of concept) implementation
(based on the previous discussion on </font></tt><a href=https://bugs.lttng.org/issues/474><tt><font size=2>https://bugs.lttng.org/issues/474</font></tt></a><tt><font size=2>).
It's a starting point for further discussions that will hopefully help
me to provide an implementation that is good enough for upstream inclusion.<br>
<br>
Applying the patch provides the following additional events for userspace
tracing:<br>
<br>
*) ust_baddr:push with TP_ARGS(void *, baddr, const char*, sopath, int64_t,
size, int64_t, mtime)<br>
*) ust_baddr:pop with TP_ARGS(void *, baddr)<br>
<br>
Tracepoints 'ust_baddr:push' and 'ust_baddr:pop' are emitted for every
runtime object that makes use of tracing (i.e emits tracepoints/includes
tracepoint.h). This is also true for shared objects that get loaded during
application run time. Loading a shared object via dlopen will, for example,
result in emitting:<br>
[14:22:07.841547445] ust_baddr:push: { cpu_id = 4 }, { baddr = 0x7F8D13DFD000,
sopath = "/path/to/plugin1.so", size = 21968, mtime = 1377519722
}<br>
..likewise sometime later a corresponding dlclose in the program will result
in emitting:<br>
[14:22:07.841867307] ust_baddr:pop: { cpu_id = 4 }, { baddr = 0x7F8D13DFD000
}<br>
<br>
*) ust_baddr:init with TP_ARGS(void *, baddr, const char*, sopath, int64_t,
size, int64_t, mtime)<br>
<br>
In contrast, ust_baddr:init tracepoints are only emitted when a userspace
application gets a "session enabled" sent by the sessiond (necessary
if tracing starts in the middle of an already running application). In
this case all the currently loaded shared objects are iterated and the
base address mappings are recored as ust_baddr:init events with the same
payload structure as ust_baddr:push. E.g.<br>
<br>
[15:20:32.763114409] ust_baddr:init: { cpu_id = 1 }, { baddr = 0x7F5BAC083000,
sopath = "/lib64/libc-2.17.so", size = 1992089, mtime = 1359709982
}<br>
[15:20:32.763118346] ust_baddr:init: { cpu_id = 1 }, { baddr = 0x7F5BAEAF0000,
sopath = "/lib64/ld-2.17.so", size = 163493, mtime = 1359709980
}<br>
[15:20:32.763125921] ust_baddr:init: { cpu_id = 1 }, { baddr = 0x7F5BAAE7C000,
sopath = "/other/currently/loaded/shared-object.so.0.0.0", size
= 58359, mtime = 1377516019 }<br>
... and so on for all other currently loaded shared objects<br>
<br>
The known deficiencies of the current implementation are:<br>
<br>
Non-optional 'ust_baddr:push' and 'ust_baddr:pop' events <br>
<br>
<br>
-- <br>
Paul Woegerer, SW Development Engineer<br>
Sourcery Analyzer <</font></tt><a href=http://go.mentor.com/sourceryanalyzer><tt><font size=2>http://go.mentor.com/sourceryanalyzer</font></tt></a><tt><font size=2>><br>
Mentor Graphics, Embedded Software Division<br>
<br>
<br>
<br>
_______________________________________________<br>
lttng-dev mailing list<br>
lttng-dev@lists.lttng.org<br>
</font></tt><a 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><tt><font size=2><br>
<br>
</font></tt>
<br>