GSoC Project | Basic Support for Trace Compass
Ravindra Kumar Meena
rmeena840 at gmail.com
Wed Jun 26 05:01:30 UTC 2019
>
>
> I had a look at the metadata file:
>
> typedef enum events_e : uint64_t_be {
>
Because I am passing the item->event value in big-endian byte order. This
will take passed value in big-endian byte order.
Now metadata trace description is in little-endian
trace {
major = 1;
minor = 8;
byte_order = le;
};
It will instruct babeltrace to read the big-endian value in little-endian.
Hence giving us the correct value.
> Why is it like this? Your structure looks like this:
>
> typedef struct ctf_event {
> uint32_t event_id;
> uint64_t ns;
> uint32_t cpu;
> rtems_record_event event;
> uint64_t data;
> } ctf_event;
If you carefully look at the event structure I defined in metadata.
event {
name = "RTEMS_RECORDING_EVENT";
id=0;
fields := struct {
timestamp_t ns;
uint32_t cpu;
rtems_record_event events;
uint64_t data;
};
};
I have defined id=0 here. This instructs babeltrace that new event has
begun and from this point, there will be four values (ns, cpu, events,
data).
Once the babeltrace has read the last value(data). It will again see event
id equal 0 stating that new event has begun and again it will read four
values.
It will become more clear if you see the generated trace in HEX format. I
used Ghex software for the same.
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190626/8441fffb/attachment-0002.html>
More information about the devel
mailing list