[lttng-dev] Fix filter: pointer to string, not string, should be on stack -- query

[David Bryant]

Hi,

I'm trying to understand the following changeset:

commit 27f4b6094f399f2fe231b58801dce98cbd21baa9
Author: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
Date: Tue Sep 4 12:17:07 2012 -0400

Fix filter: pointer to string, not string, should be on stack

Fixes #329

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>

Bug link: https://bugs.lttng.org/issues/329

The patch forces the ctf_string() argument to be an lvalue. It appears 
to be in support of tracepoint filtering of the sort:

lttng enable-event ust_tests_demo2:loop -u --filter 'stringfield=="text"'

Because the argument must be an lvalue the examples/easy-ust won't 
compile (anymore) with the following patch:

diff -u --recursive easy-ust/sample_component_provider.h 
easy-ust-reproduce/sample_component_provider.h
--- easy-ust/sample_component_provider.h 2012-11-07 17:00:09.879299565 +1030
+++ easy-ust-reproduce/sample_component_provider.h 2012-11-07 
16:57:02.121647871 +1030
@@ -61,6 +61,11 @@
*/
#include <lttng/tracepoint.h>

+#ifndef SEE_ONCE
+#define SEE_ONCE
+static inline char * echo(char * c) { return c; }
+#endif
+
/*
* The following tracepoint event writes a message (c string) into the
* field message of the trace event message in the provider
@@ -100,7 +105,7 @@
* The ctf_string macro takes a c string and writes it into a field
* named "message"
*/
- ctf_string(message, text)
+ ctf_string(message, echo(text))
)
)
/*

Compilation results in:

$ make
gcc -I/home/dbryant/local5/include -I. -c -o sample.o sample.c
gcc -I/home/dbryant/local5/include -I. -c -o tp.o tp.c
In file included from 
/home/dbryant/local5/include/lttng/ust-tracepoint-event.h:338:0,
from /home/dbryant/local5/include/lttng/tracepoint-event.h:41,
from sample_component_provider.h:140,
from tp.c:25:
././sample_component_provider.h: In function 
‘__event_prepare_filter_stack__sample_component___message’:
././sample_component_provider.h:76:1: error: lvalue required as unary 
‘&’ operand
make: *** [tp.o] Error 1

I'm trying to make sense of all this. I've been passing 
generated-on-the-fly rvalues through ctf_string() using v2.0.5 with no 
(noticeable) problems. Now I can't. Should I never have been doing that, 
or has this change had an unintended consequence? Admittedly I haven't 
been filtering tracepoints on text criteria and am not considering 
things from that angle. Should ctf_string() arguments always be string 
literals?!

Thanks,
Dave

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.