Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

Documentation patch review is pending:
https://lists.rtems.org/pipermail/devel/2019-August/027215.html

>

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > What's the procedure for getting code merged? Do I have to raise PR on
> > GitHub or simply send a patch on devel?
>
> First we have to integrate the initial support for the rtems-record
> program:
>
> https://lists.rtems.org/pipermail/devel/2019-August/027278.html
>
> Then you can rebase your work on top of it and send a single patch to
> devel@rtems.org for the normal patch review.
>
Okay. Thanks.

Let me know if any other coding optimization/style needed in code.

Thanks


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 12/08/2019 12:27, Ravindra Kumar Meena wrote:

This is too complicated:

+    strcpy( filename, "event_" );
       snprintf( file_index, sizeof( file_index ), "%ld", i );
       strcat( filename, file_index );

In addition, the strcpy() and strcat() functions are dangerous to use.
Why don't you simply use:

snprintf( filename, sizeof( filename ), "event_%zu", i );

?

The i is of type size_t, so %ld is not the right format. Firstly, the
signedness is wrong, secondly using "l" is not portable.


Okay
https://github.com/rmeena840/rtems-tools/commit/1ffbe7d5dcea741a3e7ceec8ded869d38c20081f

Have a look.

What's the procedure for getting code merged? Do I have to raise PR on 
GitHub or simply send a patch on devel?


First we have to integrate the initial support for the rtems-record program:

https://lists.rtems.org/pipermail/devel/2019-August/027278.html

Then you can rebase your work on top of it and send a single patch to 
devel@rtems.org for the normal patch review.


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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> This is too complicated:
>
> +strcpy( filename, "event_" );
>   snprintf( file_index, sizeof( file_index ), "%ld", i );
>   strcat( filename, file_index );
>
> In addition, the strcpy() and strcat() functions are dangerous to use.
> Why don't you simply use:
>
> snprintf( filename, sizeof( filename ), "event_%zu", i );
>
> ?
>
> The i is of type size_t, so %ld is not the right format. Firstly, the
> signedness is wrong, secondly using "l" is not portable.
>

Okay
https://github.com/rmeena840/rtems-tools/commit/1ffbe7d5dcea741a3e7ceec8ded869d38c20081f

Have a look.

What's the procedure for getting code merged? Do I have to raise PR on
GitHub or simply send a patch on devel?


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 11/08/2019 09:51, Ravindra Kumar Meena wrote:

rtems-main.c coding style fix:
https://github.com/rmeena840/rtems-tools/commit/eeb2067783f7e375087bee913342ce3fecce7883


This is too complicated:

+strcpy( filename, "event_" );
 snprintf( file_index, sizeof( file_index ), "%ld", i );
 strcat( filename, file_index );

In addition, the strcpy() and strcat() functions are dangerous to use. 
Why don't you simply use:


snprintf( filename, sizeof( filename ), "event_%zu", i );

?

The i is of type size_t, so %ld is not the right format. Firstly, the 
signedness is wrong, secondly using "l" is not portable.


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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

rtems-main.c coding style fix:
https://github.com/rmeena840/rtems-tools/commit/eeb2067783f7e375087bee913342ce3fecce7883

>

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
>
> Ok, good. Please always check if the babeltrace and Trace Compass give
> the right results after the changes.
>
Yes. Both are displaying same output.

>
> If you use cctx->switch_event[ item->cpu ] and similar a couple of times
> in a function, then please assign it to a local pointer and use it, e.g.
>
> switch_event *se = >switch_event[ item->cpu ];
>
> Please check all structure names and make the similar to the names used
> in the metadata, e.g. swich_event -> event_sched_switch;
>
> Please check the style of the if again, it should be:
>
> if ( condition ) {
>   ...
> } else {
>   ...
> }
>
> Check the white space and position of the { }.
>
> When you have a function like get_api_of_id() you return the api, so the
> variable should be named "api":
>
>size_t api_id = get_api_of_id( cctx->thread_id_name[ item->cpu
> ].thread_id );
>
>size_t api = get_api_of_id( cctx->thread_id_name[ item->cpu
> ].thread_id );
>
> Declare all variables at the top of the function, e.g.
>
> size_t api;
> ...
> api = get_api_of_id( cctx->thread_id_name[ item->cpu ].thread_id );

https://github.com/rmeena840/rtems-tools/commit/11cf7626e40a20c9bfaf889a94d51171519d6dc0



-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

- Am 9. Aug 2019 um 16:11 schrieb joel j...@rtems.org:

> On Fri, Aug 9, 2019, 8:45 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> 
>>
>> - Joel Sherrill  schrieb:
>> > Coming in late but there isn't there a helper method to turn object names
>> > into strings from either 32 bit values or strings? Shouldn't that be
>> used?
>>
>> This program runs on the host.
>>
> 
> Couldn't the method be copied?

Yes, you are a bit late ;-)

The integer values with the thread name parts are in the record event data, not 
the object names.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Joel Sherrill]

On Fri, Aug 9, 2019, 8:45 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
> - Joel Sherrill  schrieb:
> > Coming in late but there isn't there a helper method to turn object names
> > into strings from either 32 bit values or strings? Shouldn't that be
> used?
>
> This program runs on the host.
>

Couldn't the method be copied?

>
> >
> > On Fri, Aug 9, 2019, 8:17 AM Sebastian Huber <
> > sebastian.hu...@embedded-brains.de> wrote:
> >
> > > On 09/08/2019 15:06, Ravindra Kumar Meena wrote:
> > > > rtems-main.c cleanup:
> > > >
> > >
> https://github.com/rmeena840/rtems-tools/commit/61d5dc45e43f0998ad9305d565926090215a5bdc
> > > >
> > > > Switch_event per CPU added:
> > > >
> > >
> https://github.com/rmeena840/rtems-tools/commit/8ffe8bd2adea27772a9ab0e578539dd99fa0174b
> > > >
> > > > Have a look.
> > >
> > > Ok, good. Please always check if the babeltrace and Trace Compass give
> > > the right results after the changes.
> > >
> > > If you use cctx->switch_event[ item->cpu ] and similar a couple of
> times
> > > in a function, then please assign it to a local pointer and use it,
> e.g.
> > >
> > > switch_event *se = >switch_event[ item->cpu ];
> > >
> > > Please check all structure names and make the similar to the names used
> > > in the metadata, e.g. swich_event -> event_sched_switch;
> > >
> > > Please check the style of the if again, it should be:
> > >
> > > if ( condition ) {
> > >   ...
> > > } else {
> > >   ...
> > > }
> > >
> > > Check the white space and position of the { }.
> > >
> > > When you have a function like get_api_of_id() you return the api, so
> the
> > > variable should be named "api":
> > >
> > >size_t api_id = get_api_of_id( cctx->thread_id_name[ item->cpu
> > > ].thread_id );
> > >
> > >size_t api = get_api_of_id( cctx->thread_id_name[ item->cpu
> > > ].thread_id );
> > >
> > > Declare all variables at the top of the function, e.g.
> > >
> > > size_t api;
> > > ...
> > > api = get_api_of_id( cctx->thread_id_name[ item->cpu ].thread_id );
> > >
> > > --
> > > 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
>
> --
> 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

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

- Joel Sherrill  schrieb:
> Coming in late but there isn't there a helper method to turn object names
> into strings from either 32 bit values or strings? Shouldn't that be used?

This program runs on the host.

> 
> On Fri, Aug 9, 2019, 8:17 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> 
> > On 09/08/2019 15:06, Ravindra Kumar Meena wrote:
> > > rtems-main.c cleanup:
> > >
> > https://github.com/rmeena840/rtems-tools/commit/61d5dc45e43f0998ad9305d565926090215a5bdc
> > >
> > > Switch_event per CPU added:
> > >
> > https://github.com/rmeena840/rtems-tools/commit/8ffe8bd2adea27772a9ab0e578539dd99fa0174b
> > >
> > > Have a look.
> >
> > Ok, good. Please always check if the babeltrace and Trace Compass give
> > the right results after the changes.
> >
> > If you use cctx->switch_event[ item->cpu ] and similar a couple of times
> > in a function, then please assign it to a local pointer and use it, e.g.
> >
> > switch_event *se = >switch_event[ item->cpu ];
> >
> > Please check all structure names and make the similar to the names used
> > in the metadata, e.g. swich_event -> event_sched_switch;
> >
> > Please check the style of the if again, it should be:
> >
> > if ( condition ) {
> >   ...
> > } else {
> >   ...
> > }
> >
> > Check the white space and position of the { }.
> >
> > When you have a function like get_api_of_id() you return the api, so the
> > variable should be named "api":
> >
> >size_t api_id = get_api_of_id( cctx->thread_id_name[ item->cpu
> > ].thread_id );
> >
> >size_t api = get_api_of_id( cctx->thread_id_name[ item->cpu
> > ].thread_id );
> >
> > Declare all variables at the top of the function, e.g.
> >
> > size_t api;
> > ...
> > api = get_api_of_id( cctx->thread_id_name[ item->cpu ].thread_id );
> >
> > --
> > 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

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

Re: GSoC Project | Basic Support for Trace Compass

[Joel Sherrill]

Coming in late but there isn't there a helper method to turn object names
into strings from either 32 bit values or strings? Shouldn't that be used?

On Fri, Aug 9, 2019, 8:17 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 09/08/2019 15:06, Ravindra Kumar Meena wrote:
> > rtems-main.c cleanup:
> >
> https://github.com/rmeena840/rtems-tools/commit/61d5dc45e43f0998ad9305d565926090215a5bdc
> >
> > Switch_event per CPU added:
> >
> https://github.com/rmeena840/rtems-tools/commit/8ffe8bd2adea27772a9ab0e578539dd99fa0174b
> >
> > Have a look.
>
> Ok, good. Please always check if the babeltrace and Trace Compass give
> the right results after the changes.
>
> If you use cctx->switch_event[ item->cpu ] and similar a couple of times
> in a function, then please assign it to a local pointer and use it, e.g.
>
> switch_event *se = >switch_event[ item->cpu ];
>
> Please check all structure names and make the similar to the names used
> in the metadata, e.g. swich_event -> event_sched_switch;
>
> Please check the style of the if again, it should be:
>
> if ( condition ) {
>   ...
> } else {
>   ...
> }
>
> Check the white space and position of the { }.
>
> When you have a function like get_api_of_id() you return the api, so the
> variable should be named "api":
>
>size_t api_id = get_api_of_id( cctx->thread_id_name[ item->cpu
> ].thread_id );
>
>size_t api = get_api_of_id( cctx->thread_id_name[ item->cpu
> ].thread_id );
>
> Declare all variables at the top of the function, e.g.
>
> size_t api;
> ...
> api = get_api_of_id( cctx->thread_id_name[ item->cpu ].thread_id );
>
> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 09/08/2019 15:06, Ravindra Kumar Meena wrote:

rtems-main.c cleanup:
https://github.com/rmeena840/rtems-tools/commit/61d5dc45e43f0998ad9305d565926090215a5bdc

Switch_event per CPU added:
https://github.com/rmeena840/rtems-tools/commit/8ffe8bd2adea27772a9ab0e578539dd99fa0174b

Have a look.


Ok, good. Please always check if the babeltrace and Trace Compass give 
the right results after the changes.


If you use cctx->switch_event[ item->cpu ] and similar a couple of times 
in a function, then please assign it to a local pointer and use it, e.g.


switch_event *se = >switch_event[ item->cpu ];

Please check all structure names and make the similar to the names used 
in the metadata, e.g. swich_event -> event_sched_switch;


Please check the style of the if again, it should be:

if ( condition ) {
 ...
} else {
 ...
}

Check the white space and position of the { }.

When you have a function like get_api_of_id() you return the api, so the 
variable should be named "api":


  size_t api_id = get_api_of_id( cctx->thread_id_name[ item->cpu 
].thread_id );


  size_t api = get_api_of_id( cctx->thread_id_name[ item->cpu 
].thread_id );


Declare all variables at the top of the function, e.g.

size_t api;
...
api = get_api_of_id( cctx->thread_id_name[ item->cpu ].thread_id );

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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

rtems-main.c cleanup:
https://github.com/rmeena840/rtems-tools/commit/61d5dc45e43f0998ad9305d565926090215a5bdc

Switch_event per CPU added:
https://github.com/rmeena840/rtems-tools/commit/8ffe8bd2adea27772a9ab0e578539dd99fa0174b

Have a look.

>

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > What to do for bound access for api_id? Should I use exit( EXIT_SUCCESS
> > ) for this?
>
> You ignore this item an continue.
>
Okay
https://github.com/rmeena840/rtems-tools/commit/24c7753238ab20fc8c002936657ee0f4c16a6e61


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 08/08/2019 17:29, Ravindra Kumar Meena wrote:

print_item() cleanup:
https://github.com/rmeena840/rtems-tools/commit/76f1d2898729c9f885abaef1e33a58247c4760dd 



What to do for bound access for api_id? Should I use exit( EXIT_SUCCESS 
) for this?


You ignore this item an continue.



The LTTng metadata also needs a license at the top. What should I add there?


The metadata do not need an extra license and copyright notice. This is 
just an interface specification.


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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

print_item() cleanup:
https://github.com/rmeena840/rtems-tools/commit/76f1d2898729c9f885abaef1e33a58247c4760dd


What to do for bound access for api_id? Should I use exit( EXIT_SUCCESS )
for this?

The LTTng metadata also needs a license at the top. What should I add there?

Thanks



-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

rtems-main.c cleanup:
https://github.com/rmeena840/rtems-tools/commit/527fc0f2f3c971c21741b28b1f0ecde6efb6eb4a

Copyright added:
https://github.com/rmeena840/rtems-tools/commit/dc0cc02e805691bd0fd6a42abe4a0e068587c0ed

Have a look.

>

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

On Thu, Aug 8, 2019 at 1:06 PM Ravindra Kumar Meena 
wrote:

> > Should I include whole metadata content in that char metadata[]?
>>
>> Yes, if everything is constant.
>>
> Okay
>
> https://github.com/rmeena840/rtems-tools/commit/13c81bfb3a72dd777507f3bf92a96ec50ab7dd17
>
>
> At the end of the file fwrite() is writing some small binary data. I don't
> know why that is happening.
> Because of this binary data at the end babeltrace is not able to read
> events.
>
> Fixed the issue:
https://github.com/rmeena840/rtems-tools/commit/7d150f742a8ca44d719b10d314c5ba84187ac7fb


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > Should I include whole metadata content in that char metadata[]?
>
> Yes, if everything is constant.
>
Okay
https://github.com/rmeena840/rtems-tools/commit/13c81bfb3a72dd777507f3bf92a96ec50ab7dd17


At the end of the file fwrite() is writing some small binary data. I don't
know why that is happening.
Because of this binary data at the end babeltrace is not able to read
events.



-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 08/08/2019 08:43, Ravindra Kumar Meena wrote:

No, not a typedef. Something like this:

diff --git a/misc/record/record-main.c b/misc/record/record-main.c
index 314bb78..b5d1a66 100644
--- a/misc/record/record-main.c
+++ b/misc/record/record-main.c
@@ -422,19 +422,28 @@ static rtems_record_client_status handler(
     return RTEMS_RECORD_CLIENT_SUCCESS;
   }

+static const char metadata[] =
+"/* CTF 1.8 */\n"
+"\n"
+"typealias integer { size = 5; align = 1; signed = false; } :=
uint5_t;\n"
+"typealias integer { size = 8; align = 8; signed = false; } :=
uint8_t;\n"
+"typealias integer { size = 32; align = 8; signed = false; } :=
uint32_t;\n"
+"typealias integer { size = 64; align = 8; signed = false; } :=
uint64_t;\n"
+"typealias integer { size = 64; align = 8; signed = false; } :=
unsigned long;\n";
+
   void generate_metadata(){
-  FILE *metadata = fopen("metadata","w");
+  FILE *file = fopen("metadata","w");
     assert( metadata !=  NULL );

-  fprintf(metadata, "/* CTF 1.8 */\n\n");
-  fprintf(metadata, "typealias integer { size = 5; align = 1; signed =
false; } := uint5_t;\
+  fwrite( metadata, sizeof( metadata ), 1, file );

Okay.
https://github.com/rmeena840/rtems-tools/commit/6ee5468224d70eda4147fb7739571ea91eac7b9c 



Should I include whole metadata content in that char metadata[]?


Yes, if everything is constant.

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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> No, not a typedef. Something like this:
>
> diff --git a/misc/record/record-main.c b/misc/record/record-main.c
> index 314bb78..b5d1a66 100644
> --- a/misc/record/record-main.c
> +++ b/misc/record/record-main.c
> @@ -422,19 +422,28 @@ static rtems_record_client_status handler(
> return RTEMS_RECORD_CLIENT_SUCCESS;
>   }
>
> +static const char metadata[] =
> +"/* CTF 1.8 */\n"
> +"\n"
> +"typealias integer { size = 5; align = 1; signed = false; } := uint5_t;\n"
> +"typealias integer { size = 8; align = 8; signed = false; } := uint8_t;\n"
> +"typealias integer { size = 32; align = 8; signed = false; } :=
> uint32_t;\n"
> +"typealias integer { size = 64; align = 8; signed = false; } :=
> uint64_t;\n"
> +"typealias integer { size = 64; align = 8; signed = false; } :=
> unsigned long;\n";
> +
>   void generate_metadata(){
> -  FILE *metadata = fopen("metadata","w");
> +  FILE *file = fopen("metadata","w");
> assert( metadata !=  NULL );
>
> -  fprintf(metadata, "/* CTF 1.8 */\n\n");
> -  fprintf(metadata, "typealias integer { size = 5; align = 1; signed =
> false; } := uint5_t;\
> +  fwrite( metadata, sizeof( metadata ), 1, file );
>
Okay.
https://github.com/rmeena840/rtems-tools/commit/6ee5468224d70eda4147fb7739571ea91eac7b9c


Should I include whole metadata content in that char metadata[]?


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 08/08/2019 06:10, Ravindra Kumar Meena wrote:

Could you please move the const metadata content to as few as possible

static const metadata_xyz[] = "...
...
...";

variables and write them with fwrite().

Sorry. I didn't get which part of the metadata you want to move. Are you 
talking about typedef?


No, not a typedef. Something like this:

diff --git a/misc/record/record-main.c b/misc/record/record-main.c
index 314bb78..b5d1a66 100644
--- a/misc/record/record-main.c
+++ b/misc/record/record-main.c
@@ -422,19 +422,28 @@ static rtems_record_client_status handler(
   return RTEMS_RECORD_CLIENT_SUCCESS;
 }

+static const char metadata[] =
+"/* CTF 1.8 */\n"
+"\n"
+"typealias integer { size = 5; align = 1; signed = false; } := uint5_t;\n"
+"typealias integer { size = 8; align = 8; signed = false; } := uint8_t;\n"
+"typealias integer { size = 32; align = 8; signed = false; } := 
uint32_t;\n"
+"typealias integer { size = 64; align = 8; signed = false; } := 
uint64_t;\n"
+"typealias integer { size = 64; align = 8; signed = false; } := 
unsigned long;\n";

+
 void generate_metadata(){
-  FILE *metadata = fopen("metadata","w");
+  FILE *file = fopen("metadata","w");
   assert( metadata !=  NULL );

-  fprintf(metadata, "/* CTF 1.8 */\n\n");
-  fprintf(metadata, "typealias integer { size = 5; align = 1; signed = 
false; } := uint5_t;\

+  fwrite( metadata, sizeof( metadata ), 1, file );

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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> Could you please move the const metadata content to as few as possible
>
> static const metadata_xyz[] = "...
> ...
> ...";
>
> variables and write them with fwrite().
>
Sorry. I didn't get which part of the metadata you want to move. Are you
talking about typedef?

>
> >
> > Is there any coding style guideline mentioned somewhere to follow for
> > rtems-tools?
>
> This file should follow the RTEMS style:
>
> https://docs.rtems.org/branches/master/eng/coding.html

Thanks. I think first we should work on code optimization.


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

- Am 7. Aug 2019 um 17:53 schrieb Ravindra Kumar Meena rmeena...@gmail.com:

> Metadata cleanup:
> https://github.com/rmeena840/rtems-tools/commit/6eb069cbf6639653a7df3b183a86a58f4da8cdbd
> 
> Generated metadata in client-side:
> https://github.com/rmeena840/rtems-tools/commit/1e07b1ea3bb334ee56b142f08659869576e76db8
> 
> Have a look.

Could you please move the const metadata content to as few as possible

static const metadata_xyz[] = "...
...
...";

variables and write them with fwrite().

> 
> Is there any coding style guideline mentioned somewhere to follow for
> rtems-tools?

This file should follow the RTEMS style:

https://docs.rtems.org/branches/master/eng/coding.html
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

Metadata cleanup:
https://github.com/rmeena840/rtems-tools/commit/6eb069cbf6639653a7df3b183a86a58f4da8cdbd

Generated metadata in client-side:
https://github.com/rmeena840/rtems-tools/commit/1e07b1ea3bb334ee56b142f08659869576e76db8

Have a look.

Is there any coding style guideline mentioned somewhere to follow for
rtems-tools?

>

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

Code Cleanup:
https://github.com/rmeena840/rtems-tools/commit/f19ec63810347f6e532e13b1fb27002554344d3f



-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

- Am 6. Aug 2019 um 17:30 schrieb Ravindra Kumar Meena rmeena...@gmail.com:

>>
>> > I think this can be the right way to check bound access.
>> >
>> https://github.com/rmeena840/rtems-tools/commit/81bf2a9b9e57e7911d519c4719c5126e29a7adbe
>>
>> No, the API classes are 1, 2, and 3. The indices into the table must be
>> 0, 1, and 2. Don't add asserts in this path. Ignore items which have
>> unexpected values.
>>
> Okay API is always returned in the range [ 1, 3 ]. Decrementing it by one
> should be safe then.
> https://github.com/rmeena840/rtems-tools/commit/8ff97b38970595f507e23f2a9a6e397ae1f70bb9

The converter program should not exhibit undefined behaviour due to invalid 
input. Lets suppose item->data is zero, what happens then?

Another issue is that your code violates the DRY principle:

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > I think this can be the right way to check bound access.
> >
> https://github.com/rmeena840/rtems-tools/commit/81bf2a9b9e57e7911d519c4719c5126e29a7adbe
>
> No, the API classes are 1, 2, and 3. The indices into the table must be
> 0, 1, and 2. Don't add asserts in this path. Ignore items which have
> unexpected values.
>
Okay API is always returned in the range [ 1, 3 ]. Decrementing it by one
should be safe then.
https://github.com/rmeena840/rtems-tools/commit/8ff97b38970595f507e23f2a9a6e397ae1f70bb9



-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> No, when you emit a sched_switch event in print_item() you replace the
>
> snprintf( item_data_str, sizeof( item_data_str ), "%08"PRIx64,
>
> with a memcpy() from the corresponding thread_names entry.
>
Done.
https://github.com/rmeena840/rtems-tools/commit/6517c7b32f4dc063fd12dce02d5004741588ea28

The babeltrace and Trace Compass can now display event name :) :)


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 06/08/2019 15:14, Ravindra Kumar Meena wrote:

There is another bug here:

size_t api_id = ( ( cctx->thread_id_name[ item->cpu ].thread_id >> 24 )
& 0x7 );

Please make sure that you don't have an out of bounds access. Check the
dimensions of your array against the values you get from the line above.

I think this can be the right way to check bound access.
https://github.com/rmeena840/rtems-tools/commit/81bf2a9b9e57e7911d519c4719c5126e29a7adbe 


No, the API classes are 1, 2, and 3. The indices into the table must be 
0, 1, and 2. Don't add asserts in this path. Ignore items which have 
unexpected values.


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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> There is another bug here:
>
> size_t api_id = ( ( cctx->thread_id_name[ item->cpu ].thread_id >> 24 )
> & 0x7 );
>
> Please make sure that you don't have an out of bounds access. Check the
> dimensions of your array against the values you get from the line above.
>
I think this can be the right way to check bound access.
https://github.com/rmeena840/rtems-tools/commit/81bf2a9b9e57e7911d519c4719c5126e29a7adbe



-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 06/08/2019 13:26, Ravindra Kumar Meena wrote:

 > Yes, I tried that also. I can't see the 8 char for multiple
 > RTEMS_RECORD_THREAD_NAME in print_item(). Still, I tried to
follow the
 > previously mentioned algorithm.
 >
 >

https://github.com/rmeena840/rtems-tools/commit/33c217642e36b91926dfd823e5b3b59974790084

The code is more complicated than necessary, but it looks mostly all
right.

All variables are defined inside if()..else() scope. It can be made easy 
if we use global variables. You asked once not to use global variables. 
So I did in this way.



Setting

+        cctx->thread_id_name[ item->cpu ].name_index = 0;

if the name_index was 1, is wrong. You have to increment it.

Done
https://github.com/rmeena840/rtems-tools/commit/8ceb3ccb97422044fb30b3c562fc736cf0686d48 


There is another bug here:

size_t api_id = ( ( cctx->thread_id_name[ item->cpu ].thread_id >> 24 ) 
& 0x7 );


Please make sure that you don't have an out of bounds access. Check the 
dimensions of your array against the values you get from the line above.


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

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 06/08/2019 13:41, Ravindra Kumar Meena wrote:

 > Done
 >

https://github.com/rmeena840/rtems-tools/commit/8ceb3ccb97422044fb30b3c562fc736cf0686d48


Ok, good. Now please use this table to populate the thread names in the
sched_switch event.


Do we have to populate it at the end of the file when print_item() has 
done its job?
And this table is not CPU specific so I am not sure in which CPU file 
should I populate it?


No, when you emit a sched_switch event in print_item() you replace the

snprintf( item_data_str, sizeof( item_data_str ), "%08"PRIx64,

with a memcpy() from the corresponding thread_names entry.

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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > Done
> >
> https://github.com/rmeena840/rtems-tools/commit/8ceb3ccb97422044fb30b3c562fc736cf0686d48
>
> Ok, good. Now please use this table to populate the thread names in the
> sched_switch event.
>

Do we have to populate it at the end of the file when print_item() has done
its job?
And this table is not CPU specific so I am not sure in which CPU file
should I populate it?


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 06/08/2019 13:26, Ravindra Kumar Meena wrote:

 > Yes, I tried that also. I can't see the 8 char for multiple
 > RTEMS_RECORD_THREAD_NAME in print_item(). Still, I tried to
follow the
 > previously mentioned algorithm.
 >
 >

https://github.com/rmeena840/rtems-tools/commit/33c217642e36b91926dfd823e5b3b59974790084

The code is more complicated than necessary, but it looks mostly all
right.

All variables are defined inside if()..else() scope. It can be made easy 
if we use global variables. You asked once not to use global variables. 
So I did in this way.


For now this is all right, we will work on optimizations once the thread 
names show up in the Trace Compass.



Setting

+        cctx->thread_id_name[ item->cpu ].name_index = 0;

if the name_index was 1, is wrong. You have to increment it.

Done
https://github.com/rmeena840/rtems-tools/commit/8ceb3ccb97422044fb30b3c562fc736cf0686d48 


Ok, good. Now please use this table to populate the thread names in the 
sched_switch event.


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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > Yes, I tried that also. I can't see the 8 char for multiple
> > RTEMS_RECORD_THREAD_NAME in print_item(). Still, I tried to follow the
> > previously mentioned algorithm.
> >
> >
> https://github.com/rmeena840/rtems-tools/commit/33c217642e36b91926dfd823e5b3b59974790084
>
> The code is more complicated than necessary, but it looks mostly all right.
>
All variables are defined inside if()..else() scope. It can be made easy if
we use global variables. You asked once not to use global variables. So I
did in this way.

>
> Setting
>
> +cctx->thread_id_name[ item->cpu ].name_index = 0;
>
> if the name_index was 1, is wrong. You have to increment it.
>
Done
https://github.com/rmeena840/rtems-tools/commit/8ceb3ccb97422044fb30b3c562fc736cf0686d48



-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 06/08/2019 12:50, Ravindra Kumar Meena wrote:

Have a look at the documentation of printf
(http://www.cplusplus.com/reference/cstdio/printf/).
The format specifier "%lx" refers to unsigned long int which is most
likely a 32bit integer on your machine.
So it will only read 4 bytes regardless of how many are stored in
memory.
Try using either "%llx" or PRIx64 format specifier for printing
64-bit numbers.

Yes, I tried that also. I can't see the 8 char for multiple 
RTEMS_RECORD_THREAD_NAME in print_item(). Still, I tried to follow the 
previously mentioned algorithm.


https://github.com/rmeena840/rtems-tools/commit/33c217642e36b91926dfd823e5b3b59974790084


The code is more complicated than necessary, but it looks mostly all right.

Setting

+cctx->thread_id_name[ item->cpu ].name_index = 0;

if the name_index was 1, is wrong. You have to increment it.

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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> Have a look at the documentation of printf (
> http://www.cplusplus.com/reference/cstdio/printf/).
> The format specifier "%lx" refers to unsigned long int which is most
> likely a 32bit integer on your machine.
> So it will only read 4 bytes regardless of how many are stored in memory.
> Try using either "%llx" or PRIx64 format specifier for printing 64-bit
> numbers.
>
Yes, I tried that also. I can't see the 8 char for multiple
RTEMS_RECORD_THREAD_NAME in print_item(). Still, I tried to follow the
previously mentioned algorithm.

https://github.com/rmeena840/rtems-tools/commit/33c217642e36b91926dfd823e5b3b59974790084



-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

AW: GSoC Project | Basic Support for Trace Compass

[Jan.Sommer]

> -Ursprüngliche Nachricht-
> Von: devel [mailto:devel-boun...@rtems.org] Im Auftrag von Ravindra
> Kumar Meena
> Gesendet: Dienstag, 6. August 2019 10:59
> An: Sebastian Huber
> Cc: rtems-de...@rtems.org
> Betreff: Re: GSoC Project | Basic Support for Trace Compass
> 
>   e.g.
>   > Object Index: 30
>   > Name: 36697773
>   > Name: 71206b73
> 
>   On a 64-bit target, the data field contains 8 chars. Why do you only
>   print 4 chars here?
> 
> 
> This is what I am getting in Konsole output when I did this:
> 
> printf("Name: %lx\n",item->data);
> 
> May be full information is not received in client-side.
> 
> 
Have a look at the documentation of printf 
(http://www.cplusplus.com/reference/cstdio/printf/).
The format specifier "%lx" refers to unsigned long int which is most likely a 
32bit integer on your machine.
So it will only read 4 bytes regardless of how many are stored in memory. 
Try using either "%llx" or PRIx64 format specifier for printing 64-bit numbers.


> --
> 
> Ravindra Kumar Meena,
> B. Tech. Computer Science and Engineering,
> 
> Indian Institute of Technology (Indian School of Mines)
> <https://www.iitism.ac.in/> , Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> e.g.
> > Object Index: 30
> > Name: 36697773
> > Name: 71206b73
>
> On a 64-bit target, the data field contains 8 chars. Why do you only
> print 4 chars here?
>
This is what I am getting in Konsole output when I did this:

printf("Name: %lx\n",item->data);

May be full information is not received in client-side.


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 06/08/2019 10:26, Ravindra Kumar Meena wrote:

Thread name is in the right order now.

Yes, the order is all right, but you still overwrite thread names which
consist of multiple events.

I am not able to figure out how overwritten is happening. In my code 
overwritten case is handled by:


if( cctx->thread_names[ api_id ][ thread_id ][ i ] == 0x00 )


This check is wrong, you should not rely on previous content of this 
buffer. If you see the first RTEMS_RECORD_THREAD_NAME event, then you 
should overwrite the complete 16 chars with 0 and fill it up with the 
new content. In the first RTEMS_RECORD_THREAD_NAME event, you fill up 
chars 0..7, in the second 8..15.  For this you have to store somehow 
thread_id_name on which position you are, e.g.


typedef struct thread_id_name{
  uint64_t thread_id;
  size_t name_index;
} thread_id_name;

Set name_index to 0 if you see a RTEMS_RECORD_THREAD_ID event. Increment 
it by one after you processed a RTEMS_RECORD_THREAD_NAME event.




The above line means that write value only if a NULL char position is 
available. When we receive first RTEMS_RECORD_THREAD_NAME the loop will 
start filling the NULL char position from the beginning and when second 
RTEMS_RECORD_THREAD_NAME is received then NULL char are filled just 
after the previously filled char position.


e.g.
Object Index: 30
Name: 36697773
Name: 71206b73


On a 64-bit target, the data field contains 8 chars. Why do you only 
print 4 chars here?




After the first iteration of for loop, the 16 size char array will be:
{s,w,i,6,0,0,0,0,0,0,0,0,0,0,0,0}

After the second iteration of for loop, the 16 size char array will be:
{s,w,i,6,s,k, ,q,0,0,0,0,0,0,0,0}

For this decode, the value will be "swi6sk q". Right? This is exactly 
what I am getting in Konsole.


For this task you should end up with "swi6: task queu".

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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> Thread name is in the right order now.
>
> Yes, the order is all right, but you still overwrite thread names which
> consist of multiple events.
>
I am not able to figure out how overwritten is happening. In my code
overwritten case is handled by:

if( cctx->thread_names[ api_id ][ thread_id ][ i ] == 0x00 )

The above line means that write value only if a NULL char position is
available. When we receive first RTEMS_RECORD_THREAD_NAME the loop will
start filling the NULL char position from the beginning and when second
RTEMS_RECORD_THREAD_NAME is received then NULL char are filled just after
the previously filled char position.

e.g.
Object Index: 30
Name: 36697773
Name: 71206b73

After the first iteration of for loop, the 16 size char array will be:
{s,w,i,6,0,0,0,0,0,0,0,0,0,0,0,0}

After the second iteration of for loop, the 16 size char array will be:
{s,w,i,6,s,k, ,q,0,0,0,0,0,0,0,0}

For this decode, the value will be "swi6sk q". Right? This is exactly what
I am getting in Konsole.


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 06/08/2019 08:34, Ravindra Kumar Meena wrote:

Object Index: 75 Name: SHLL

Thread name is in the right order now.


Yes, the order is all right, but you still overwrite thread names which 
consist of multiple events.


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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > The decoded thread name is "swi6: task queu"
> >
> > For each RTEMS_RECORD_THREAD_NAME event you start the loop at i == 0, so
> > you overwrite your previous data.
>
> The thread name encoding was difficult to decode. I changed it like this:
>
>
> https://git.rtems.org/rtems/commit/?id=cc91fae43a71ccb5f47fa7ed179dd86c53e290ae
>
> I pushed new raw data to the repository.
>
Okay.

This is how Konsole output looks like:
Object Index: 1 Name: IDLE
Object Index: 2 Name: IDLE
Object Index: 3 Name: IDLE
Object Index: 4 Name: IDLE
Object Index: 5 Name: IDLE
Object Index: 6 Name: IDLE
Object Index: 7 Name: IDLE
Object Index: 8 Name: IDLE
Object Index: 9 Name: IDLE
Object Index: 10 Name: IDLE
Object Index: 11 Name: IDLE
Object Index: 12 Name: IDLE
Object Index: 13 Name: IDLE
Object Index: 14 Name: IDLE
Object Index: 15 Name: IDLE
Object Index: 16 Name: IDLE
Object Index: 17 Name: IDLE
Object Index: 18 Name: IDLE
Object Index: 19 Name: IDLE
Object Index: 20 Name: IDLE
Object Index: 21 Name: IDLE
Object Index: 22 Name: IDLE
Object Index: 23 Name: IDLE
Object Index: 24 Name: IDLE
Object Index: 1 Name: UI1
Object Index: 2 Name: BSWP
Object Index: 3 Name: BRDA
Object Index: 4 Name: MDIA
Object Index: 5 Name: TIME
Object Index: 6 Name: IRQS
Object Index: 7 Name: IRQS
Object Index: 8 Name: IRQS
Object Index: 9 Name: IRQS
Object Index: 10 Name: IRQS
Object Index: 11 Name: IRQS
Object Index: 12 Name: IRQS
Object Index: 13 Name: IRQS
Object Index: 14 Name: IRQS
Object Index: 15 Name: IRQS
Object Index: 16 Name: IRQS
Object Index: 17 Name: IRQS
Object Index: 18 Name: IRQS
Object Index: 19 Name: IRQS
Object Index: 20 Name: IRQS
Object Index: 21 Name: IRQS
Object Index: 22 Name: IRQS
Object Index: 23 Name: IRQS
Object Index: 24 Name: IRQS
Object Index: 25 Name: IRQS
Object Index: 26 Name: IRQS
Object Index: 27 Name: IRQS
Object Index: 28 Name: IRQS
Object Index: 29 Name: IRQS
Object Index: 30 Name: swi6
Object Index: 30 Name: swi6sk q
Object Index: 31 Name: conf
Object Index: 32 Name: swi5
Object Index: 32 Name: swi5st t
Object Index: 33 Name: kque
Object Index: 33 Name: kquetx t
Object Index: 34 Name: thre
Object Index: 34 Name: threaskq
Object Index: 35 Name: swi6
Object Index: 35 Name: swi6ant
Object Index: 36 Name: swi1
Object Index: 36 Name: swi1tisr
Object Index: 37 Name: soft
Object Index: 37 Name: soft0
Object Index: 38 Name: DHCP
Object Index: 39 Name: PRTL
Object Index: 40 Name: PSTA
Object Index: 41 Name: PRTL
Object Index: 42 Name: PSTA
Object Index: 43 Name: FTPa
Object Index: 44 Name: FTPb
Object Index: 45 Name: FTPc
Object Index: 46 Name: FTPd
Object Index: 47 Name: FTPe
Object Index: 48 Name: FTPf
Object Index: 49 Name: FTPg
Object Index: 50 Name: FTPh
Object Index: 51 Name: FTPi
Object Index: 52 Name: FTPj
Object Index: 53 Name: FTPk
Object Index: 54 Name: FTPl
Object Index: 55 Name: FTPm
Object Index: 56 Name: FTPn
Object Index: 57 Name: FTPo
Object Index: 58 Name: FTPp
Object Index: 59 Name: FTPq
Object Index: 60 Name: FTPr
Object Index: 61 Name: FTPs
Object Index: 62 Name: FTPt
Object Index: 63 Name: FTPu
Object Index: 64 Name: FTPv
Object Index: 65 Name: FTPw
Object Index: 66 Name: FTPx
Object Index: 67 Name: FTPD
Object Index: 68 Name: TNTa
Object Index: 69 Name: TNTb
Object Index: 70 Name: TNTc
Object Index: 71 Name: TNTd
Object Index: 72 Name: TNTe
Object Index: 73 Name: TNTD
Object Index: 74 Name: RCRD
Object Index: 75 Name: SHLL

Thread name is in the right order now.


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 06/08/2019 07:27, Sebastian Huber wrote:

On 06/08/2019 07:20, Ravindra Kumar Meena wrote:

 >
 > Have made changes. Simplified the code.
 >

https://github.com/rmeena840/rtems-tools/commit/9e09be40db85e4e903118f8eb5eb1ea1e41baf46 



    Yes, this moves into the right direction:

    +      for( i = 0; i < THREAD_NAME_SIZE - 1; i++ ){
    +        if( cctx->thread_names[ api_id ][ thread_id ][ i ] == 
0x00 ){

    +          cctx->thread_names[ api_id ][ thread_id ][ i ] = (
    thread_name  & 0xff );
    +          thread_name = ( thread_name >> 8 );
    +        }
    +      }

    On a 32-bit target you may get up to 4 RTEMS_RECORD_THREAD_NAME 
events,
    on a 64-bit target you may get up to 2 RTEMS_RECORD_THREAD_NAME 
events.


    Your code overwrites the data from previous name events and only the
    last one is visible. You have to add the name index (i) to
    thread_id_name.

The overwrites thing is taken care of by :
if( cctx->thread_names[ api_id ][ thread_id ][ i ] == 0x00 )

If thread_name is received for the same api_id and thread_id then it 
will write only in empty char position.


For example this sequence of events is generated in case the thread name 
exceeds 8 chars:


THREAD_ID:a01001e
THREAD_NAME:737769363a207461
THREAD_NAME:736b2071756575

The decoded thread name is "swi6: task queu"

For each RTEMS_RECORD_THREAD_NAME event you start the loop at i == 0, so 
you overwrite your previous data.


The thread name encoding was difficult to decode. I changed it like this:

https://git.rtems.org/rtems/commit/?id=cc91fae43a71ccb5f47fa7ed179dd86c53e290ae

I pushed new raw data to the repository.

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

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 06/08/2019 07:20, Ravindra Kumar Meena wrote:

 >
 > Have made changes. Simplified the code.
 >

https://github.com/rmeena840/rtems-tools/commit/9e09be40db85e4e903118f8eb5eb1ea1e41baf46

Yes, this moves into the right direction:

+      for( i = 0; i < THREAD_NAME_SIZE - 1; i++ ){
+        if( cctx->thread_names[ api_id ][ thread_id ][ i ] == 0x00 ){
+          cctx->thread_names[ api_id ][ thread_id ][ i ] = (
thread_name  & 0xff );
+          thread_name = ( thread_name >> 8 );
+        }
+      }

On a 32-bit target you may get up to 4 RTEMS_RECORD_THREAD_NAME events,
on a 64-bit target you may get up to 2 RTEMS_RECORD_THREAD_NAME events.

Your code overwrites the data from previous name events and only the
last one is visible. You have to add the name index (i) to
thread_id_name.

The overwrites thing is taken care of by :
if( cctx->thread_names[ api_id ][ thread_id ][ i ] == 0x00 )

If thread_name is received for the same api_id and thread_id then it 
will write only in empty char position.


For example this sequence of events is generated in case the thread name 
exceeds 8 chars:


THREAD_ID:a01001e
THREAD_NAME:737769363a207461
THREAD_NAME:736b2071756575

The decoded thread name is "swi6: task queu"

For each RTEMS_RECORD_THREAD_NAME event you start the loop at i == 0, so 
you overwrite your previous data.


I checked the value with the provided output. The value is the same but 
in reverse order.


It would be good to have the thread names displayed in the right order.

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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> >
> > Have made changes. Simplified the code.
> >
> https://github.com/rmeena840/rtems-tools/commit/9e09be40db85e4e903118f8eb5eb1ea1e41baf46
>
> Yes, this moves into the right direction:
>
> +  for( i = 0; i < THREAD_NAME_SIZE - 1; i++ ){
> +if( cctx->thread_names[ api_id ][ thread_id ][ i ] == 0x00 ){
> +  cctx->thread_names[ api_id ][ thread_id ][ i ] = (
> thread_name  & 0xff );
> +  thread_name = ( thread_name >> 8 );
> +}
> +  }
>
> On a 32-bit target you may get up to 4 RTEMS_RECORD_THREAD_NAME events,
> on a 64-bit target you may get up to 2 RTEMS_RECORD_THREAD_NAME events.
>
> Your code overwrites the data from previous name events and only the
> last one is visible. You have to add the name index (i) to thread_id_name.
>
The overwrites thing is taken care of by :
if( cctx->thread_names[ api_id ][ thread_id ][ i ] == 0x00 )

If thread_name is received for the same api_id and thread_id then it will
write only in empty char position.
I checked the value with the provided output. The value is the same but in
reverse order.


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 06/08/2019 06:37, Ravindra Kumar Meena wrote:

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

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


Yes, this moves into the right direction:

+  for( i = 0; i < THREAD_NAME_SIZE - 1; i++ ){
+if( cctx->thread_names[ api_id ][ thread_id ][ i ] == 0x00 ){
+  cctx->thread_names[ api_id ][ thread_id ][ i ] = ( 
thread_name  & 0xff );

+  thread_name = ( thread_name >> 8 );
+}
+  }

On a 32-bit target you may get up to 4 RTEMS_RECORD_THREAD_NAME events, 
on a 64-bit target you may get up to 2 RTEMS_RECORD_THREAD_NAME events.


Your code overwrites the data from previous name events and only the 
last one is visible. You have to add the name index (i) to thread_id_name.


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

Re: 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.
> > 
> > 
> > 
> >
> > 
> > 
> > 
>
> 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)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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









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

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









-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 05/08/2019 10:12, Ravindra Kumar Meena wrote:

 > In the console output at someplace, I am getting this type of output:
 >
 > THREAD_ID:a01001e
 > THREAD_NAME:737769363a207461
 > THREAD_NAME:736b2071756575
 >
 > Does this mean that the same thread_id have two thread_name? If
so then
 > only one thread_name can be stored in
 > char thread_names[3][65536][THREAD_NAME_SIZE];

No, it means that the thread name is longer than 8 bytes (on a 32-bit
target, it would be 4 bytes), see the loop here:

https://git.rtems.org/rtems/tree/cpukit/libtrace/record/record-userext.c#n54

To get the thread name back from the integers into a char array, you
have to reverse what this loop did.

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.


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

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.


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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > In the console output at someplace, I am getting this type of output:
> >
> > THREAD_ID:a01001e
> > THREAD_NAME:737769363a207461
> > THREAD_NAME:736b2071756575
> >
> > Does this mean that the same thread_id have two thread_name? If so then
> > only one thread_name can be stored in
> > char thread_names[3][65536][THREAD_NAME_SIZE];
>
> No, it means that the thread name is longer than 8 bytes (on a 32-bit
> target, it would be 4 bytes), see the loop here:
>
>
> https://git.rtems.org/rtems/tree/cpukit/libtrace/record/record-userext.c#n54
>
> To get the thread name back from the integers into a char array, you
> have to reverse what this loop did.
>
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
);


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 05/08/2019 06:54, Ravindra Kumar Meena wrote:

*Plan of the week:*
Last week I did some tweak in client program for the idle thread so that 
more details are visible in Trace Compass. I will continue to work on 
the client program and will produce documentation for the same.


In the console output at someplace, I am getting this type of output:

THREAD_ID:a01001e
THREAD_NAME:737769363a207461
THREAD_NAME:736b2071756575

Does this mean that the same thread_id have two thread_name? If so then 
only one thread_name can be stored in

char thread_names[3][65536][THREAD_NAME_SIZE];


No, it means that the thread name is longer than 8 bytes (on a 32-bit 
target, it would be 4 bytes), see the loop here:


https://git.rtems.org/rtems/tree/cpukit/libtrace/record/record-userext.c#n54

To get the thread name back from the integers into a char array, you 
have to reverse what this loop did.


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

GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

*Plan of the week:*
Last week I did some tweak in client program for the idle thread so that
more details are visible in Trace Compass. I will continue to work on the
client program and will produce documentation for the same.

In the console output at someplace, I am getting this type of output:

THREAD_ID:a01001e
THREAD_NAME:737769363a207461
THREAD_NAME:736b2071756575

Does this mean that the same thread_id have two thread_name? If so then
only one thread_name can be stored in
char thread_names[3][65536][THREAD_NAME_SIZE];

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

- Am 4. Aug 2019 um 9:54 schrieb Ravindra Kumar Meena rmeena...@gmail.com:

> We don't really need so many sched_switch events in the metadata. I have
> removed the extra events.
> 
>>
> https://github.com/rmeena840/rtems-tools/commit/61003e8013146acf400a79fb9dea982242f5c6af
> 
> And for the same, I have made changes in the client program.
> 
> https://github.com/rmeena840/rtems-tools/commit/426c2d293f17e3d3150d50a7943a2d22ad382c47
> 
> I checked the output with/without it. The babeltrace and Trace Compass
> displays the same output.

This is a good cleanup. Please remove everything else which is not in line with 
the LTTNG metadata.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

- Am 3. Aug 2019 um 18:16 schrieb Ravindra Kumar Meena rmeena...@gmail.com:

> Now, I can get the [thread_id] and [thread_name] in print_item() but since
> this information is not CPU specific so in which CPU should I store this
> information?

Maybe something like this (please remove your hash table):

diff --git a/misc/record/record-main.c b/misc/record/record-main.c
index 20158fd..2cc3a3c 100644
--- a/misc/record/record-main.c
+++ b/misc/record/record-main.c
@@ -190,12 +190,14 @@ typedef struct event_header_extended {
   uint64_t ns;
 } __attribute__((__packed__)) event_header_extended;
 
+#define THREAD_NAME_SIZE 16
+
 typedef struct switch_event{
-  uint8_t  prev_comm[16];
+  uint8_t  prev_comm[THREAD_NAME_SIZE];
   int32_t  prev_tid;
   int32_t  prev_prio;
   int64_t  prev_state;
-  uint8_t  next_comm[16];
+  uint8_t  next_comm[THREAD_NAME_SIZE];
   int32_t  next_tid;
   int32_t  next_prio;
 } __attribute__((__packed__)) switch_event;
@@ -222,6 +224,14 @@ typedef struct client_context {
   uint64_tcontent_size[ RTEMS_RECORD_CLIENT_MAXIMUM_CPU_COUNT ];
   uint64_tpacket_size[ RTEMS_RECORD_CLIENT_MAXIMUM_CPU_COUNT ];
   switch_out_int  switch_out_int[ RTEMS_RECORD_CLIENT_MAXIMUM_CPU_COUNT ];
+
+  /**
+   * @brief Thread names indexed by API and object index.
+   *
+   * The API indices are 0 for Internal API, 1 for Classic API and 2 for POSIX 
API.
+   */
+  char thread_names[3][65536][THREAD_NAME_SIZE];
+
   map_data*   hashArray[ MAP_SIZE ];
 } client_context;
 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

We don't really need so many sched_switch events in the metadata. I have
removed the extra events.

>
https://github.com/rmeena840/rtems-tools/commit/61003e8013146acf400a79fb9dea982242f5c6af

And for the same, I have made changes in the client program.

https://github.com/rmeena840/rtems-tools/commit/426c2d293f17e3d3150d50a7943a2d22ad382c47

I checked the output with/without it. The babeltrace and Trace Compass
displays the same output.

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

Now, I can get the [thread_id] and [thread_name] in print_item() but since
this information is not CPU specific so in which CPU should I store this
information?

>

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> Yes, prev_state is the state of the previous thread. See my other email
> which mentions the swapper. In the Trace Compass code you see that a tid ==
> 0 is used to detect an idle CPU.
>
> We have to set prev_tid to 0 if the previous thread is an idle thread,
> likewise for next_tid if the next thread is an idle thread.
>
Okay. I have added the idle thread condition in next_tid.
https://github.com/rmeena840/rtems-tools/commit/4e767dd71a7dc402edf7ac5e1ed78cdb49e09607

Have a look.


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

- Am 3. Aug 2019 um 9:18 schrieb Ravindra Kumar Meena rmeena...@gmail.com:

>>
>>
>> Yes, this is similar to what I see. I don't think this is what we want.
>> The 09.. are all idle threads. What I want is something similar to the
>> LTTNG output, see attached screen shot.
>>
> 
> Are you talking about CPU states the Trace Compass has?
> --CPU states
>  --IRQ 34
>  --SOFT_IRQ 1 Timer
>  --SOFT IRQ 7 Schedular
>  --SOFT IRQ 9 RCU data

No, we don't have support for interrupts yet. We can only support the states 
"usermode" and "idle".

> 
>>
>> It seems the prev_state is actually the state of the new thread. Doesn't
>> really make sense to me. Could you please clarify this with the LTTNG
>> mailing list?
>>
> In the lttng response, I shared with you previously.
> https://lists.lttng.org/pipermail/lttng-dev/2019-July/029121.html
> 
> They had mentioned that
> "My guess would be that prev_state is the previous state of the thread (TID)
> "
> 
> So I think prev_state is for prev_tid only.

Yes, prev_state is the state of the previous thread. See my other email which 
mentions the swapper. In the Trace Compass code you see that a tid == 0 is used 
to detect an idle CPU.

We have to set prev_tid to 0 if the previous thread is an idle thread, likewise 
for next_tid if the next thread is an idle thread.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
>
> Yes, this is similar to what I see. I don't think this is what we want.
> The 09.. are all idle threads. What I want is something similar to the
> LTTNG output, see attached screen shot.
>

Are you talking about CPU states the Trace Compass has?
--CPU states
  --IRQ 34
  --SOFT_IRQ 1 Timer
  --SOFT IRQ 7 Schedular
  --SOFT IRQ 9 RCU data

>
> It seems the prev_state is actually the state of the new thread. Doesn't
> really make sense to me. Could you please clarify this with the LTTNG
> mailing list?
>
In the lttng response, I shared with you previously.
https://lists.lttng.org/pipermail/lttng-dev/2019-July/029121.html

They had mentioned that
"My guess would be that prev_state is the previous state of the thread (TID)
"

So I think prev_state is for prev_tid only.


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

- Am 2. Aug 2019 um 19:14 schrieb Ravindra Kumar Meena rmeena...@gmail.com:

>>
>> It seems that there are some special cases for the swapper which has a
>> tid of 0. Could you please adjust the code so that idle threads get a
>> tid of 0.
>>
> 
> Done. The graph now has more detail now. I have attached the screenshot.
> Earlier there was a straight line in the beginning. The histogram graph has
> also changed.
> https://github.com/rmeena840/rtems-tools/commit/12cc758befee3e415d0f133288aa7af04ee1572e

You have to set the tid to zero in each of the two fields if you have a 
corresponding idle thread.___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > I did following thing in print_item() but nothing is shown in the console
> > output:
> >
> >  if(item->event == RTEMS_RECORD_THREAD_ID){
> >printf("this thing is present\n");
> >  }
>
>
> I checked in a fix for this problem.
>
Thanks a lot. It worked.


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

- Am 2. Aug 2019 um 18:09 schrieb Ravindra Kumar Meena rmeena...@gmail.com:

>>
>> I just checked out the original version with some minor edits. This output
>> should be enough to figure out how it works.
>>
>> You have to extend the switch case in print_item() to check for
>> RTEMS_RECORD_THREAD_ID and RTEMS_RECORD_THREAD_NAME. The thread name events
>> contain the bytes in the data field. For the encoding see:
> 
> Thanks for the clarification.
> 
> I tried to check if we are getting RTEMS_RECORD_THREAD_ID in prtin_item()
> or not.
> 
> I did following thing in print_item() but nothing is shown in the console
> output:
> 
>  if(item->event == RTEMS_RECORD_THREAD_ID){
>printf("this thing is present\n");
>  }


I checked in a fix for this problem.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> I just checked out the original version with some minor edits. This output
> should be enough to figure out how it works.
>
> You have to extend the switch case in print_item() to check for
> RTEMS_RECORD_THREAD_ID and RTEMS_RECORD_THREAD_NAME. The thread name events
> contain the bytes in the data field. For the encoding see:

Thanks for the clarification.

I tried to check if we are getting RTEMS_RECORD_THREAD_ID in prtin_item()
or not.

I did following thing in print_item() but nothing is shown in the console
output:

  if(item->event == RTEMS_RECORD_THREAD_ID){
printf("this thing is present\n");
  }



-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

- Am 2. Aug 2019 um 17:25 schrieb Ravindra Kumar Meena rmeena...@gmail.com:

>>
>> The task name information is already in qoriq_e6500_64.bin:
>>
>> *:0:VERSION:5
>> *:0:PROCESSOR_MAXIMUM:17
>> *:0:PER_CPU_COUNT:1
>> *:0:FREQUENCY:59682f00
>> *:0:THREAD_ID:9010001
>> *:0:THREAD_NAME:49444c45
[...]
>>
> 
> Please post the new output of the file you pushed on my workplace.
> How do you generate this output?

I just checked out the original version with some minor edits. This output 
should be enough to figure out how it works.

You have to extend the switch case in print_item() to check for 
RTEMS_RECORD_THREAD_ID and RTEMS_RECORD_THREAD_NAME. The thread name events 
contain the bytes in the data field. For the encoding see:

https://git.rtems.org/rtems/tree/cpukit/libtrace/record/record-userext.c#n54

On a 32-bit target you get 4 characters per data field, on a 64-bit target you 
get 8 characters per data field.

If you really want to keep your hash map, I would add unit tests for this piece 
of code. However, since the number of thread objects is limited to 3 * 2**16 in 
RTEMS, you don't need a hash map. Keep it simple, this program is just a proof 
of concept.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> The task name information is already in qoriq_e6500_64.bin:
>
> *:0:VERSION:5
> *:0:PROCESSOR_MAXIMUM:17
> *:0:PER_CPU_COUNT:1
> *:0:FREQUENCY:59682f00
> *:0:THREAD_ID:9010001
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:9010002
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:9010003
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:9010004
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:9010005
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:9010006
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:9010007
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:9010008
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:9010009
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:901000a
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:901000b
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:901000c
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:901000d
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:901000e
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:901000f
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:9010010
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:9010011
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:9010012
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:9010013
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:9010014
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:9010015
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:9010016
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:9010017
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:9010018
> *:0:THREAD_NAME:49444c45
> *:0:THREAD_ID:a010001
> *:0:THREAD_NAME:55493120
> *:0:THREAD_ID:a010002
> *:0:THREAD_NAME:42535750
> *:0:THREAD_ID:a010003
> *:0:THREAD_NAME:42524441
> *:0:THREAD_ID:a010004
> *:0:THREAD_NAME:4d444941
> *:0:THREAD_ID:a010005
> *:0:THREAD_NAME:54494d45
> *:0:THREAD_ID:a010006
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a010007
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a010008
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a010009
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a01000a
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a01000b
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a01000c
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a01000d
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a01000e
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a01000f
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a010010
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a010011
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a010012
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a010013
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a010014
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a010015
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a010016
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a010017
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a010018
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a010019
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a01001a
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a01001b
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a01001c
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a01001d
> *:0:THREAD_NAME:49525153
> *:0:THREAD_ID:a01001e
> *:0:THREAD_NAME:737769363a207461
> *:0:THREAD_NAME:736b2071756575
> *:0:THREAD_ID:a01001f
> *:0:THREAD_NAME:636f6e6669675f30
> *:0:THREAD_ID:a010020
> *:0:THREAD_NAME:737769353a206661
> *:0:THREAD_NAME:7374207461736b
> *:0:THREAD_ID:a010021
> *:0:THREAD_NAME:6b71756575655f63
> *:0:THREAD_NAME:7478207461736b
> *:0:THREAD_ID:a010022
> *:0:THREAD_NAME:7468726561642074
> *:0:THREAD_NAME:61736b71
> *:0:THREAD_ID:a010023
> *:0:THREAD_NAME:737769363a204769
> *:0:THREAD_NAME:616e7420746173
> *:0:THREAD_ID:a010024
> *:0:THREAD_NAME:737769313a206e65
> *:0:THREAD_NAME:746973722030
> *:0:THREAD_ID:a010025
> *:0:THREAD_NAME:736f66746972715f
> *:0:THREAD_NAME:30
> *:0:THREAD_ID:a010026
> *:0:THREAD_NAME:44484350
> *:0:THREAD_ID:a010027
> *:0:THREAD_NAME:5052544c
> *:0:THREAD_ID:a010028
> *:0:THREAD_NAME:50535441
> *:0:THREAD_ID:a010029
> *:0:THREAD_NAME:5052544c
> *:0:THREAD_ID:a01002a
> *:0:THREAD_NAME:50535441
> *:0:THREAD_ID:a01002b
> *:0:THREAD_NAME:46545061
> *:0:THREAD_ID:a01002c
> *:0:THREAD_NAME:46545062
> *:0:THREAD_ID:a01002d
> *:0:THREAD_NAME:46545063
> *:0:THREAD_ID:a01002e
> *:0:THREAD_NAME:46545064
> *:0:THREAD_ID:a01002f
> *:0:THREAD_NAME:46545065
> *:0:THREAD_ID:a010030
> *:0:THREAD_NAME:46545066
> *:0:THREAD_ID:a010031
> *:0:THREAD_NAME:46545067
> *:0:THREAD_ID:a010032
> *:0:THREAD_NAME:46545068
> *:0:THREAD_ID:a010033
> *:0:THREAD_NAME:46545069
> *:0:THREAD_ID:a010034
> *:0:THREAD_NAME:4654506a
> *:0:THREAD_ID:a010035
> *:0:THREAD_NAME:4654506b
> *:0:THREAD_ID:a010036
> *:0:THREAD_NAME:4654506c
> *:0:THREAD_ID:a010037
> *:0:THREAD_NAME:4654506d
> *:0:THREAD_ID:a010038
> *:0:THREAD_NAME:4654506e
> *:0:THREAD_ID:a010039
> *:0:THREAD_NAME:4654506f
> *:0:THREAD_ID:a01003a
> *:0:THREAD_NAME:46545070
> *:0:THREAD_ID:a01003b
> *:0:THREAD_NAME:46545071
> *:0:THREAD_ID:a01003c
> *:0:THREAD_NAME:46545072
> *:0:THREAD_ID:a01003d
> *:0:THREAD_NAME:46545073
> *:0:THREAD_ID:a01003e
> *:0:THREAD_NAME:46545074
> *:0:THREAD_ID:a01003f
> *:0:THREAD_NAME:46545075
> *:0:THREAD_ID:a010040
> *:0:THREAD_NAME:46545076
> *:0:THREAD_ID:a010041
> *:0:THREAD_NAME:46545077
> *:0:THREAD_ID:a010042

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 02/08/2019 10:45, Sebastian Huber wrote:

On 02/08/2019 10:38, Sebastian Huber wrote:

On 31/07/2019 08:30, Ravindra Kumar Meena wrote:
 > The bit field is documented in the manual. I would simplify 
this to:

 >
 > cctx->switch_out_int[ item->cpu ].prev_state = ( ( ( item->data
 >> 24 )
 > & 0x7 ) == 1 ) ? TASK_IDLE : TASK_RUNNING;

    Did you check how the Trace Compass behaviour changed with this?

Yes. I imported the trace on Trace Compass. The CPU 5 Threads and CPU 
5 States lines are straight in the beginning because there is no 
change in the cpu_id. At the end of the trace, there is a lot of 
change in cpu_id due to which Trace Compass shows other CPU thread 
and state lines.


I have attached the screenshot of trace compass. Have a look.


Yes, this is similar to what I see. I don't think this is what we 
want. The 09.. are all idle threads. What I want is something similar 
to the LTTNG output, see attached screen shot.


It seems the prev_state is actually the state of the new thread. 
Doesn't really make sense to me. Could you please clarify this with 
the LTTNG mailing list?


It seems that there are some special cases for the swapper which has a 
tid of 0. Could you please adjust the code so that idle threads get a 
tid of 0.


Yes, this seems to achieve what we need. I updated the raw data so that 
more task switches are included.


With your current version the program doesn't terminate, I guess there 
is a bug in your new hash table code.


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

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 02/08/2019 10:38, Sebastian Huber wrote:

On 31/07/2019 08:30, Ravindra Kumar Meena wrote:
 > The bit field is documented in the manual. I would simplify 
this to:

 >
 > cctx->switch_out_int[ item->cpu ].prev_state = ( ( ( item->data
 >> 24 )
 > & 0x7 ) == 1 ) ? TASK_IDLE : TASK_RUNNING;

    Did you check how the Trace Compass behaviour changed with this?

Yes. I imported the trace on Trace Compass. The CPU 5 Threads and CPU 
5 States lines are straight in the beginning because there is no 
change in the cpu_id. At the end of the trace, there is a lot of 
change in cpu_id due to which Trace Compass shows other CPU thread and 
state lines.


I have attached the screenshot of trace compass. Have a look.


Yes, this is similar to what I see. I don't think this is what we want. 
The 09.. are all idle threads. What I want is something similar to the 
LTTNG output, see attached screen shot.


It seems the prev_state is actually the state of the new thread. Doesn't 
really make sense to me. Could you please clarify this with the LTTNG 
mailing list?


It seems that there are some special cases for the swapper which has a 
tid of 0. Could you please adjust the code so that idle threads get a 
tid of 0.


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

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 02/08/2019 08:29, Ravindra Kumar Meena wrote:

Why do you implement a hash map on your own? I would have renamed the
record-main.c to record-main.cc and use std::map for example or
something from boost.

I tried this but this generates a lot of warnings from the same file and 
other files also. Converting from C to another language requires the 
resolution of each warning. That's why I implemented it.


Ok, since the RTEMS object count is limited to 65536 and we have only 
three APIs, I would simply use one big table for the id to name lookup.





The threads can execute on every CPU, so this information must not be
CPU-specific.

Okay


What do you want to do with this line?

map_insert( cctx->map_per_cpu[ item->cpu ].hashArray, item->data,
rtems_record_event_text( item->event ));

We need thread names, not the text of a record event.

Okay. How do I get thread name in client-side?


Yes, this is your task.




To figure out how the thread names are sent from the target to your
client you have to look at this patch:


https://git.rtems.org/rtems/commit/?id=036717eda4de437336a86ca67253b7e32f67463c

If you don't understand this patch, then please ask.

How do I access the thread name information in client-side? Will it be 
only accessible through the TCP command

./build/misc/rtems-record -H 169.254.23.78 -p 1234 | head
or
./build/misc/rtems-record --input misc/record/qoriq_e6500_64.bin | head?


The task name information is already in qoriq_e6500_64.bin:

*:0:VERSION:5
*:0:PROCESSOR_MAXIMUM:17
*:0:PER_CPU_COUNT:1
*:0:FREQUENCY:59682f00
*:0:THREAD_ID:9010001
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:9010002
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:9010003
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:9010004
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:9010005
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:9010006
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:9010007
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:9010008
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:9010009
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:901000a
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:901000b
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:901000c
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:901000d
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:901000e
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:901000f
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:9010010
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:9010011
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:9010012
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:9010013
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:9010014
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:9010015
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:9010016
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:9010017
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:9010018
*:0:THREAD_NAME:49444c45
*:0:THREAD_ID:a010001
*:0:THREAD_NAME:55493120
*:0:THREAD_ID:a010002
*:0:THREAD_NAME:42535750
*:0:THREAD_ID:a010003
*:0:THREAD_NAME:42524441
*:0:THREAD_ID:a010004
*:0:THREAD_NAME:4d444941
*:0:THREAD_ID:a010005
*:0:THREAD_NAME:54494d45
*:0:THREAD_ID:a010006
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a010007
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a010008
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a010009
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a01000a
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a01000b
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a01000c
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a01000d
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a01000e
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a01000f
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a010010
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a010011
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a010012
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a010013
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a010014
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a010015
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a010016
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a010017
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a010018
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a010019
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a01001a
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a01001b
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a01001c
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a01001d
*:0:THREAD_NAME:49525153
*:0:THREAD_ID:a01001e
*:0:THREAD_NAME:737769363a207461
*:0:THREAD_NAME:736b2071756575
*:0:THREAD_ID:a01001f
*:0:THREAD_NAME:636f6e6669675f30
*:0:THREAD_ID:a010020
*:0:THREAD_NAME:737769353a206661
*:0:THREAD_NAME:7374207461736b
*:0:THREAD_ID:a010021
*:0:THREAD_NAME:6b71756575655f63
*:0:THREAD_NAME:7478207461736b
*:0:THREAD_ID:a010022
*:0:THREAD_NAME:7468726561642074
*:0:THREAD_NAME:61736b71
*:0:THREAD_ID:a010023
*:0:THREAD_NAME:737769363a204769
*:0:THREAD_NAME:616e7420746173
*:0:THREAD_ID:a010024
*:0:THREAD_NAME:737769313a206e65
*:0:THREAD_NAME:746973722030
*:0:THREAD_ID:a010025
*:0:THREAD_NAME:736f66746972715f
*:0:THREAD_NAME:30
*:0:THREAD_ID:a010026
*:0:THREAD_NAME:44484350
*:0:THREAD_ID:a010027
*:0:THREAD_NAME:5052544c
*:0:THREAD_ID:a010028
*:0:THREAD_NAME:50535441
*:0:THREAD_ID:a010029
*:0:THREAD_NAME:5052544c
*:0:THREAD_ID:a01002a
*:0:THREAD_NAME:50535441

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> Why do you implement a hash map on your own? I would have renamed the
> record-main.c to record-main.cc and use std::map for example or
> something from boost.
>
I tried this but this generates a lot of warnings from the same file and
other files also. Converting from C to another language requires the
resolution of each warning. That's why I implemented it.

>
> The threads can execute on every CPU, so this information must not be
> CPU-specific.
>
Okay

>
> What do you want to do with this line?
>
> map_insert( cctx->map_per_cpu[ item->cpu ].hashArray, item->data,
> rtems_record_event_text( item->event ));
>
> We need thread names, not the text of a record event.
>
Okay. How do I get thread name in client-side?

>
> To figure out how the thread names are sent from the target to your
> client you have to look at this patch:
>
>
> https://git.rtems.org/rtems/commit/?id=036717eda4de437336a86ca67253b7e32f67463c
>
> If you don't understand this patch, then please ask.
>
How do I access the thread name information in client-side? Will it be only
accessible through the TCP command
./build/misc/rtems-record -H 169.254.23.78 -p 1234 | head
or
./build/misc/rtems-record --input misc/record/qoriq_e6500_64.bin | head?


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 02/08/2019 05:48, Ravindra Kumar Meena wrote:
I have implemented the hash map for [thread_id]->[thread_name]. The hash 
map stores the thread per cpu.
https://github.com/rmeena840/rtems-tools/commit/a8da9cc4aefc1cdb5d9634715601a96f69fa526a 


Why do you implement a hash map on your own? I would have renamed the 
record-main.c to record-main.cc and use std::map for example or 
something from boost.


The threads can execute on every CPU, so this information must not be 
CPU-specific.


What do you want to do with this line?

map_insert( cctx->map_per_cpu[ item->cpu ].hashArray, item->data, 
rtems_record_event_text( item->event ));


We need thread names, not the text of a record event.

To figure out how the thread names are sent from the target to your 
client you have to look at this patch:


https://git.rtems.org/rtems/commit/?id=036717eda4de437336a86ca67253b7e32f67463c

If you don't understand this patch, then please ask.

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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

I have implemented the hash map for [thread_id]->[thread_name]. The hash
map stores the thread per cpu.
https://github.com/rmeena840/rtems-tools/commit/a8da9cc4aefc1cdb5d9634715601a96f69fa526a


Have a look.

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 31/07/2019 07:30, Sebastian Huber wrote:


Have added the prev_state in client-side:
https://github.com/rmeena840/rtems-tools/commit/43ae797ba3c6123cc51a6244a62912c999f69a1e 



The bit field is documented in the manual. I would simplify this to:

cctx->switch_out_int[ item->cpu ].prev_state = ( ( ( item->data >> 24 ) 
& 0x7 ) == 1 ) ? TASK_IDLE : TASK_RUNNING;


Did you check how the Trace Compass behaviour changed with this?

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

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 30/07/2019 18:32, Ravindra Kumar Meena wrote:

 >     The next tasks are:
 >
 >     1. Detect if we switch to/from an idle thread. In this case
set the
 >     corresponding state to TASK_IDLE == 1026.
 >
 > I tried to work on this task. I am not sure how to detect it without
 > calling pthread_*.
 > Does this have to do something with rtems_task_is_suspended?
 >

https://docs.rtems.org/branches/master/c-user/task_manager.html#rtems-task-is-suspended

On the host you cannot call any RTEMS functions on the target. All
information you have is in the record items. For a start, you can
identify the idle threads via the identifier API:

https://docs.rtems.org/branches/master/c-user/key_concepts.html#object-ids

The API value for idle threads is 1.

Have made changes in metadata to sync with RTEMS:
https://github.com/rmeena840/rtems-tools/commit/4bc050227dd3055af99bd73b667015a620c259d4


Since this enum is not defined by LTTNG, we should remove it.



Have added the prev_state in client-side:
https://github.com/rmeena840/rtems-tools/commit/43ae797ba3c6123cc51a6244a62912c999f69a1e


The bit field is documented in the manual. I would simplify this to:

cctx->switch_out_int[ item->cpu ].prev_state = ( ( ( item->data >> 24 ) 
& 0x7 ) == 1 ) ? TASK_IDLE : TASK_RUNNING;




Have a look


 >
 >
 >     2. The program should learn the thread names corresponding to
a thread
 >     identifier. Build up a thread identifier to thread name map.
Use the
 >     map
 >     to emit thread names in the sched_switch event.
 >
 > Mapping should be like this:
 > [thread_id]->[thread_name] or [thread_name]->[thread_id]?

In the RTEMS_RECORD_THREAD_SWITCH_OUT and RTEMS_RECORD_THREAD_SWITCH_IN
record events you have the thread id. So, the mapping must be
[thread_id]->[thread_name].

 >
 > the thread name can be obtained by:
 > rtems_record_event_text( item->event )
 >
 >
 >     You can use C++ if this makes it easier for you.
 >
 > I will have to create separate c++ file for this.

Please convert the entire record-main.c file to C++.

Okay. I will work on it after the previous task.


Did the previous task keep you busy for 8 hours?

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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > The next tasks are:
> >
> > 1. Detect if we switch to/from an idle thread. In this case set the
> > corresponding state to TASK_IDLE == 1026.
> >
> > I tried to work on this task. I am not sure how to detect it without
> > calling pthread_*.
> > Does this have to do something with rtems_task_is_suspended?
> >
> https://docs.rtems.org/branches/master/c-user/task_manager.html#rtems-task-is-suspended
>
> On the host you cannot call any RTEMS functions on the target. All
> information you have is in the record items. For a start, you can
> identify the idle threads via the identifier API:
>
> https://docs.rtems.org/branches/master/c-user/key_concepts.html#object-ids
>
> The API value for idle threads is 1.
>
Have made changes in metadata to sync with RTEMS:
https://github.com/rmeena840/rtems-tools/commit/4bc050227dd3055af99bd73b667015a620c259d4

Have added the prev_state in client-side:
https://github.com/rmeena840/rtems-tools/commit/43ae797ba3c6123cc51a6244a62912c999f69a1e

Have a look

>
> >
> >
> > 2. The program should learn the thread names corresponding to a
> thread
> > identifier. Build up a thread identifier to thread name map. Use the
> > map
> > to emit thread names in the sched_switch event.
> >
> > Mapping should be like this:
> > [thread_id]->[thread_name] or [thread_name]->[thread_id]?
>
> In the RTEMS_RECORD_THREAD_SWITCH_OUT and RTEMS_RECORD_THREAD_SWITCH_IN
> record events you have the thread id. So, the mapping must be
> [thread_id]->[thread_name].
>
> >
> > the thread name can be obtained by:
> > rtems_record_event_text( item->event )
> >
> >
> > You can use C++ if this makes it easier for you.
> >
> > I will have to create separate c++ file for this.
>
> Please convert the entire record-main.c file to C++.
>
Okay. I will work on it after the previous task.


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 30/07/2019 14:40, Ravindra Kumar Meena wrote:

I checked in the RTEMS patch to add some basic support for thread
names.
Please update your RTEMS to the current master branch.

I check in some patches for the rtems-record program in your
rtems-tools
branch.

Please run your tests with new raw input data:

../../build/misc/rtems-record --input=../record/qoriq_e6500_64.bin

Okay. Pulled the recent changes. Getting different output.


What do you mean with "different output"?




The next tasks are:

1. Detect if we switch to/from an idle thread. In this case set the
corresponding state to TASK_IDLE == 1026.

I tried to work on this task. I am not sure how to detect it without 
calling pthread_*.

Does this have to do something with rtems_task_is_suspended?
https://docs.rtems.org/branches/master/c-user/task_manager.html#rtems-task-is-suspended


On the host you cannot call any RTEMS functions on the target. All 
information you have is in the record items. For a start, you can 
identify the idle threads via the identifier API:


https://docs.rtems.org/branches/master/c-user/key_concepts.html#object-ids

The API value for idle threads is 1.




2. The program should learn the thread names corresponding to a thread
identifier. Build up a thread identifier to thread name map. Use the
map
to emit thread names in the sched_switch event.

Mapping should be like this:
[thread_id]->[thread_name] or [thread_name]->[thread_id]?


In the RTEMS_RECORD_THREAD_SWITCH_OUT and RTEMS_RECORD_THREAD_SWITCH_IN 
record events you have the thread id. So, the mapping must be 
[thread_id]->[thread_name].




the thread name can be obtained by:
rtems_record_event_text( item->event )


You can use C++ if this makes it easier for you.

I will have to create separate c++ file for this.


Please convert the entire record-main.c file to C++.

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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> I checked in the RTEMS patch to add some basic support for thread names.
> Please update your RTEMS to the current master branch.
>
> I check in some patches for the rtems-record program in your rtems-tools
> branch.
>
> Please run your tests with new raw input data:
>
> ../../build/misc/rtems-record --input=../record/qoriq_e6500_64.bin
>
Okay. Pulled the recent changes. Getting different output.

>
> The next tasks are:
>
> 1. Detect if we switch to/from an idle thread. In this case set the
> corresponding state to TASK_IDLE == 1026.
>
I tried to work on this task. I am not sure how to detect it without
calling pthread_*.
Does this have to do something with rtems_task_is_suspended?
https://docs.rtems.org/branches/master/c-user/task_manager.html#rtems-task-is-suspended

>
> 2. The program should learn the thread names corresponding to a thread
> identifier. Build up a thread identifier to thread name map. Use the map
> to emit thread names in the sched_switch event.
>
Mapping should be like this:
[thread_id]->[thread_name] or [thread_name]->[thread_id]?

the thread name can be obtained by:
rtems_record_event_text( item->event )


> You can use C++ if this makes it easier for you.
>
I will have to create separate c++ file for this.

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

Hello Ravindra,


On 29/07/2019 08:14, Ravindra Kumar Meena wrote:

*Plan of the week:*
Last week I added the sched_switch in client-side. Trace compass can now 
show more details of the trace now. I will continue to continue to work 
on client-side.
I checked in the RTEMS patch to add some basic support for thread names. 
Please update your RTEMS to the current master branch.


I check in some patches for the rtems-record program in your rtems-tools 
branch.


Please run your tests with new raw input data:

../../build/misc/rtems-record --input=../record/qoriq_e6500_64.bin

The next tasks are:

1. Detect if we switch to/from an idle thread. In this case set the 
corresponding state to TASK_IDLE == 1026.


2. The program should learn the thread names corresponding to a thread 
identifier. Build up a thread identifier to thread name map. Use the map 
to emit thread names in the sched_switch event.


You can use C++ if this makes it easier for you.

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

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

- Am 29. Jul 2019 um 12:21 schrieb Ravindra Kumar Meena rmeena...@gmail.com:

>>
>> > What I understand from here is that _prev_state is the previous state of
>> > the thread(TID)).
>>
>> Yes, but what is the meaning of these state values? We have to figure this
>> out since we need a mapping from RTEMS thread states to these Linux thread
>> states. Could you use an example trace from Linux to check if the
>> information referenced in this email answer makes sense?
>>
> 
> $ grep "#define TASK_" include/linux/sched.h
> #define TASK_RUNNING0x
> #define TASK_INTERRUPTIBLE  0x0001
> #define TASK_UNINTERRUPTIBLE0x0002
> #define TASK_PARKED 0x0040
> #define TASK_DEAD   0x0080
> #define TASK_WAKEKILL   0x0100
> #define TASK_WAKING 0x0200
> #define TASK_NOLOAD 0x0400
> #define TASK_NEW0x0800
> #define TASK_STATE_MAX  0x1000
> #define TASK_KILLABLE   (TASK_WAKEKILL |
> TASK_UNINTERRUPTIBLE)
> #define TASK_STOPPED(TASK_WAKEKILL | __TASK_STOPPED)
> #define TASK_TRACED (TASK_WAKEKILL | __TASK_TRACED)
> #define TASK_IDLE   (TASK_UNINTERRUPTIBLE | TASK_NOLOAD)
> #define TASK_NORMAL (TASK_INTERRUPTIBLE |
> TASK_UNINTERRUPTIBLE)
> #define TASK_REPORT (TASK_RUNNING | TASK_INTERRUPTIBLE
>| \
> 
> In babeltrace output _prev_state have { 0, 1, 1026, 4096 } values.
> If you have look at above #define . They have been defined in hex
> format.
> eg.
> 0 is 0x which means TASK_RUNNING
> 1 is 0x0001 which means TASK_INTERRUPTIBLE
> 1026 in decimal is 0x402 which is 0x400 | 0x002. That is TASK_NOLOAD |
> TASK_UNINTERRUPTIBLE, or, as defined above, it's simply TASK_IDLE.
> 
> So in this way, all the prev_state are defined.

Ok, I think on RTEMS only TASK_RUNNING and TASK_IDLE make sense at the moment. 
You have to use the thread ID to determine if an idle thread is involved in the 
sched_switch event.

> 
>>
>> >
>> >
>> >> It would be good to get task names for the IDs. Do you have an idea how
>> >> we can do this?
>> >>
>> > With task name do you mean RTEMS_RECORD_THREAD_SWITCH_IN
>> > and RTEMS_RECORD_THREAD_SWITCH_OUT?
>> >
>> > if so this can be done by calling:
>> > rtems_record_event_text( item->event )
>>
>> Attached is a patch for RTEMS. The record server sends all thread names to
>> the client after the header.
>>
>> For thread name changes and new threads we have to think about.
>>
> I applied the patch. The bootstrap worked successfully. I am not sure what
> I have to do with this.

Please look at the patch and try to understand it.

Once you connect to the record server, it sends you the names of all present 
threads after the header. You can collect this information and use it to map a 
thread ID to a name.

The mapping might be a bit difficult to implement in C for you. You can also 
use C++ for the record client if this makes it easier for you.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > What I understand from here is that _prev_state is the previous state of
> > the thread(TID)).
>
> Yes, but what is the meaning of these state values? We have to figure this
> out since we need a mapping from RTEMS thread states to these Linux thread
> states. Could you use an example trace from Linux to check if the
> information referenced in this email answer makes sense?
>

$ grep "#define TASK_" include/linux/sched.h
#define TASK_RUNNING0x
#define TASK_INTERRUPTIBLE  0x0001
#define TASK_UNINTERRUPTIBLE0x0002
#define TASK_PARKED 0x0040
#define TASK_DEAD   0x0080
#define TASK_WAKEKILL   0x0100
#define TASK_WAKING 0x0200
#define TASK_NOLOAD 0x0400
#define TASK_NEW0x0800
#define TASK_STATE_MAX  0x1000
#define TASK_KILLABLE   (TASK_WAKEKILL |
TASK_UNINTERRUPTIBLE)
#define TASK_STOPPED(TASK_WAKEKILL | __TASK_STOPPED)
#define TASK_TRACED (TASK_WAKEKILL | __TASK_TRACED)
#define TASK_IDLE   (TASK_UNINTERRUPTIBLE | TASK_NOLOAD)
#define TASK_NORMAL (TASK_INTERRUPTIBLE |
TASK_UNINTERRUPTIBLE)
#define TASK_REPORT (TASK_RUNNING | TASK_INTERRUPTIBLE
| \

In babeltrace output _prev_state have { 0, 1, 1026, 4096 } values.
If you have look at above #define . They have been defined in hex
format.
eg.
0 is 0x which means TASK_RUNNING
1 is 0x0001 which means TASK_INTERRUPTIBLE
1026 in decimal is 0x402 which is 0x400 | 0x002. That is TASK_NOLOAD |
TASK_UNINTERRUPTIBLE, or, as defined above, it's simply TASK_IDLE.

So in this way, all the prev_state are defined.

>
> >
> >
> >> It would be good to get task names for the IDs. Do you have an idea how
> >> we can do this?
> >>
> > With task name do you mean RTEMS_RECORD_THREAD_SWITCH_IN
> > and RTEMS_RECORD_THREAD_SWITCH_OUT?
> >
> > if so this can be done by calling:
> > rtems_record_event_text( item->event )
>
> Attached is a patch for RTEMS. The record server sends all thread names to
> the client after the header.
>
> For thread name changes and new threads we have to think about.
>
I applied the patch. The bootstrap worked successfully. I am not sure what
I have to do with this.


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

- Am 26. Jul 2019 um 14:56 schrieb Ravindra Kumar Meena rmeena...@gmail.com:

>>
>> Ok, very good. This look all right. It is amazing how much information
>> Trace Compass can display with only sched_switch events.
>>
> Great!! We have something working very useful. :) :)
> 
>>
>> Please figure out how the state member values are defined. I think this
>> is important to improve the diagrams.
>>
> Here is the response from lltng:
> https://lists.lttng.org/pipermail/lttng-dev/2019-July/029121.html
> 
> What I understand from here is that _prev_state is the previous state of
> the thread(TID)).

Yes, but what is the meaning of these state values? We have to figure this out 
since we need a mapping from RTEMS thread states to these Linux thread states. 
Could you use an example trace from Linux to check if the information 
referenced in this email answer makes sense?

> 
> 
>> It would be good to get task names for the IDs. Do you have an idea how
>> we can do this?
>>
> With task name do you mean RTEMS_RECORD_THREAD_SWITCH_IN
> and RTEMS_RECORD_THREAD_SWITCH_OUT?
> 
> if so this can be done by calling:
> rtems_record_event_text( item->event )

Attached is a patch for RTEMS. The record server sends all thread names to the 
client after the header.

For thread name changes and new threads we have to think about.
From 05b8722d2db2dbc316b2b4d77a7f42399e68 Mon Sep 17 00:00:00 2001
From: Sebastian Huber 
Date: Fri, 26 Jul 2019 16:36:10 +0200
Subject: [PATCH] record: Add support for thread names

---
 cpukit/include/rtems/recorddata.h  |  4 +-
 cpukit/libtrace/record/record-server.c | 70 ++
 cpukit/libtrace/record/record-text.c   |  2 +-
 testsuites/libtests/record01/init.c| 30 +++
 4 files changed, 103 insertions(+), 3 deletions(-)

diff --git a/cpukit/include/rtems/recorddata.h b/cpukit/include/rtems/recorddata.h
index 61a6311735..607955c596 100644
--- a/cpukit/include/rtems/recorddata.h
+++ b/cpukit/include/rtems/recorddata.h
@@ -55,7 +55,7 @@ extern "C" {
  * The record version reflects the record event definitions.  It is reported by
  * the RTEMS_RECORD_VERSION event.
  */
-#define RTEMS_RECORD_THE_VERSION 4
+#define RTEMS_RECORD_THE_VERSION 5
 
 /**
  * @brief The items are in 32-bit little-endian format.
@@ -291,6 +291,7 @@ typedef enum {
   RTEMS_RECORD_THREAD_EXIT,
   RTEMS_RECORD_THREAD_EXITTED,
   RTEMS_RECORD_THREAD_ID,
+  RTEMS_RECORD_THREAD_NAME,
   RTEMS_RECORD_THREAD_PRIO_CURRENT_HIGH,
   RTEMS_RECORD_THREAD_PRIO_CURRENT_LOW,
   RTEMS_RECORD_THREAD_PRIO_REAL_HIGH,
@@ -607,7 +608,6 @@ typedef enum {
   RTEMS_RECORD_SYSTEM_508,
   RTEMS_RECORD_SYSTEM_509,
   RTEMS_RECORD_SYSTEM_510,
-  RTEMS_RECORD_SYSTEM_511,
 
   /* There are 512 events reserved for the user */
   RTEMS_RECORD_USER_0,
diff --git a/cpukit/libtrace/record/record-server.c b/cpukit/libtrace/record/record-server.c
index 840924a24a..f84852d226 100644
--- a/cpukit/libtrace/record/record-server.c
+++ b/cpukit/libtrace/record/record-server.c
@@ -30,6 +30,7 @@
 #endif
 
 #include 
+#include 
 #include 
 
 #include 
@@ -165,6 +166,74 @@ static void send_header( int fd )
   (void) write( fd, , sizeof( header ) );
 }
 
+typedef struct {
+  int fd;
+  size_t index;
+  rtems_record_item items[ 128 ];
+} thread_names_context;
+
+static void thread_names_produce(
+  thread_names_context *ctx,
+  rtems_record_eventevent,
+  rtems_record_data data
+)
+{
+  size_t i;
+
+  i = ctx->index;
+  ctx->items[ i ].event = RTEMS_RECORD_TIME_EVENT( 0, event );
+  ctx->items[ i ].data = data;
+
+  if (i == RTEMS_ARRAY_SIZE(ctx->items) - 2) {
+ctx->index = 0;
+(void) write( ctx->fd, ctx->items, sizeof( ctx->items ) );
+  } else {
+ctx->index = i + 1;
+  }
+}
+
+static bool thread_names_visitor( rtems_tcb *tcb, void *arg )
+{
+  thread_names_context *ctx;
+  char  buf[ 16 ];
+  size_tn;
+  size_ti;
+  rtems_record_data data;
+
+  ctx = arg;
+  thread_names_produce( ctx, RTEMS_RECORD_THREAD_ID, tcb->Object.id );
+  n = _Thread_Get_name( tcb, buf, sizeof( buf ) );
+  i = 0;
+
+  while ( i < n ) {
+size_t j;
+
+data = 0;
+
+for ( j = 0; i < n && j < sizeof( data ); ++j ) {
+  data = ( data << 8 ) | buf[ i ];
+  ++i;
+}
+
+thread_names_produce( ctx, RTEMS_RECORD_THREAD_NAME, data );
+  }
+
+  return false;
+}
+
+static void send_thread_names( int fd )
+{
+  thread_names_context ctx;
+
+  ctx.fd = fd;
+  ctx.index = 0;
+  rtems_task_iterate( thread_names_visitor,  );
+
+  if ( ctx.index > 0 ) {
+(void) write( ctx.fd, ctx.items, ctx.index * sizeof( ctx.items[ 0 ] ) );
+  }
+}
+
 void rtems_record_server( uint16_t port, rtems_interval period )
 {
   rtems_status_code sc;
@@ -216,6 +285,7 @@ void rtems_record_server( uint16_t port, rtems_interval period )
 wait( RTEMS_NO_WAIT );
 (void) rtems_timer_fire_after( timer, period, wakeup_timer,  );
 send_header( cd );
+send_thread_names( cd );
 
 

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> Ok, very good. This look all right. It is amazing how much information
> Trace Compass can display with only sched_switch events.
>
Great!! We have something working very useful. :) :)

>
> Please figure out how the state member values are defined. I think this
> is important to improve the diagrams.
>
Here is the response from lltng:
https://lists.lttng.org/pipermail/lttng-dev/2019-July/029121.html

What I understand from here is that _prev_state is the previous state of
the thread(TID)).


> It would be good to get task names for the IDs. Do you have an idea how
> we can do this?
>
With task name do you mean RTEMS_RECORD_THREAD_SWITCH_IN
and RTEMS_RECORD_THREAD_SWITCH_OUT?

if so this can be done by calling:
rtems_record_event_text( item->event )


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > 1. Gather the information from two record events
> > (RTEMS_RECORD_THREAD_SWITCH_OUT and RTEMS_RECORD_THREAD_SWITCH_IN)
> with
> > the same timestamp on the same CPU.
> >
> > A CPU can have many records events. Since RTEMS_RECORD_THREAD_SWITCH_IN
> > is received after RTEMS_RECORD_THREAD_SWITCH_OUT we can just directly
> > write into corresponding CPU file after receiving
> > RTEMS_RECORD_THREAD_SWITCH_IN for the same timestamp.
>
> Yes.
>
> All the record handling must be done per CPU.
>
> >
> >
> > 2. Once you gathered the information of two events that meet this
> > criteria, you produce exactly one LTTNG sched_switch event.
> >
> >   Okay. So this particular lttng sched_switch will have prev_* value
> > as RTEMS_RECORD_THREAD_SWITCH_OUT data and next_* value
> > as RTEMS_RECORD_THREAD_SWITCH_IN.
>
> Yes.
>
Have made changes:

https://github.com/rmeena840/rtems-tools/commit/4048dfb7f5c49ba731e46946b51b12af95088109

Have a look

I have made code more easy to understand.

Babeltrace output:

babeltrace . | head

[19:16:31.180116542] (+?.?) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "0a01002b", prev_tid = 167837739, prev_prio = 0,
prev_state = 0, next_comm = "09010014", next_tid = 151060500, next_prio = 0
}
[19:16:31.180154588] (+0.38046) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "09010014", prev_tid = 151060500, prev_prio = 0,
prev_state = 0, next_comm = "0a01002b", next_tid = 167837739, next_prio = 0
}
[19:16:31.180174232] (+0.19644) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "0a01002b", prev_tid = 167837739, prev_prio = 0,
prev_state = 0, next_comm = "09010014", next_tid = 151060500, next_prio = 0
}
[19:16:31.180223920] (+0.49688) Record_Item sched_switch: { cpu_id = 5
}, { prev_comm = "09010015", prev_tid = 151060501, prev_prio = 0,
prev_state = 0, next_comm = "0a01002b", next_tid = 167837739, next_prio = 0
}
[19:16:31.180241405] (+0.17485) Record_Item sched_switch: { cpu_id = 5
}, { prev_comm = "0a01002b", prev_tid = 167837739, prev_prio = 0,
prev_state = 0, next_comm = "09010015", next_tid = 151060501, next_prio = 0
}
[19:16:31.180281360] (+0.39955) Record_Item sched_switch: { cpu_id = 5
}, { prev_comm = "09010015", prev_tid = 151060501, prev_prio = 0,
prev_state = 0, next_comm = "0a01002b", next_tid = 167837739, next_prio = 0
}
[19:16:31.180295428] (+0.14068) Record_Item sched_switch: { cpu_id = 5
}, { prev_comm = "0a01002b", prev_tid = 167837739, prev_prio = 0,
prev_state = 0, next_comm = "09010015", next_tid = 151060501, next_prio = 0
}
[19:16:31.180348740] (+0.53312) Record_Item sched_switch: { cpu_id = 5
}, { prev_comm = "09010015", prev_tid = 151060501, prev_prio = 0,
prev_state = 0, next_comm = "0a01002b", next_tid = 167837739, next_prio = 0
}
[19:16:31.180362596] (+0.13856) Record_Item sched_switch: { cpu_id = 5
}, { prev_comm = "0a01002b", prev_tid = 167837739, prev_prio = 0,
prev_state = 0, next_comm = "09010015", next_tid = 151060501, next_prio = 0
}
[19:16:31.180397048] (+0.34452) Record_Item sched_switch: { cpu_id = 5
}, { prev_comm = "09010015", prev_tid = 151060501, prev_prio = 0,
prev_state = 0, next_comm = "0a01002b", next_tid = 167837739, next_prio = 0
}

Both prev_* and next_* values are different.


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 25/07/2019 09:24, Ravindra Kumar Meena wrote:

 >

https://github.com/rmeena840/rtems-tools/commit/f7838f156006064ffc53b1b1d3fb01f80ef15ae4


No, sorry, this is not what we need. Maybe you should delete this code
part and start from scratch.

We process record events and produce LTTNG events. Is this clear?

Your task is:

1. Gather the information from two record events
(RTEMS_RECORD_THREAD_SWITCH_OUT and RTEMS_RECORD_THREAD_SWITCH_IN) with
the same timestamp on the same CPU.

A CPU can have many records events. Since RTEMS_RECORD_THREAD_SWITCH_IN 
is received after RTEMS_RECORD_THREAD_SWITCH_OUT we can just directly 
write into corresponding CPU file after receiving 
RTEMS_RECORD_THREAD_SWITCH_IN for the same timestamp.


Yes.

All the record handling must be done per CPU.




2. Once you gathered the information of two events that meet this
criteria, you produce exactly one LTTNG sched_switch event.

  Okay. So this particular lttng sched_switch will have prev_* value 
as RTEMS_RECORD_THREAD_SWITCH_OUT data and next_* value 
as RTEMS_RECORD_THREAD_SWITCH_IN.


Yes.

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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> >
> https://github.com/rmeena840/rtems-tools/commit/f7838f156006064ffc53b1b1d3fb01f80ef15ae4
>
> No, sorry, this is not what we need. Maybe you should delete this code
> part and start from scratch.
>
> We process record events and produce LTTNG events. Is this clear?
>
> Your task is:
>
> 1. Gather the information from two record events
> (RTEMS_RECORD_THREAD_SWITCH_OUT and RTEMS_RECORD_THREAD_SWITCH_IN) with
> the same timestamp on the same CPU.

A CPU can have many records events. Since RTEMS_RECORD_THREAD_SWITCH_IN is
received after RTEMS_RECORD_THREAD_SWITCH_OUT we can just directly write
into corresponding CPU file after receiving RTEMS_RECORD_THREAD_SWITCH_IN
for the same timestamp.

>
>
2. Once you gathered the information of two events that meet this
> criteria, you produce exactly one LTTNG sched_switch event.
>
 Okay. So this particular lttng sched_switch will have prev_* value
as RTEMS_RECORD_THREAD_SWITCH_OUT data and next_* value
as RTEMS_RECORD_THREAD_SWITCH_IN.


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 25/07/2019 07:53, Ravindra Kumar Meena wrote:

We don't need threads for this program. I meant if you know the concept
of software threads in general and what a stack is.


I have removed the RTEMS_RECORD_THREAD_STACK_CURRENT.

https://github.com/rmeena840/rtems-tools/commit/f7838f156006064ffc53b1b1d3fb01f80ef15ae4 


No, sorry, this is not what we need. Maybe you should delete this code 
part and start from scratch.


We process record events and produce LTTNG events. Is this clear?

Your task is:

1. Gather the information from two record events 
(RTEMS_RECORD_THREAD_SWITCH_OUT and RTEMS_RECORD_THREAD_SWITCH_IN) with 
the same timestamp on the same CPU.


2. Once you gathered the information of two events that meet this 
criteria, you produce exactly one LTTNG sched_switch event.


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

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 25/07/2019 06:34, Ravindra Kumar Meena wrote:

Being not equal is necessary but not sufficient.

Your code is too complicated.  Please try to simplify it.  Avoid the
magic numbers and use the enumerator constants instead.

Okay


Why do you use values from RTEMS_RECORD_THREAD_STACK_CURRENT for the
sched_switch? Do you know what a software thread is?

I learned software thread in Java. I tried to implement thread in C. We 
need '-lpthread' flag in gcc compiler to use the thread in C. Does this 
flag needed to be included in wscript?


We don't need threads for this program. I meant if you know the concept 
of software threads in general and what a stack is.


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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> Being not equal is necessary but not sufficient.
>
> Your code is too complicated.  Please try to simplify it.  Avoid the
> magic numbers and use the enumerator constants instead.
>
Okay

>
> Why do you use values from RTEMS_RECORD_THREAD_STACK_CURRENT for the
> sched_switch? Do you know what a software thread is?
>
I learned software thread in Java. I tried to implement thread in C. We
need '-lpthread' flag in gcc compiler to use the thread in C. Does this
flag needed to be included in wscript?



-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 24/07/2019 14:07, Ravindra Kumar Meena wrote:

You received RTEMS_RECORD_THREAD_SWITCH_OUT two record events before
the
   RTEMS_RECORD_THREAD_SWITCH_IN with the same timestamp. See my
comment
above. In these two record events all you need for the sched_switch
event is contained.


Have made changes:

https://github.com/rmeena840/rtems-tools/commit/880eb38c41f66e5ca08429f9ed52a209feed123e

Have a look.

Babeltrace output:

babeltrace . | head


[...]
[19:16:31.180223920] (+0.49688) Record_Item sched_switch: { cpu_id = 
5 }, { prev_comm = "09010015", prev_tid = 151060501, prev_prio = 0, 
prev_state = 0, next_comm = "1ce0", next_tid = 7392, next_prio = 0 }


Now the prev_* and next_* values are not equal.


Being not equal is necessary but not sufficient.

Your code is too complicated.  Please try to simplify it.  Avoid the 
magic numbers and use the enumerator constants instead.


Why do you use values from RTEMS_RECORD_THREAD_STACK_CURRENT for the 
sched_switch? Do you know what a software thread is?


You only need RTEMS_RECORD_THREAD_SWITCH_IN and 
RTEMS_RECORD_THREAD_SWITCH_OUT.


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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> You received RTEMS_RECORD_THREAD_SWITCH_OUT two record events before the
>   RTEMS_RECORD_THREAD_SWITCH_IN with the same timestamp. See my comment
> above. In these two record events all you need for the sched_switch
> event is contained.
>

Have made changes:

https://github.com/rmeena840/rtems-tools/commit/880eb38c41f66e5ca08429f9ed52a209feed123e

Have a look.

Babeltrace output:

babeltrace . | head

[19:16:31.180116542] (+?.?) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "0a01002b", prev_tid = 167837739, prev_prio = 0,
prev_state = 0, next_comm = "16e0", next_tid = 5856, next_prio = 0 }
[19:16:31.180116542] (+0.0) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "16e0", prev_tid = 5856, prev_prio = 0, prev_state =
0, next_comm = "09010014", next_tid = 151060500, next_prio = 0 }
[19:16:31.180116542] (+0.0) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "09010014", prev_tid = 151060500, prev_prio = 0,
prev_state = 0, next_comm = "0a01002b", next_tid = 167837739, next_prio = 0
}
[19:16:31.180154588] (+0.38046) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "09010014", prev_tid = 151060500, prev_prio = 0,
prev_state = 0, next_comm = "1ce0", next_tid = 7392, next_prio = 0 }
[19:16:31.180154588] (+0.0) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "1ce0", prev_tid = 7392, prev_prio = 0, prev_state =
0, next_comm = "0a01002b", next_tid = 167837739, next_prio = 0 }
[19:16:31.180154588] (+0.0) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "0a01002b", prev_tid = 167837739, prev_prio = 0,
prev_state = 0, next_comm = "09010014", next_tid = 151060500, next_prio = 0
}
[19:16:31.180174232] (+0.19644) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "0a01002b", prev_tid = 167837739, prev_prio = 0,
prev_state = 0, next_comm = "16e0", next_tid = 5856, next_prio = 0 }
[19:16:31.180174232] (+0.0) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "16e0", prev_tid = 5856, prev_prio = 0, prev_state =
0, next_comm = "09010014", next_tid = 151060500, next_prio = 0 }
[19:16:31.180174232] (+0.0) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "09010014", prev_tid = 151060500, prev_prio = 0,
prev_state = 0, next_comm = "0a01002b", next_tid = 167837739, next_prio = 0
}
[19:16:31.180223920] (+0.49688) Record_Item sched_switch: { cpu_id = 5
}, { prev_comm = "09010015", prev_tid = 151060501, prev_prio = 0,
prev_state = 0, next_comm = "1ce0", next_tid = 7392, next_prio = 0 }

Now the prev_* and next_* values are not equal.


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 24/07/2019 11:04, Ravindra Kumar Meena wrote:

This approach makes no sense to me.

Per CPU you receive three record events in succession:

[19:32:26.679099590] (+0.46608) Record_Item
RTEMS_RECORDING_EVENT: {
cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_SWITCH_OUT" :
container =
216 ), data = 167837707 }
[19:32:26.679099590] (+0.0) Record_Item
RTEMS_RECORDING_EVENT: {
cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_STACK_CURRENT" :
container = 209 ), data = 32320 }
[19:32:26.679099590] (+0.0) Record_Item
RTEMS_RECORDING_EVENT: {
cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_SWITCH_IN" : container =
215 ), data = 151060501 }

They have all the same timestamp.

When you receive an RTEMS_RECORD_THREAD_SWITCH_OUT event, you store the
timestamp (per CPU) and the data (per-CPU, this is the thread ID).

When you receive an RTEMS_RECORD_THREAD_SWITCH_IN event and the
timestamp matches, you use the values of the current event and the
values stored before to output an LTTNG sched_switch event.

I am trying this approach but I think there is one problem with it. When 
RTEMS_RECORD_THREAD_SWITCH_IN event is received then there is no way to 
receive it's next_* values.


You received RTEMS_RECORD_THREAD_SWITCH_OUT two record events before the 
 RTEMS_RECORD_THREAD_SWITCH_IN with the same timestamp. See my comment 
above. In these two record events all you need for the sched_switch 
event is contained.


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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> This approach makes no sense to me.
>
> Per CPU you receive three record events in succession:
>
> [19:32:26.679099590] (+0.46608) Record_Item RTEMS_RECORDING_EVENT: {
> cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_SWITCH_OUT" : container =
> 216 ), data = 167837707 }
> [19:32:26.679099590] (+0.0) Record_Item RTEMS_RECORDING_EVENT: {
> cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_STACK_CURRENT" :
> container = 209 ), data = 32320 }
> [19:32:26.679099590] (+0.0) Record_Item RTEMS_RECORDING_EVENT: {
> cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_SWITCH_IN" : container =
> 215 ), data = 151060501 }
>
> They have all the same timestamp.
>
> When you receive an RTEMS_RECORD_THREAD_SWITCH_OUT event, you store the
> timestamp (per CPU) and the data (per-CPU, this is the thread ID).
>
> When you receive an RTEMS_RECORD_THREAD_SWITCH_IN event and the
> timestamp matches, you use the values of the current event and the
> values stored before to output an LTTNG sched_switch event.
>

I am trying this approach but I think there is one problem with it. When
RTEMS_RECORD_THREAD_SWITCH_IN event is received then there is no way to
receive it's next_* values.

e.g.

ab //RTEMS_RECORD_THREAD_SWITCH_OUT
bc //RTEMS_RECORD_THREAD_STACK_CURRENT
cd //RTEMS_RECORD_THREAD_SWITCH_IN

Think this example as output in babeltrace where first character is of
prev_comm value and second character is of next_comm value. Since we will
be writing just after receiving c(third row) we can't get d values.

For this, we should have d value so that we can write it in
RTEMS_RECORD_THREAD_SWITCH_IN event with next_comm value.




-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 24/07/2019 07:47, Ravindra Kumar Meena wrote:

This makes no sense:

static void print_item( client_context *cctx, const client_item *item )
{
    if( cctx->event_counter % 2 == 0 ){

1. event_counter is not per CPU.

2. You don't care about the record event. You have to do this for
specific events as I already wrote in the description of this task.


I forgot to remove the modular operator.

https://github.com/rmeena840/rtems-tools/commit/c278c48abab1d5ea93cf36823bd24af07633f35f

The logic behind this is that when the first time program enters in 
print_item() it initializes the
prev_* values and after this, it will enter in else part recursively 
initializing prev_* and next_* values for the same CPU and write it in 
the file.


This approach makes no sense to me.

Per CPU you receive three record events in succession:

[19:32:26.679099590] (+0.46608) Record_Item RTEMS_RECORDING_EVENT: { 
cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_SWITCH_OUT" : container = 
216 ), data = 167837707 }
[19:32:26.679099590] (+0.0) Record_Item RTEMS_RECORDING_EVENT: { 
cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_STACK_CURRENT" : 
container = 209 ), data = 32320 }
[19:32:26.679099590] (+0.0) Record_Item RTEMS_RECORDING_EVENT: { 
cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_SWITCH_IN" : container = 
215 ), data = 151060501 }


They have all the same timestamp.

When you receive an RTEMS_RECORD_THREAD_SWITCH_OUT event, you store the 
timestamp (per CPU) and the data (per-CPU, this is the thread ID).


When you receive an RTEMS_RECORD_THREAD_SWITCH_IN event and the 
timestamp matches, you use the values of the current event and the 
values stored before to output an LTTNG sched_switch event.


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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> This makes no sense:
>
> static void print_item( client_context *cctx, const client_item *item )
> {
>if( cctx->event_counter % 2 == 0 ){
>
> 1. event_counter is not per CPU.
>
> 2. You don't care about the record event. You have to do this for
> specific events as I already wrote in the description of this task.
>

I forgot to remove the modular operator.

https://github.com/rmeena840/rtems-tools/commit/c278c48abab1d5ea93cf36823bd24af07633f35f

The logic behind this is that when the first time program enters in
print_item() it initializes the
prev_* values and after this, it will enter in else part recursively
initializing prev_* and next_* values for the same CPU and write it in the
file.


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 23/07/2019 12:34, Ravindra Kumar Meena wrote:

All your state must be per-CPU otherwise you mix data from different
CPUs.

Have made changes.

https://github.com/rmeena840/rtems-tools/commit/fac873672d5cd8fe3605ea7ac817ebaa4e8e4cdc


This makes no sense:

static void print_item( client_context *cctx, const client_item *item )
{
  if( cctx->event_counter % 2 == 0 ){

1. event_counter is not per CPU.

2. You don't care about the record event. You have to do this for 
specific events as I already wrote in the description of this task.


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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> All your state must be per-CPU otherwise you mix data from different CPUs.
>
Have made changes.

https://github.com/rmeena840/rtems-tools/commit/fac873672d5cd8fe3605ea7ac817ebaa4e8e4cdc

Have a look.

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 23/07/2019 10:23, Ravindra Kumar Meena wrote:

I said this before, do not add global variables like this:

   static void print_item( client_context *cctx, const client_item
*item )
   {
     switch_event switch_event;
     event_header_extended event_header_extended;
     char item_data_str[256];
     FILE **f = cctx->event_streams;

+  static size_t event_counter = 1;
+  static uint8_t prev_comm[16];
+  static int32_t prev_tid;
+  static uint32_t cpu_id;
+  static uint64_t ns;

Move all your state to client_context. I said also that you have to
create the sched_switch event per CPU.

Have made changes.

https://github.com/rmeena840/rtems-tools/commit/a9e7c343188f2b5dcf2dded0f6b407bcdbcdced3


All your state must be per-CPU otherwise you mix data from different CPUs.

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

Re: GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> I said this before, do not add global variables like this:
>
>   static void print_item( client_context *cctx, const client_item *item )
>   {
> switch_event switch_event;
> event_header_extended event_header_extended;
> char item_data_str[256];
> FILE **f = cctx->event_streams;
>
> +  static size_t event_counter = 1;
> +  static uint8_t prev_comm[16];
> +  static int32_t prev_tid;
> +  static uint32_t cpu_id;
> +  static uint64_t ns;
>
> Move all your state to client_context. I said also that you have to
> create the sched_switch event per CPU.
>
Have made changes.

https://github.com/rmeena840/rtems-tools/commit/a9e7c343188f2b5dcf2dded0f6b407bcdbcdced3

Have a look.

Babeltrace output:

babeltrace . | head

[19:16:31.179109789] (+?.?) Record_Item sched_switch: { cpu_id = 0
}, { prev_comm = "", prev_tid = 0, prev_prio = 0, prev_state = 0, next_comm
= "1ce0", next_tid = 7392, next_prio = 0 }
[19:16:31.180096211] (+0.000986422) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "0a01002b", prev_tid = 167837739, prev_prio = 0,
prev_state = 0, next_comm = "0a01002b", next_tid = 167837739, next_prio = 0
}
[19:16:31.180116542] (+0.20331) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "0a01002b", prev_tid = 167837739, prev_prio = 0,
prev_state = 0, next_comm = "09010014", next_tid = 151060500, next_prio = 0
}
[19:16:31.180116542] (+0.0) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "09010014", prev_tid = 151060500, prev_prio = 0,
prev_state = 0, next_comm = "1ce0", next_tid = 7392, next_prio = 0 }
[19:16:31.180154588] (+0.38046) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "1ce0", prev_tid = 7392, prev_prio = 0, prev_state =
0, next_comm = "0a01002b", next_tid = 167837739, next_prio = 0 }
[19:16:31.180174232] (+0.19644) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "0a01002b", prev_tid = 167837739, prev_prio = 0,
prev_state = 0, next_comm = "09010014", next_tid = 151060500, next_prio = 0
}
[19:16:31.180174232] (+0.0) Record_Item sched_switch: { cpu_id = 17
}, { prev_comm = "09010014", prev_tid = 151060500, prev_prio = 0,
prev_state = 0, next_comm = "09010015", next_tid = 151060501, next_prio = 0
}
[19:16:31.180208594] (+0.34362) Record_Item sched_switch: { cpu_id = 5
}, { prev_comm = "09010015", prev_tid = 151060501, prev_prio = 0,
prev_state = 0, next_comm = "1ce0", next_tid = 7392, next_prio = 0 }
[19:16:31.180223920] (+0.15326) Record_Item sched_switch: { cpu_id = 5
}, { prev_comm = "1ce0", prev_tid = 7392, prev_prio = 0, prev_state =
0, next_comm = "0a01002b", next_tid = 167837739, next_prio = 0 }
[19:16:31.180241405] (+0.17485) Record_Item sched_switch: { cpu_id = 5
}, { prev_comm = "0a01002b", prev_tid = 167837739, prev_prio = 0,
prev_state = 0, next_comm = "09010015", next_tid = 151060501, next_prio = 0
}


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel