GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

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

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

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>


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190805/af1e29c0/attachment-0002.html>