On Sun, Mar 19, 2017 at 11:23 AM, vivek kukreja <vivekkukre...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
