On Thu, May 26, 2016 at 6:16 PM, vivek kukreja <vivekkukre...@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 <chr...@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
>
>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
