[GSOC - Tracing] Status Update
Vidushi Vashishth
reachvidu at gmail.com
Thu Jul 5 00:51:53 UTC 2018
>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.champagne at 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 <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
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180705/e4a79f38/attachment-0002.html>
More information about the devel
mailing list