GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 24/07/2019 11:04, Ravindra Kumar Meena wrote:
>     This approach makes no sense to me.
> 
>     Per CPU you receive three record events in succession:
> 
>     [19:32:26.679099590] (+0.000046608) Record_Item
>     RTEMS_RECORDING_EVENT: {
>     cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_SWITCH_OUT" :
>     container =
>     216 ), data = 167837707 }
>     [19:32:26.679099590] (+0.000000000) Record_Item
>     RTEMS_RECORDING_EVENT: {
>     cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_STACK_CURRENT" :
>     container = 209 ), data = 32320 }
>     [19:32:26.679099590] (+0.000000000) Record_Item
>     RTEMS_RECORDING_EVENT: {
>     cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_SWITCH_IN" : container =
>     215 ), data = 151060501 }
> 
>     They have all the same timestamp.
> 
>     When you receive an RTEMS_RECORD_THREAD_SWITCH_OUT event, you store the
>     timestamp (per CPU) and the data (per-CPU, this is the thread ID).
> 
>     When you receive an RTEMS_RECORD_THREAD_SWITCH_IN event and the
>     timestamp matches, you use the values of the current event and the
>     values stored before to output an LTTNG sched_switch event.
> 
> I am trying this approach but I think there is one problem with it. When 
> RTEMS_RECORD_THREAD_SWITCH_IN event is received then there is no way to 
> receive it's next_* values.

You received RTEMS_RECORD_THREAD_SWITCH_OUT two record events before the 
  RTEMS_RECORD_THREAD_SWITCH_IN with the same timestamp. See my comment 
above. In these two record events all you need for the sched_switch 
event is contained.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.