I ran into a bug while using barectf on the parallella platform : If there were multiple tracepoints in an eCore program then everything was nicely written by the eCore and retrieved by the consumer daemon. But, I figured that if the content of all tracepoints reached during an execution on the eCore wasn't big enough to fulfil a packet (that is to say that we use only one packet during the execution and that this packet is not full at the end of the program), then nothing happened.
Apparently the problem is just a missing '1' in the 'initialized' field of the global tracing context of the eCore at the end of said initialization, causing the "tracing_fini()" function to not close the packet. This explains why the problem isn't to be expected when there is at least two packets, since the opening of a new packet automatically closes the previous one inside the barectf files (i.e without checking the good initialization of the context).
I ran into a bug while using barectf on the parallella platform : If there were multiple tracepoints in an eCore program then everything was nicely written by the eCore and retrieved by the consumer daemon. But, I figured that if the content of all tracepoints reached during an execution on the eCore wasn't big enough to fulfil a packet (that is to say that we use only one packet during the execution and that this packet is not full at the end of the program), then nothing happened.
Apparently the problem is just a missing '1' in the 'initialized' field of the global tracing context of the eCore at the end of said initialization, causing the "tracing_fini()" function to not close the packet. This explains why the problem isn't to be expected when there is at least two packets, since the opening of a new packet automatically closes the previous one inside the barectf files (i.e without checking the good initialization of the context).