Queries regarding Tracing related bugs and GSoC 2017

[Gedare Bloom]

On Sun, Mar 19, 2017 at 11:23 AM, vivek kukreja <vivekkukreja5 at gmail.com> wrote:
> Hello developers,
>
> I have worked on CTF tracing last year under GSoC. I was working on my
> previous deliverables and i noticed there are some bugs in the current
> capture and function tracing examples on qemu for arm/xilinx_zynq_a9,
> related to recent updates made to TCB and termios implementation. I'm
> working on resolving these issues so I can merge my previous changes.
> I have mailed Chris regarding this and I was suggested to ping the
> developer list for further clarification on these errors, and whether
> I should create any tickets.
>
Good. Probably you should have a ticket related to the project. Maybe
create a GSoC Project ticket.

> I also wanted to enquire about the status of the Live tracing project
> this year in GSoC. I'm considering the following ideas for a proposal,
> once the tracing support is re-established:
>
> 1. libDWARF integration: I've been studying libDWARF for
> functionalities that can be ported to RTEMS, for the purpose of
> finding function signatures and variable types to be traced by the
> trace linker. This can be used to auto-configure the signatures/types
> at the trace linking phase of an application.
>
> 2. Transports API: In GSoC 2016 I worked on transport for moving
> traces to host. I investigated serial and USB transport apart from
> ethernet using libBSD. There is discussion on the Tracing projects
> page about integrating all transports and providing an API for custom
> transports in the application for both capture and function tracing.
>
> 3. Live tracing: In capture tracing, the trace process has to be
> paused before reading the trace (as discussed with Jennifer Averrett,
> the previous contributor). I'm looking at alternatives like copying
> the unsafe buffer to a new one which can in turn be dumped on host
> using NFS or other transport options. We can create a low priority
> task for this purpose, along with the trace buffering functions
> defined in rtld-trace-buffer.ini.
>
> Please suggest any improvements or additions to the above ideas. Also
> I dont know if there is any interest in this project for GSoC 2017 but
> I would like to merge my previous changes soon nonetheless.
>
This continues to be an important area to support. I suspect a
"Transports API" would be a good beneficial project to scope out and
understand. Without Transports, it is hard to create a uniform
approach to live tracing that would work well across Architectures/BSP
families.

> Regards,
> Vivek
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel