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