GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

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

Have made changes. Simplified the code.
https://github.com/rmeena840/rtems-tools/commit/9e09be40db85e4e903118f8eb5eb1ea1e41baf46



-- 
*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/20190806/00a81491/attachment-0002.html>