From mboxrd@z Thu Jan 1 00:00:00 1970 From: mathieu.desnoyers@polymtl.ca (Mathieu Desnoyers) Date: Tue, 23 Dec 2008 11:59:51 -0500 Subject: [ltt-dev] LTTng. Strings with missing characters (ARM) In-Reply-To: <1E65288790442545B413D69F2A8D27DE04568EF1@ERLD164A.ww004.siemens.net> References: <1E65288790442545B413D69F2A8D27DE04568A68@ERLD164A.ww004.siemens.net> <20081219171644.GC1339@Krystal> <1E65288790442545B413D69F2A8D27DE04568D9C@ERLD164A.ww004.siemens.net> <20081222185109.GC22001@Krystal> <1E65288790442545B413D69F2A8D27DE04568EF1@ERLD164A.ww004.siemens.net> Message-ID: <20081223165951.GB17885@Krystal> (adding the ltt-dev list in CC, so other developers can have a look at it and help reproducing this ARM problem) Hrm, weird, So /proc/ltt outputs correct strings, but ltt-armall output is messed up. Can you do the following ? which ltt-armall and cat `which ltt-armall` I guess it has something to do with the IFS=$'\n' line in the script, which works on x86, but maybe not on arm for some reason. Also, can you give me the output after this sequence of commands ? ltt-armall lttctl -C -w /tmp/trace trace find /mnt/debugfs/ltt (where /mnt/debugfs is the path to your debugfs mount) Thanks Mathieu * Akyurek, Ali (EXT) (ali.akyurek.ext at siemens.com) wrote: > > Hello, > > Strings are seem to be cutted off at 'n' character. > > -----Urspr?ngliche Nachricht----- > Von: Mathieu Desnoyers [mailto:mathieu.desnoyers at polymtl.ca] > Gesendet: Montag, 22. Dezember 2008 19:51 > An: Akyurek, Ali (EXT) > Betreff: Re: LTTng. Strings with missing characters > > > Hrm, > > What do you get if you do : > > cat /proc/ltt ? > > And what is your kernel config ? > > Mathieu > > * Akyurek, Ali (EXT) (ali.akyurek.ext at siemens.com) wrote: > > > > > > > > Hello again, > > > > I've installed latest versions LTTng 0.70, lttcontrol 0.61. > > > > When i run armall, in the output, i see strings with missing characters like: > > > > ... > > Connecting el irq_exit > > ker > > Connecting el kthread_create > > ker > > Connecting el kthread_stop > > ker > > Connecting el kthread_stop_ret > > ker > > ... > > > > > > Also after i'm done with tracing, the trace output directory looks like: > > > > drwxr-xr-x 2 root 0 0 Jan 1 02:12 . > > drwxr-xr-x 3 root 0 0 Jan 1 01:55 .. > > -rwxr-xr-x 1 root 0 262144 Jan 1 01:55 _page_e_0 > > -rwxr-xr-x 1 root 0 262144 Jan 1 01:55 d_sig_0 > > -rwxr-xr-x 1 root 0 262144 Jan 1 01:55 dle_fault_e_0 > > -rwxr-xr-x 1 root 0 262144 Jan 1 01:55 el_0 > > -rwxr-xr-x 1 root 0 262144 Jan 1 01:55 etif_state_0 > > -rwxr-xr-x 1 root 0 262144 Jan 1 01:55 etwork_ip_i_0 > > -rwxr-xr-x 1 root 0 262144 Jan 1 01:55 etwork_ipv4_i_0 > > -rwxr-xr-x 1 root 0 65536 Jan 1 01:55 fd_state_0 > > -rwxr-xr-x 1 root 0 262144 Jan 1 01:55 metadata_0 > > -rwxr-xr-x 1 root 0 262144 Jan 1 01:55 mm_0 > > -rwxr-xr-x 1 root 0 262144 Jan 1 01:55 put_0 > > -rwxr-xr-x 1 root 0 262144 Jan 1 01:55 put_eve_0 > > > > Do you have an idea about it? > > > > Thanks. > > > > > > -----Urspr?ngliche Nachricht----- > > Von: Mathieu Desnoyers [mailto:mathieu.desnoyers at polymtl.ca] > > Gesendet: Freitag, 19. Dezember 2008 18:17 > > An: Akyurek, Ali (EXT) > > Betreff: Re: arm userspace tracing > > > > Hello ! > > > > Well, it's your lucky day I guess. I just added a neat feature to LTTng > > which will help a great deal sending a subset of the data types > > supported (a simple string) into the trace buffers from userspace _very_ > > easily. It's not integrated with the event management, so I would not > > add this to application in production (because it would add overhead > > even when tracing is disabled). With the latest LTTng, all you have to > > do is : > > > > modprobe ltt-userspace-event > > lttctl -C -w /tmp/trace trace (note : the arguments recently changed) > > run stuff... > > echo "Some event happened!" > /mnt/debugfs/ltt/write_event > > lttctl -D trace > > looking specifically for the event : > > lttv -e userspace.event -m textDump -t /tmp/trace > > > > So basically, you can look for your own string into the trace stream as > > a starting point. This is portable, so should work on ARM without any > > problem. > > > > There is still a lot of work to do on ARM to have per-site activation of > > tracepoints like we currently have in the kernel, but at least this > > solution gives us _something_. It's just that it's always enabled. > > > > * Akyurek, Ali (EXT) (ali.akyurek.ext at siemens.com) wrote: > > > Hello Mr.Desnoyers, > > > > > > First of all, thanks for the great work you've done. > > > What i wonder is that is it possible to trace user space in arm architecture? > > > In the quick start document it writes : > > > > > > "Get the latest markers-userspace-*.tar.bz2 and see the Makefile and examples. It > > > allows inserting markers in executables and libraries, currently only on x86_32 > > > and x86_64." > > > > > > But ,then i've seen a patch in http://ltt.polymtl.ca/packages/markers-user/ called lttng-userspace-tracing-arm.patch . > > > > > > > That was a complete syscall implementation at some point, which could be > > ported to the new infrastructure, but note that the current > > markers-userspace-*.tar.bz2 code also needs linker script modification. > > > > Mathieu > > > > > Thanks. > > > > > > Mit freundlichem Gruss / Best Regards > > > Ali G?nhan Aky?rek > > > evoline TR > > > > > > > -- > > Mathieu Desnoyers > > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 > > > > -- > Mathieu Desnoyers > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 > -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68