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