GSOC proposal - Runtime tracing

[Sebastian Huber]

On 23/03/18 16:28, Gedare Bloom 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.

I think we should define some basic functionality which should be 
available ready to use during mid term evaluation. I want to avoid a 
last minute delivery during the project end with no time to fix problems 
after a review. This likely results in some half-finished work which 
nobody can use.

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

The network transport should rely on the POSIX sockets API only as 
defined by Newlib.

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

Everything which uses an atomic read-modify-write operation on some 
global data will lead to a significant change in the overall timing on 
larger machines with several cache layers (e.g. QoriIQ T4240). The 
reader side with per-processor data is not that difficult if everything 
runs in kernel-space. You can use processor affine threads (supported by 
the default SMP scheduler) or inter-processor interrupts to fetch the data.

>
>> Maybe we don't have to re-invent the wheel. For example:
>>
>> http://www.cs.unc.edu/~bbb/feathertrace/

This was just one example.

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