Print stack info using rtems_stack_checker_report_usage_with_plugin()

[Joel Sherrill]

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.

--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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20191212/60639762/attachment.html>