GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

----- Am 29. Jul 2019 um 12:21 schrieb Ravindra Kumar Meena rmeena840 at gmail.com:

>>
>> > What I understand from here is that _prev_state is the previous state of
>> > the thread(TID)).
>>
>> Yes, but what is the meaning of these state values? We have to figure this
>> out since we need a mapping from RTEMS thread states to these Linux thread
>> states. Could you use an example trace from Linux to check if the
>> information referenced in this email answer makes sense?
>>
> 
> $ grep "#define TASK_" include/linux/sched.h
> #define TASK_RUNNING                    0x0000
> #define TASK_INTERRUPTIBLE              0x0001
> #define TASK_UNINTERRUPTIBLE            0x0002
> #define TASK_PARKED                     0x0040
> #define TASK_DEAD                       0x0080
> #define TASK_WAKEKILL                   0x0100
> #define TASK_WAKING                     0x0200
> #define TASK_NOLOAD                     0x0400
> #define TASK_NEW                        0x0800
> #define TASK_STATE_MAX                  0x1000
> #define TASK_KILLABLE                   (TASK_WAKEKILL |
> TASK_UNINTERRUPTIBLE)
> #define TASK_STOPPED                    (TASK_WAKEKILL | __TASK_STOPPED)
> #define TASK_TRACED                     (TASK_WAKEKILL | __TASK_TRACED)
> #define TASK_IDLE                       (TASK_UNINTERRUPTIBLE | TASK_NOLOAD)
> #define TASK_NORMAL                     (TASK_INTERRUPTIBLE |
> TASK_UNINTERRUPTIBLE)
> #define TASK_REPORT                     (TASK_RUNNING | TASK_INTERRUPTIBLE
>| \
> 
> In babeltrace output _prev_state have { 0, 1, 1026, 4096 } values.
> If you have look at above #define <TASK_*>. They have been defined in hex
> format.
> eg.
> 0 is 0x0000 which means TASK_RUNNING
> 1 is 0x0001 which means TASK_INTERRUPTIBLE
> 1026 in decimal is 0x402 which is 0x400 | 0x002. That is TASK_NOLOAD |
> TASK_UNINTERRUPTIBLE, or, as defined above, it's simply TASK_IDLE.
> 
> So in this way, all the prev_state are defined.

Ok, I think on RTEMS only TASK_RUNNING and TASK_IDLE make sense at the moment. You have to use the thread ID to determine if an idle thread is involved in the sched_switch event.

> 
>>
>> >
>> >
>> >> It would be good to get task names for the IDs. Do you have an idea how
>> >> we can do this?
>> >>
>> > With task name do you mean RTEMS_RECORD_THREAD_SWITCH_IN
>> > and RTEMS_RECORD_THREAD_SWITCH_OUT?
>> >
>> > if so this can be done by calling:
>> > rtems_record_event_text( item->event )
>>
>> Attached is a patch for RTEMS. The record server sends all thread names to
>> the client after the header.
>>
>> For thread name changes and new threads we have to think about.
>>
> I applied the patch. The bootstrap worked successfully. I am not sure what
> I have to do with this.

Please look at the patch and try to understand it.

Once you connect to the record server, it sends you the names of all present threads after the header. You can collect this information and use it to map a thread ID to a name.

The mapping might be a bit difficult to implement in C for you. You can also use C++ for the record client if this makes it easier for you.