Now the ctrace command returns the following error: trace read failed: RTEMS_UNSATISFIED. I think the problem lies in rtems_capture_read function call in capture_support.c file. Im trying to debug the capture engine code. Does anyone how to resolve this?
> On 26-May-2016, at 23:56, vivek kukreja <vivekkukre...@gmail.com> wrote: > >> 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
