[GSOC - Tracing] Status Update

Wed Jul 4 22:34:36 UTC 2018

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 <gedare at rtems.org>
> wrote:
> > On Mon, Jul 2, 2018 at 1:27 AM, Sebastian Huber
> > <sebastian.huber at 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.huber at embedded-brains.de
> > > PGP     : Public key available on request.
> > >
> > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des
> > EHUG.
> > >
> 
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel