GSOC proposal - Runtime tracing

[Gedare Bloom]

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