>I am not sure you can do this without providing your own babeltrace source component in a separate plugin to what is already available. If the trace is not converted to a useful CTF format.
Yes. The blog post is merely to demonstrate how to use babeltrace. We will not be dealing with text trace input to babeltrace. I am reading up on how to create a customized plugin for RTEMS binary trace output for this. Transporting ASCII files off the target will be a heavy operation hence this is avoided. Thanks On Thu, Jul 5, 2018 at 4:04 AM, Guillaume Champagne < guillaume.champa...@polymtl.ca> wrote: > On Tue, 2018-07-03 at 07:50 +0530, Vidushi Vashishth wrote: > > > 3. Clearly document your modifications in separate commit messages. > > > > > 4. Add a Makefile to build it automatically. > > > > I will push commits to a fork of the rtems. Have given a link to the > > repository in the readme.md of the Tracing repo. Will that be okay? > > > > > 6. Document the steps involved in the tracing, e.g. trace data > > generation on the RTEMS target, transfer of the data to the > > development host, conversion of trace data in format X to Y using > > tool Z, etc. Document the interfaces between the different steps and > > what runs on the RTEMS target and what runs on the development host. > > > > Done > > > > > To get the trace data from the simulator to the development host, > > you can just dump the data via printf() and parse it on the host. > > This is slow, but enough for a test scenario. > > > > I have tested the babeltrace conversion by saving the console output > > to a text file on host manually (https://vidushivashishth.github.io/e > > ighthpost/). Can I use sockets to transport the traces from target to > > host instead? Will that be feasible? I have already created a client > > and server side program and tested a text file transfer. This is > > working. > > > > I tried the example in your blog post which works without `sudo` with > babeltrace 2.0.0-pre4 on fedora. However, I am not sure the ctf output > is correct. Each line in the original trace is dumped in a ctf event > named "string" since the example uses the source `text.dmesg`. This > source is usually used to parse the output of the dmesg linux tool [1]. > > string: { }, { str = "0:00:26.703188295 2081911 0a010002 [ 2/ 2] > > malloc((size_t) 00000130)" } > string: { }, { str = "0:00:26.703324403 136108 0a010002 [ 2/ 2] > < malloc => (void*) 0x219be08" } > [..] > > This should be changed to actually split the data into correct CTF > event field and header, like lttng-ust does: > > [18:14:22.611410669] (+0.000001652) station12.dorsal.polymtl.ca > lttng_ust_cyg_profile:func_entry: { cpu_id = 5 }, { vpid = 21117, vtid = > 21117, procname = "demo" }, { addr = 0x7FF848DB6E21, call_site = > 0x7FF848DB7856 } > [..] > > I am not sure you can do this without providing your own babeltrace > source component in a separate plugin to what is already available. If > the trace is not converted to a useful CTF format, Trace Compass won't > provide any useful analyses since it won't know what the event or the > payload means. > > [1] http://man7.org/linux/man-pages/man7/babeltrace-source.text.dmesg.7 > .html > > Guillaume > > > > Either we should use barectf to generate CTF traces in RTEMS, we > > > should implement our own CTF generator in RTEMS, or we should > > provide > > > a converter for running babeltrace on a host (Linux/MacOS/etc) to > > > convert from RTEMS trace linker format to CTF. > > > > I am implementing the last option. > > > > On Tue, Jul 3, 2018 at 1:37 AM, Gedare Bloom <ged...@rtems.org> > > wrote: > > > On Mon, Jul 2, 2018 at 1:27 AM, Sebastian Huber > > > <sebastian.hu...@embedded-brains.de> wrote: > > > > Hello Vidushi, > > > > > > > > On 29/06/18 09:44, Vidushi Vashishth wrote: > > > >> > > > >> > > > >> >Could you please create a self-contained repository > > > which > > > >> contains > > > >> > > > >> >* a README > > > >> > > > >> >* a simple RTEMS application which runs on a simulator > > > BSP > > > >> > > > >> >* the stuff that makes it possible to view the trace > > > output > > > >> (it is not a problem if it doesn't work, but all pieces > > > should > > > >> be included) > > > >> > > > >> >The repository should not be a clone of some larger > > > project. > > > >> It may contain external references as submodules. > > > >> > > > >> Okay. Got it. I will update you when its done. > > > >> > > > >> > > > >> Ok, do you have a time estimate for this? Which parts are > > > missing? > > > >> > > > >> > > > >> Viewing the trace output is buggy right now. I will have to > > > combine the > > > >> rest. I will push the required things in the repository by end > > > of today and > > > >> notify you. > > > >> > > > > > > > > the stuff you published here > > > > > > > > https://github.com/VidushiVashishth/Tracing > > > > > > > > yesterday (this is not "by end of today") is not much considering > > > this the > > > > 8th week of the GSoC project. > > > > > > > > You seem to have imported cpukit/libmisc/shell/main_rtrace.c and > > > modified > > > > it. The modifications are not visible in the repository history. > > > Why did yo > > > > copy this file out of the RTEMS sources at all? > > > > > > > > There is no Makefile (or similar). You have to read the > > > documentation to > > > > build it. You cannot copy and past the instructions to build it > > > since it > > > > contains your local paths. > > > > > > > > The test data is generated with user input. > > > > > > > > How can I transfer the test data generated on the simulator to my > > > host > > > > development system? > > > > > > > > I asked for a self-contained repository, with"the stuff that > > > makes it > > > > possible to view the trace output". This is missing. > > > > > > > > Could you please: > > > > > > > > 1. Not copy sources out of the RTEMS repository. Before you do > > > this, ask on > > > > the mailing list and explain why have have to do it. > > > > > > > > 2. If you import things, then import the original files and state > > > the > > > > origin. > > > > > > > > 3. Clearly document your modifications in separate commit > > > messages. > > > > > > > > 4. Add a Makefile to build it automatically. > > > > > > > > 5. Add the missing stuff that makes it possible to view the trace > > > output. If > > > > something is not available yet, then no problem. Just document > > > the > > > > interfaces and what it is supposed to do. > > > > > > > > 6. Document the steps involved in the tracing, e.g. trace data > > > generation on > > > > the RTEMS target, transfer of the data to the development host, > > > conversion > > > > of trace data in format X to Y using tool Z, etc. Document the > > > interfaces > > > > between the different steps and what runs on the RTEMS target and > > > what runs > > > > on the development host. > > > > > > > > To get the trace data from the simulator to the development host, > > > you can > > > > just dump the data via printf() and parse it on the host. This is > > > slow, but > > > > enough for a test scenario. > > > > > > > > You should be able to do this in a couple of hours. > > > > > > > > > > I'm trying to catch up. I generally agree with all this. Also, I do > > > not see any reason ever to try to run babeltrace from RTEMS. I > > > don't > > > know if that is being attempted, but it is not a worthwhile effort. > > > Either we should use barectf to generate CTF traces in RTEMS, we > > > should implement our own CTF generator in RTEMS, or we should > > > provide > > > a converter for running babeltrace on a host (Linux/MacOS/etc) to > > > convert from RTEMS trace linker format to CTF. > > > > > > Gedare > > > > > > > > > > > -- > > > > Sebastian Huber, embedded brains GmbH > > > > > > > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > > > > Phone : +49 89 189 47 41-16 > > > > Fax : +49 89 189 47 41-09 > > > > E-Mail : sebastian.hu...@embedded-brains.de > > > > PGP : Public key available on request. > > > > > > > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des > > > EHUG. > > > > > > > > _______________________________________________ > > 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
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
