GSOC proposal - Runtime tracing

[Vidushi Vashishth]

Hello!

>>We should focus on basic functionality and this is interrupt entry/exit
and thread switching. This should work out of the box without having to
compile RTEMS with specialized configuration options. It should work via a
serial line and network (UDP I guess). It should also support SMP machines.
This requires per-processor trace buffers. The trace buffer should work
without locks, e.g. only interrupt disable/enable. I would do also a short
review of existing trace solutions. Maybe we don't have to re-invent the
wheel. For example:

http://www.cs.unc.edu/~bbb/feathertrace/

I see. I went through the feathertrace solution documentation. I am also
looking at other solutions, including Linux Trace Toolkit. I will reinvent
the focus of my proposal to include the basic functionality suggested.

>There is a lot to review to get the
plan right here. I've made comments on the google doc proposal.

Yes. I went over the comments. Thank you for such a detailed explanation. I
will amend the proposal to incorporate the comments.

>I don't see how network support can exist out-of-the-box unless the
solution exists at libbsd level. I think there will be two pieces to
this kind of project:
1. capturing traces to memory buffers from interrupt/"kernel" contexts.
2. transporting buffers via worker threads.

Then, one can implement a basic worker thread using available drivers
in rtems, and also more advanced (network) workers relying on libbsd.

>The use of per-processor buffers makes the "reader" side (transport)
more complicated. This is a good place to consider a wait-free
non-blocking data structure, or a rwlock with writer prioritization.
At any rate, a good design is needed here with some careful thought.

I will investigate if an out of the box solution exists at the libbsd level
and post it here.


Regards,
Vidushi



On Fri, Mar 23, 2018 at 8:58 PM, Gedare Bloom <gedare at rtems.org> wrote:

> Hello Vidushi, Sebastian:
>
> On Fri, Mar 23, 2018 at 2:16 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
> > Hello Vidushi,
> >
> > the RTEMS Trace Linker is definitely an interesting tool to track down
> > difficult and specific issues. However, this is a nice to have optional
>
> out-of-box Trace Linker with integration to debugger or CTF tools will
> be highly beneficial for the "user-side" experience of RTEMS. This can
> be quite beneficial for marketing if nothing else. :) Given the
> current state, and that we've had a few projects already on this
> topic, any project working here needs to focus on delivering a
> complete slice of the software stack from trace configuration all the
> way through trace output analysis. There is a lot to review to get the
> plan right here. I've made comments on the google doc proposal.
>
> > feature from my point of view. We should focus on basic functionality and
> > this is interrupt entry/exit and thread switching. This should work out
> of
> > the box without having to compile RTEMS with specialized configuration
>
> I agree that this is also an important aspect for "kernel-level"
> tracing, and it should be implemented directly into RTEMS with
> standard configuration (configure or confdefs.h options). The
> requirements for this functionality is unclear, though, such as what
> the trace output should be.
>
> > options. It should work via a serial line and network (UDP I guess). It
>
> I don't see how network support can exist out-of-the-box unless the
> solution exists at libbsd level. I think there will be two pieces to
> this kind of project:
> 1. capturing traces to memory buffers from interrupt/"kernel" contexts.
> 2. transporting buffers via worker threads.
>
> Then, one can implement a basic worker thread using available drivers
> in rtems, and also more advanced (network) workers relying on libbsd.
>
> > should also support SMP machines. This requires per-processor trace
> buffers.
> > The trace buffer should work without locks, e.g. only interrupt
> > disable/enable. I would do also a short review of existing trace
> solutions.
>
> The use of per-processor buffers makes the "reader" side (transport)
> more complicated. This is a good place to consider a wait-free
> non-blocking data structure, or a rwlock with writer prioritization.
> At any rate, a good design is needed here with some careful thought.
>
> > Maybe we don't have to re-invent the wheel. For example:
> >
> > http://www.cs.unc.edu/~bbb/feathertrace/
> >
> > --
> > 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.huber at embedded-brains.de
> > PGP     : Public key available on request.
> >
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180324/d120c0cf/attachment-0002.html>