Print stack info using rtems_stack_checker_report_usage_with_plugin()

Fri Jan 3 20:58:21 UTC 2020

On Thu, Dec 12, 2019 at 7:08 AM Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Thu, Dec 12, 2019, 7:21 AM Fernando Domínguez Pousa <fdpousa at gmv.com>
> wrote:
>
>>
>>
>>
>>
>> *From:* Joel Sherrill [mailto:joel at rtems.org]
>> *Sent:* 10 December 2019 17:36
>> *To:* Fernando Domínguez Pousa <fdpousa at gmv.com>
>> *Subject:* Re: Print stack info using
>> rtems_stack_checker_report_usage_with_plugin()
>>
>>
>>
>>
>>
>> On Tue, Dec 10, 2019, 8:37 AM Fernando Domínguez Pousa <fdpousa at gmv.com>
>> wrote:
>>
>> Hi all,
>>
>>
>>
>> I’m interested in getting stack information via an UDP message with an
>> ASCII log trace inside. Basically, I cannot get the information using a
>> printf. I found the function
>> rtems_stack_checker_report_usage_with_plugin(rtems_printer* printer) in
>> order to get the information and send it using my UDP log function. So
>> first of all I created a function called logPlugin (I used as exampled the
>> plugin at printf_plugin.c):
>>
>>
>>
>> static int logPlugin(void *context, const char *format, va_list ap)
>>
>> {
>>
>>   (void) context;
>>
>>   return addLog(INFO, STACK,format, ap); /* First two arguments are used
>> to classify message at reception*/
>>
>> }
>>
>>
>>
>> Then at rtems_stack_checker_report_usage_with_plugin calling scope:
>>
>>
>>
>>   rtems_printer printer;
>>
>>
>>
>>   printer.context = NULL;
>>
>>   printer.printer = logPlugin;
>>
>>
>>
>>   rtems_stack_checker_report_usage_with_plugin(&printer);
>>
>>
>>
>> It is important to say that addLog puts the message in a circular buffer
>> that other task will read and send the content using UDP.
>>
>>
>>
>> When stack checker report usage is called, only the information header is
>> printed:     "                             STACK USAGE BY THREAD\n"
>>
>>      "ID         NAME                  LOW        HIGH       CURRENT
>> AVAIL   USED\n"
>>
>>
>>
>> Next, stack values are not printed correctly and I can only get a value
>> that is constant and equal to the same memory location (in decimal).  It is
>> a correct guide to implement this? I do not know how to use the printer
>> struct context variable, can this cause my problem?
>>
>>
>>
>> Did you add CONFIGURE_ENABLE_STACK_CHECKER?
>>
>>
>>
>> Yes, it was enabled.
>>
>>
>>
>> Also it would be handy to have methods for obtain cpu and stack usage
>> without relying on the printf hook
>>
>>
>>
>> I developed a code to gather all the tasks stack information into a
>> struct that can be retrieved via function. Then I pack this struct and sent
>> it via Ethernet. Can I add my code to check.c in order to retrieve stack
>> information without print it? Is this an intersesting feature for the
>> community?
>>
>
> Yes it is interesting. File a ticket so there is one to track this
> addition.
>
> It also will need a test and some documentation. I'm not sure how the test
> will check the function behaves correctly.
>
> Looking forward to seeing your submission.
>
>
We've had this feature request before. It was somewhat captured in
https://devel.rtems.org/wiki/Developer/Projects/Open/StackChecker

and the related:
https://devel.rtems.org/wiki/Developer/Projects/Open/CPU_Statistics

It's not clear it is enough work for a GSoC, but it seems too much work for
someone to do voluntarily :)

> --joel
>
>>
>>
>> Regards,
>>
>>
>>
>>
>>
>> Thanks in advance,
>>
>>
>>
>> Regards,
>>
>>
>>
>>
>> ------------------------------
>>
>>
>> *Fernando Domínguez Pousa *Ingeniero de Software
>> Software Engineer
>>
>> GMV
>> Isaac Newton, 11
>> P.T.M. Tres Cantos
>> E-28760 Madrid
>> Tel. +34 91 807 21 00
>> Fax +34 91 807 21 99
>> www.gmv.com
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.facebook.com_infoGMV&d=DwMFaQ&c=CIoxZ4z5BqFvKvSGFOTo726QZIiNTc_M9CmngT-Pla4&r=JJRyTkGL8xI4YFJLjo7JWw&m=ZnGDe8CiC5tUJJuEodtypPFjSXET23uigE7l-uSzLMY&s=TVgsYD5kZtUVH9LulD6BpnRsdJjK7KKhwm0gExv79V0&e=>
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.twitter.com_infoGMV-5Fes&d=DwMFaQ&c=CIoxZ4z5BqFvKvSGFOTo726QZIiNTc_M9CmngT-Pla4&r=JJRyTkGL8xI4YFJLjo7JWw&m=ZnGDe8CiC5tUJJuEodtypPFjSXET23uigE7l-uSzLMY&s=AKhuDTIEG9B5SSppSI9W2IZbCtlVN6Xxghmhqw_8xrs&e=>
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__plus.google.com_-2BGmvcompany&d=DwMFaQ&c=CIoxZ4z5BqFvKvSGFOTo726QZIiNTc_M9CmngT-Pla4&r=JJRyTkGL8xI4YFJLjo7JWw&m=ZnGDe8CiC5tUJJuEodtypPFjSXET23uigE7l-uSzLMY&s=aH_sTC6ItBsWu6XvQPqgmMi4brzX7wBHmPqFQ2FbfSc&e=>
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.youtube.com_infoGMV&d=DwMFaQ&c=CIoxZ4z5BqFvKvSGFOTo726QZIiNTc_M9CmngT-Pla4&r=JJRyTkGL8xI4YFJLjo7JWw&m=ZnGDe8CiC5tUJJuEodtypPFjSXET23uigE7l-uSzLMY&s=LeXn3Vd6znq0lx28JCcO0BUCbRxzg36aodelZfSy_QE&e=>
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_gmv&d=DwMFaQ&c=CIoxZ4z5BqFvKvSGFOTo726QZIiNTc_M9CmngT-Pla4&r=JJRyTkGL8xI4YFJLjo7JWw&m=ZnGDe8CiC5tUJJuEodtypPFjSXET23uigE7l-uSzLMY&s=qQvn0q84_7QaJIvkgK7wpqkfzr7YoJNDa9KIA6w0TVQ&e=>
>>
>> <http://www.gmv.com/en/RSS>
>>
>>
>>
>> <http://www.gmv.com/blog_gmv/language/en/>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> P Please consider the environment before printing this e-mail.
>>
>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_users&d=DwMFaQ&c=CIoxZ4z5BqFvKvSGFOTo726QZIiNTc_M9CmngT-Pla4&r=JJRyTkGL8xI4YFJLjo7JWw&m=ZnGDe8CiC5tUJJuEodtypPFjSXET23uigE7l-uSzLMY&s=dGxmP2gK5vUyNRX5UQVoMbmLLQ1K6M-QpFkFJfVYVEY&e=>
>>
>>
>> P Please consider the environment before printing this e-mail.
>>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20200103/74551c33/attachment.html>