eepp
commented
9 years ago It does work for me (using the latest barectf 0.x, v0.3.1).
Can you provide this:
- barectf version you're using
- your CTF metadata input file
- an example using the generated functions showing that they do not check if the packet is full and always return 0
I modified the "simple" example to test this: https://upl.io/cgrpjj.
Buffer size is 128 bytes, and each return value of open/trace function calls is printed.
Here's the output I get:
simple barectf example!
barectf_open_packet(): 0
barectf_trace_simple_uint32(): 0
barectf_trace_simple_int16(): 0
barectf_trace_simple_float(): 0
barectf_trace_simple_string(): 0
barectf_trace_simple_enum(): -1
barectf_trace_a_few_fields(): -1
barectf_trace_bit_packed_integers(): -1Here, barectf_trace_simple_enum() did not have enough space to record the whole event, so the event is not recorded, and -1 (-EBARECTF_NOSPC) is returned. Same thing for the following tracing function calls, although they should not be called if -EBARECTF_NOSPC was previously encountered: the packet should be closed after barectf_trace_simple_enum() returns -EBARECTF_NOSPC and a new one should be opened before calling barectf_trace_simple_enum() again to record it in the new packet.
I acknowledge that this whole manual packet management on the application side is very inconvenient. This is why I developed barectf 2, which I'm releasing today. It features automatic packet management (packet opening/closing/delivering and automatic discarded events count) thanks to barectf platforms (a new concept), effectively allowing continuous tracing from the application's point of view. You should have a look!
igutekunst
The generated trace functions will always return zero and do not appear to be checking if a trace packet is full.