On 06/08/2019 10:26, Ravindra Kumar Meena wrote:
Thread name is in the right order now.
Yes, the order is all right, but you still overwrite thread names which
consist of multiple events.
I am not able to figure out how overwritten is happening. In my code
overwritten case is handled by:
if( cctx->thread_names[ api_id ][ thread_id ][ i ] == 0x00 )
This check is wrong, you should not rely on previous content of this
buffer. If you see the first RTEMS_RECORD_THREAD_NAME event, then you
should overwrite the complete 16 chars with 0 and fill it up with the
new content. In the first RTEMS_RECORD_THREAD_NAME event, you fill up
chars 0..7, in the second 8..15. For this you have to store somehow
thread_id_name on which position you are, e.g.
typedef struct thread_id_name{
uint64_t thread_id;
size_t name_index;
} thread_id_name;
Set name_index to 0 if you see a RTEMS_RECORD_THREAD_ID event. Increment
it by one after you processed a RTEMS_RECORD_THREAD_NAME event.
The above line means that write value only if a NULL char position is
available. When we receive first RTEMS_RECORD_THREAD_NAME the loop will
start filling the NULL char position from the beginning and when second
RTEMS_RECORD_THREAD_NAME is received then NULL char are filled just
after the previously filled char position.
e.g.
Object Index: 30
Name: 36697773
Name: 71206b73
On a 64-bit target, the data field contains 8 chars. Why do you only
print 4 chars here?
After the first iteration of for loop, the 16 size char array will be:
{s,w,i,6,0,0,0,0,0,0,0,0,0,0,0,0}
After the second iteration of for loop, the 16 size char array will be:
{s,w,i,6,s,k, ,q,0,0,0,0,0,0,0,0}
For this decode, the value will be "swi6sk q". Right? This is exactly
what I am getting in Konsole.
For this task you should end up with "swi6: task queu".
--
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
