GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 05/08/2019 13:14, Ravindra Kumar Meena wrote:
>      > Have made changes:
>      >
>     https://github.com/rmeena840/rtems-tools/commit/a6701361eab030698464bab67d63a880d503c90e
>      >
>      > Have a look.
>      >
>      > The following line will give the same thread_name. There is no
>     need to
>      > reverse. I checked the output. The values are the same.
>      > snprintf( item_name_str, sizeof( item_name_str ), "%08"PRIx64,
>      > item->data );
> 
>     This change makes no sense.
> 
>     1. If you store data from a previous record item to use it in the
>     future, then you must always store this information per-CPU. So, this
>     thread_id_name must be per-CPU.
> 
> Okay
> 
> 
>     2. Each of the RTEMS_RECORD_THREAD_NAME events, the item->data integer
>     contains up to 4 or 8 chars.
> 
>     https://git.rtems.org/rtems/tree/cpukit/libtrace/record/record-userext.c#n54
> 
> item->data integer can be converted into a string by calling snprintf(); 
> Isn't it correct?

No, using sprintf() is not the right way to do this. Please try to 
understand the referenced code section. The string is converted char by 
char into a sequence of integers. You have to reverse this and convert 
an integer into a sequence of chars.

> 
> 
> 
>     3. You don't need extra memcpy() calls, just store the string directly
>     in ctx->thread_names[api_id][thread_id]. The first
>     RTEMS_RECORD_THREAD_NAME uses
>     ctx->thread_names[api_id][thread_id][0..7], the second uses
>     ctx->thread_names[api_id][thread_id][8..15]. The third and later are an
>     error, just ignore it.
> 
> We can store the 16 char all at once then why are we doing this in two 
> parts.

You get the name fragments event by event. When you receive the first 
name you don't know how many fragments will come in total.

> 
> My approach is like this:
> Get the api_id from thread_id and for the same api_id increase the 
> thread_id counter and store the string whenever new 
> RTEMS_RECORD_THREAD_NAME is received.
> eg.
> <api_id=0><thread_id=0><thread_name>
> <api_id=0><thread_id=1><thread_name>
> <api_id=0><thread_id=2><thread_name>
> 
> <api_id=1><thread_id=0><thread_name>
> <api_id=1><thread_id=1><thread_name>
> <api_id=1><thread_id=2><thread_name>

This makes no sense to me. The thread id is fixed for a sequence of 
thread name events. From the thread id you get the API index and the 
object index.

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