GSoC Project | Basic Support for Trace Compass
Sebastian Huber
sebastian.huber at embedded-brains.de
Mon Aug 5 11:30:01 UTC 2019
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.
More information about the devel
mailing list