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