<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">Hello Mathieu,<br>
<br>
What is the status regarding this patch.<br>
Any reason why it doesn’t get merged ?<br>
<br>
Thanks,<br>
Paul<br>
<br>
On 07/03/2012 09:45 AM, Woegerer, Paul wrote:<br>
</div>
<blockquote cite="mid:4FF2A31D.9020100@mentor.com" type="cite">Hi
Mathieu,
<br>
<br>
here is the revised patch that makes tracepoint.h and
ust-tracepoint-event.h robust against -finstrument-functions.
<br>
I tested it against our small ackermann sample (3 custom
tracepoints + -finstrument-functions). See screenshots.
<br>
<br>
Btw, nice macro metaprogramming in ust-tracepoint-event.h :)
<br>
<br>
Thanks,
<br>
Paul
<br>
<br>
On 06/30/2012 08:16 PM, Mathieu Desnoyers wrote:
<br>
<blockquote type="cite">* Woegerer, Paul
(<a class="moz-txt-link-abbreviated" href="mailto:Paul_Woegerer@mentor.com">Paul_Woegerer@mentor.com</a>) wrote:
<br>
<blockquote type="cite">Hi Mathieu,
<br>
<br>
libust 0.x uses notrace
(__attribute__((no_instrument_function)) for all
<br>
functions that are involved in event emitting.
<br>
<br>
For example:
<br>
./libust/marker.c:122:notrace void
__ust_marker_empty_function(const
<br>
struct ust_marker *mdata,
<br>
./libust/marker.c:137:notrace void ust_marker_probe_cb(const
struct
<br>
ust_marker *mdata,
<br>
./libust/marker.c:197:static notrace void
<br>
ust_marker_probe_cb_noarg(const struct ust_marker *mdata,
<br>
<br>
I just realized that this is no more the case for lttng-ust.
<br>
Was it a conscious decision not to use notrace for LTTng 2.0
lttng-ust,
<br>
or is it just missing ?
<br>
</blockquote>
just missing. only needed for -finstrument-functions.
<br>
<br>
<blockquote type="cite">I would like to have notrace also in
lttng-ust, at least for the
<br>
_DECLARE_TRACEPOINT macro in tracepoint.h.
<br>
</blockquote>
I guess the probes generated by ust-tracepoint-event.h would
need that
<br>
too. A patch that adds those noinline everywhere where it's
needed
<br>
(hint: all functions called on the tracing patch within public
headers
<br>
of lttng-ust 2.0 would be a good start). Please test the patch
by
<br>
tracing a program automatically instrumented by
-finstrument-functions
<br>
and see if things blow up.
<br>
<br>
Thanks,
<br>
<br>
Mathieu
<br>
<br>
<blockquote type="cite">Like this for example:
<br>
<br>
diff --git a/include/lttng/tracepoint.h
b/include/lttng/tracepoint.h
<br>
index 5bab476..71665dc 100644
<br>
--- a/include/lttng/tracepoint.h
<br>
+++ b/include/lttng/tracepoint.h
<br>
@@ -137,6 +137,7 @@ extern "C" {
<br>
<br>
#define _DECLARE_TRACEPOINT(_provider, _name, ...) \
<br>
extern struct tracepoint
__tracepoint_##_provider##___##_name;
<br>
\
<br>
+static inline void
<br>
__tracepoint_cb_##_provider##___##_name(_TP_ARGS_PROTO(__VA_ARGS__))
<br>
__attribute__ ((no_instrument_function)); \
<br>
static inline void
<br>
__tracepoint_cb_##_provider##___##_name(_TP_ARGS_PROTO(__VA_ARGS__))
\
<br>
{ \
<br>
struct tracepoint_probe
*__tp_probe; \
<br>
@@ -158,12 +159,16 @@ end: \
<br>
tp_rcu_read_unlock_bp(); \
<br>
} \
<br>
static inline void
__tracepoint_register_##_provider##___##_name(char
<br>
*name, \
<br>
+ void (*func)(void), void *data) __attribute__
<br>
((no_instrument_function)); \
<br>
+static inline void
__tracepoint_register_##_provider##___##_name(char
<br>
*name, \
<br>
void (*func)(void), void *data) \
<br>
{ \
<br>
__tracepoint_probe_register(name, func, data, \
<br>
__tracepoint_##_provider##___##_name.signature); \
<br>
} \
<br>
static inline void
__tracepoint_unregister_##_provider##___##_name(char
<br>
*name, \
<br>
+ void (*func)(void), void *data) __attribute__
<br>
((no_instrument_function)); \
<br>
+static inline void
__tracepoint_unregister_##_provider##___##_name(char
<br>
*name, \
<br>
void (*func)(void), void *data) \
<br>
{ \
<br>
__tracepoint_probe_unregister(name, func, data); \
<br>
<br>
Greetings,
<br>
Paul
<br>
<br>
-- <br>
Paul Woegerer | SW Development Engineer
<br>
Mentor Embedded(tm) | Prinz Eugen Straße 72/2/4, Vienna, 1040
Austria
<br>
P 43.1.535991320
<br>
Nucleus® | Linux® | Android(tm) | Services | UI | Multi-OS
<br>
<br>
Android is a trademark of Google Inc. Use of this trademark is
subject to Google Permissions.
<br>
Linux is the registered trademark of Linus Torvalds in the
U.S. and other countries.
<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>
<a class="moz-txt-link-freetext" href="http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev">http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev</a>
<br>
</blockquote>
</blockquote>
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
lttng-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:lttng-dev@lists.lttng.org">lttng-dev@lists.lttng.org</a>
<a class="moz-txt-link-freetext" href="http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev">http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Paul Woegerer | SW Development Engineer
Mentor Embedded(tm) | Prinz Eugen Straße 72/2/4, Vienna, 1040 Austria
P 43.1.535991320
Nucleus® | Linux® | Android(tm) | Services | UI | Multi-OS
Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.</pre>
</body>
</html>