GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 06/08/2019 07:20, Ravindra Kumar Meena wrote:
>      >
>      > Have made changes. Simplified the code.
>      >
>     https://github.com/rmeena840/rtems-tools/commit/9e09be40db85e4e903118f8eb5eb1ea1e41baf46
> 
>     Yes, this moves into the right direction:
> 
>     +      for( i = 0; i < THREAD_NAME_SIZE - 1; i++ ){
>     +        if( cctx->thread_names[ api_id ][ thread_id ][ i ] == 0x00 ){
>     +          cctx->thread_names[ api_id ][ thread_id ][ i ] = (
>     thread_name  & 0xff );
>     +          thread_name = ( thread_name >> 8 );
>     +        }
>     +      }
> 
>     On a 32-bit target you may get up to 4 RTEMS_RECORD_THREAD_NAME events,
>     on a 64-bit target you may get up to 2 RTEMS_RECORD_THREAD_NAME events.
> 
>     Your code overwrites the data from previous name events and only the
>     last one is visible. You have to add the name index (i) to
>     thread_id_name.
> 
> The overwrites thing is taken care of by :
> if( cctx->thread_names[ api_id ][ thread_id ][ i ] == 0x00 )
> 
> If thread_name is received for the same api_id and thread_id then it 
> will write only in empty char position.

For example this sequence of events is generated in case the thread name 
exceeds 8 chars:

THREAD_ID:a01001e
THREAD_NAME:737769363a207461
THREAD_NAME:736b2071756575

The decoded thread name is "swi6: task queu"

For each RTEMS_RECORD_THREAD_NAME event you start the loop at i == 0, so 
you overwrite your previous data.

> I checked the value with the provided output. The value is the same but 
> in reverse order.

It would be good to have the thread names displayed in the right order.

-- 
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.