GSOC2016: Improvements in RTEMS Tracing Framework

[vivek kukreja]

On Thu, May 26, 2016 at 6:16 PM, vivek kukreja <vivekkukreja5 at gmail.com> wrote:
>
> 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?
>> Nevermind. Instead of RMON I had to put object id of the task(argument).
>
>
> 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
>
>