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

[Mathieu Desnoyers]

* David Bryant (david.bryant at quantum.com) wrote:
> Hi,
>
> I'm trying to understand the following changeset:
>

Hello !

Please upstream lttng-ust master branch HEAD, which includes this
commit:

commit c4261b0aecaf281fc1ced4c7af96b1ff6d2600d7
Author: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
Date:   Wed Nov 7 13:24:58 2012 -0500

    Fix: re-allow non-lvalue string, sequence, array parameters
    
    Issue introduced by upstream commit:
    
      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
    
    Reported-by: David Bryant <david.bryant at quantum.com>
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>

Please let me know if it helps,

Thanks,

Mathieu

> 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.
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com