GSOC2016: Improvements in RTEMS Tracing Framework

[vivek kukreja]

Hello all,

I'm facing a problem with function tracing. I made changes to rtems-tld
command to ouput a CTF metadata file but i need sizes of arguments and
return values at compile-time to be put in the metadata file.
For now i have yet to put actual variable sizes. Any recommendations how to
go about it? We could use shared libraries or gdb along with
fileio-wrapper.o to identify variables and sizes from symbol table.

Also, my tasks for this week include tracing user-extensions and converting
them to CTF.
I followed the tutorial on
https://ftp.rtems.org/pub/rtems/people/chrisj/capture/capture-pc586.txt to
run capture.exe example but failed.
Is building grub image necessary? Trying to run the example for
xilinx_zynq_a9_qemu bsp directly on Qemu doesn't seem to work. RMON task is
visible in the init tasks list but 'ctset RMON' command fails. Any
suggestions how to make this work?

Regards,
Vivek

On Tue, May 24, 2016 at 6:56 AM, Chris Johns <chrisj at rtems.org> wrote:

> On 23/05/2016 23:19, Isaac Gutekunst wrote:
>
>> Hi Vivek,
>>
>> This is looking good!
>>
>
> I agree.
>
> I somewhat sketchy solution for getting binary files off a target is to
>> print them as intel hex, and copy them from the terminal. If the Zynq
>> bsp supports networking, you could setup a TFTP server. My ugly trace
>> implementation implements the lttng-live protocol for getting the CTF
>> stream off the target.
>>
>> See
>>
>> https://github.com/lttng/lttng-tools/blob/master/doc/live-reading-protocol.txt
>>
>>
>> Chris, do you think it's worth going down this path yet? I think this is
>> the best long term solution, as it makes RTEMS targets with networking
>> support remotely traceable with babeltrace and Trace Compass.
>>
>>
> We will have to at some stage so what ever effort is spent should help us
> get a step closer. We just need monitor it does not stall the main focus of
> the work. At the moment it is looking like the best solution to getting
> data of the boards.
>
> I'm a little confused how the BSD, old style, and lwip networking stacks
>> differ, and whether it would be possible to target all three easily.
>>
>
> This is a general area of confusion and flux.
>
> My
>> understanding is that the existing stack, and the BSD stack both
>> integrate into the RTEMS filesystem (have file descriptors), while LWIP
>> has some super ugly macros that redefine read/write/etc.
>>
>
> Let me document here what currently exists for LibBSD stack and the legacy
> stack. Maybe Pavel can help with the LwIP stack.
>
> Legacy Stack (stack in the RTEMS source tree):
>
> 1. Configured by tables and calls. Documented in the RTEMS Network
> Supplement.
> 2. Has network file system support for NFSv2, FTP and TFTP.
>
> LibBSD Stack
>
> 1. Configured using FreeBSD rc.conf(5) format files. I have only just
> added this support and it is limited but functional interface with static
> configurations. I am working on this support. The tar support changes I
> have recently posted and the RTEMS print changes are all related to this
> support.
> 2. No networked file system support. This is an important issue that needs
> to be resolved.
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160526/50ba2b09/attachment-0002.html>