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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
