On 12/06/2012 02:19 AM, David Bryant wrote:
> statement-expression would also work. Are we conflating separate ideas -
> the idea of user conditions and the idea of setup/cleanup?
FWIW, tracepoint_cond could be implemented as loan pattern (in pseudocode):
with_tp( provider, name, REF ) {
if (cond) {
// pre emit code block
...
emit_REF( arg0, ... );
// post emit code block
...
}
}
This could even be nested. E.g.
with_tp( provider1, nameA, REF1 ) {
with_tp( provider2, nameB, REF2 ) {
if (cond) {
// pre emit code block if both are enabled
...
emit_REF1( arg0x, ... );
emit_REF2( arg0y, ... );
// post emit code block if both are enabled
...
}
}
}
Nesting would be rather unpleasant with the proposed
tracepoint_cond(provider, name, pre, post, ...).
--
Paul
>
>> While we are there, it would be good to make the "pre" handler test a
>> condition. For your use-case, you would just have to pass a pre :
>>
>> { printf("pre\n"); a = malloc(16); 1; }
>>
>> So we could do:
>>
>> if (pre)
>> __tracepoint_cb_##provider##___##name(__VA_ARGS__);
>> (post)
>>
>> and therefore support not only to setup something, but also to add an
>> extra check on whether tracing should be skipped or not. If someone
>> passes "1" as end of the compound statement, it will always evaluate to
>> 1, and therefore the compiler will remove any extra branch in -O2.
>>
>> One question stands though: how would we integrate this with sdt.h
>> STAP_PROVEV() ?
> I'm yet to look at this.
>
> 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@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Paul Woegerer | SW Development Engineer
http://go.mentor.com/sourceryanalyzer
Mentor Embedded(tm) | Prinz Eugen Straße 72/2/4, Vienna, 1040 Austria
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.
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
