[lttng-dev] Fwd: compiling LTTng for android
Amit Balboul
amit.balboul at shinesec.com
Sun Mar 17 03:17:32 EDT 2013
That's great news !!!
Glad to hear that this is the last hurdle to pass,
Thanks,
Amit.
On Fri, Mar 15, 2013 at 5:08 PM, Mathieu Desnoyers <
mathieu.desnoyers at efficios.com> wrote:
> * Pierre-Luc St-Charles (pierre-luc.st-charles at polymtl.ca) wrote:
> > Good news!
> >
> > After peeking yesterday through the different glibc/SysV implementations
> > (wrappers...) of splice I could find, I realized that those are not
> > actually necessary for what we intend to do: from what I found out, they
> > only redefine/wrap/redeclare the sys_splice system call that's
> implemented
> > directly in the kernel (in any architecture). Considering we don't need
> > anything more than the default (kernel-space) splice, we can simply
> rewire
> > the 'splice' declaration we use/have to syscall(__NR_splice,...), just
> like
> > what was needed for epoll_create1 earlier.
> >
> > For example : (doing this from memory... I don't have access to the code
> > atm)
> > > in src/common/compat/fcntl.h, inside the linux ifdef, top of the file:
> >
> > #ifdef __ANDROID__
> > #define SPLICE_F_MOVE 0x01
> > #define SPLICE_F_NONBLOCK 0x02
> > #define SPLICE_F_MORE 0x04
> > #define SPLICE_F_GIFT 0x08
> > static inline ssize_t splice(int fd_in, loff_t *off_in, int fd_out,
> > loff_t *off_out,
> > size_t len, unsigned int flags)
> > {
> > return syscall(__NR_splice,fd_in,loff_in,fd_out,loff_out,len,flags);
> > }
> > #endif
> >
> >
> > Result? Boom, traces.
> >
> > The rest of the project seems to work without any other visible problem,
> > and we can finally obtain traces when asking the tools nicely. In fact,
> we
> > can obtain traces from any device without even having to modify the
> > kernel/system image at all (except to add module and tracepoints support,
> > which should already be there), which is pretty surprising, but also very
> > useful, considering we can just ship the required binaries anywhere and
> > start tracing.
> >
> > Once we confirm that the traces are actually good and we haven't broken
> > anything else (we're still not sure liburcu works 100%, we're trying to
> run
> > all the tests), we'll start sending in results for anyone who might be
> > interested.
>
> That's great news! So I understand that you got lttng-modules Linux
> kernel tracing to work on Android. I look forward to see patches we
> could merge into lttng-tools.
>
> I guess the next step will be to look into LTTng-UST user-space tracing.
>
> Thanks,
>
> Mathieu
>
> >
> > - PL
> >
> > On Tue, Mar 12, 2013 at 6:51 PM, Pierre-Luc St-Charles <
> > pierre-luc.st-charles at polymtl.ca> wrote:
> >
> > > Hey Amit,
> > >
> > > Here's a small update on my latest findings regarding the broken
> *splice*
> > > / bad Bionic impl problem:
> > >
> > > Although it didn't really cross my mind earlier, we had seen this exact
> > > problem before, but in another project; we had also investigated a bit
> at
> > > the time, but to no avail. It seems the issue is known by the
> > > Android/Bionic community, but it's simply not on their immediate todo
> list
> > > (and hasn't been for at least the past two years -- see
> > > https://code.google.com/p/android/issues/detail?id=11330). The
> solutions
> > > we are now considering are: adding splice support (and whatever else
> might
> > > also be needed) to Bionic ourselves (saving BILLIONS of broken lives
> in the
> > > process, IF the changes are accepted), or simply inserting glibc (and
> > > building against it) in our device images.
> > >
> > > In the next few days, we'll be studying how much time the first
> solution
> > > would actually take (as we're not really experts in that domain at
> all),
> > > but considering the nature/objective of this project, it might be the
> > > wisest decision (as it would not require too much swerving away from
> the
> > > default images people have on their devices for LTTng to actually
> work). If
> > > we deem it 'impossible/out of our league', we'll simply try to get a
> > > working tool asap using glibc, which should not be very complicated
> itself
> > > (many people have actually successfully done it before).
> > >
> > > In any case, I'll keep you updated, and I'll also post any big updates
> on
> > > the mailing list.
> > >
> > > -PL
> > >
> > > On Wed, Mar 6, 2013 at 8:04 PM, Pierre-Luc St-Charles <
> > > pierre-luc.st-charles at polymtl.ca> wrote:
> > >
> > >> Great findings!
> > >>
> > >> I'll also try to look into this new problem by next monday; I'm
> falling a
> > >> bit behind on my 'investigations', but I'll keep you updated if
> anything
> > >> comes up.
> > >>
> > >> -PL
> > >> On Mar 6, 2013 6:09 PM, "Amit Balboul" <amit.balboul at shinesec.com>
> wrote:
> > >>
> > >>> Hi All,
> > >>>
> > >>> Regarding the last mail about tracing system calls on Android using
> > >>> LTTng,
> > >>> The issue of not receiving enabled event to trace from the kernel
> can be
> > >>> fixed patching src/bin/lttng-sessiond/kernel.c (patch attached)
> > >>> In the function *kernel_list_events,* fscanf-ing the events exported
> by
> > >>> the kernel using the fp must not use the syntax *%m* as it is
> obsolete
> > >>> (in Android),
> > >>> thus the fscanf returns 0 and won't read the kernel events (first
> > >>> condition false).
> > >>> Instead I use a pre-allocated buffer for the string and use the
> *%[^;]*syntax, and omitting the memory free (attached is the patch).
> > >>>
> > >>> The resulting output is (sessiond is run with verbose debug prints):
> > >>>
> > >>> root at android:/data/lttng/bin # *./lttng list -k*
> > >>> DEBUG1 [10239/10290]: Wait for client response (in
> > >>> thread_manage_clients() at main.c:3242)
> > >>> DEBUG1 [10239/10290]: Receiving data from client ... (in
> > >>> thread_manage_clients() at main.c:3287)
> > >>> DEBUG1 [10239/10290]: Nothing recv() from client... continuing (in
> > >>> thread_manage_clients() at main.c:3291)
> > >>> DEBUG1 [10239/10290]: Clean command context structure (in
> > >>> clean_command_ctx() at main.c:482)
> > >>> DEBUG1 [10239/10290]: Accepting client command ... (in
> > >>> thread_manage_clients() at main.c:3200)
> > >>> DEBUG1 [10239/10290]: Wait for client response (in
> > >>> thread_manage_clients() at main.c:3242)
> > >>> DEBUG1 [10239/10290]: Receiving data from client ... (in
> > >>> thread_manage_clients() at main.c:3287)
> > >>> DEBUG1 [10239/10290]: Processing client command 14 (in
> > >>> process_client_msg() at main.c:2227)
> > >>> DEBUG1 [10239/10290]: Kernel list events done (61 events) (in
> > >>> kernel_list_events() at kernel.c:653)
> > >>> DEBUG1 [10239/10290]: Sending response (size: 35640, retcode:
> Success)
> > >>> (in thread_manage_clients() at main.c:3338)
> > >>> DEBUG1 [10239/10290]: Clean command context structure (in
> > >>> clean_command_ctx() at main.c:482)
> > >>> DEBUG1 [10239/10290]: Accepting client command ... (in
> > >>> thread_manage_clients() at main.c:3200)
> > >>> Kernel events:
> > >>> -------------
> > >>> block_rq_abort (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> block_rq_requeue (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> block_rq_complete (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> block_rq_insert (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> block_rq_issue (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> block_bio_bounce (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> block_bio_complete (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> block_bio_backmerge (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> block_bio_frontmerge (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> block_bio_queue (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> block_getrq (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> block_sleeprq (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> block_plug (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> block_unplug (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> block_split (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> block_bio_remap (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> block_rq_remap (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> irq_handler_entry (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> irq_handler_exit (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> softirq_entry (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> softirq_exit (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> softirq_raise (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> sched_kthread_stop (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> sched_kthread_stop_ret (loglevel: TRACE_EMERG (0)) (type:
> > >>> tracepoint)
> > >>> sched_wakeup (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> sched_wakeup_new (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> sched_switch (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> sched_migrate_task (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> sched_process_free (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> sched_process_exit (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> sched_wait_task (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> sched_process_wait (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> sched_process_fork (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> sched_stat_wait (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> sched_stat_sleep (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> sched_stat_iowait (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> sched_stat_runtime (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> sched_pi_setprio (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> signal_generate (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> signal_deliver (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> signal_overflow_fail (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> signal_lose_info (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> lttng_statedump_start (loglevel: TRACE_EMERG (0)) (type:
> > >>> tracepoint)
> > >>> lttng_statedump_end (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> lttng_statedump_process_state (loglevel: TRACE_EMERG (0))
> (type:
> > >>> tracepoint)
> > >>> lttng_statedump_file_descriptor (loglevel: TRACE_EMERG (0))
> (type:
> > >>> tracepoint)
> > >>> lttng_statedump_vm_map (loglevel: TRACE_EMERG (0)) (type:
> > >>> tracepoint)
> > >>> lttng_statedump_network_interface (loglevel: TRACE_EMERG (0))
> > >>> (type: tracepoint)
> > >>> lttng_statedump_interrupt (loglevel: TRACE_EMERG (0)) (type:
> > >>> tracepoint)
> > >>> timer_init (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> timer_start (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> timer_expire_entry (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> timer_expire_exit (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> timer_cancel (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> hrtimer_init (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> hrtimer_start (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> hrtimer_expire_entry (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> hrtimer_expire_exit (loglevel: TRACE_EMERG (0)) (type:
> tracepoint)
> > >>> hrtimer_cancel (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> itimer_state (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>> itimer_expire (loglevel: TRACE_EMERG (0)) (type: tracepoint)
> > >>>
> > >>> root at android:/data/lttng/bin #
> > >>>
> > >>> Now I'm facing the issue of starting the traces:
> > >>> debugging the sessiond, consumerd and lttng I concluded that the
> issue
> > >>> is due to splice system call failure.
> > >>> even using a MMAP output type channel, the metadata channel is SPLICE
> > >>> type (hard-coded).
> > >>> Problem persists also when using relayd to pass the traces through
> the
> > >>> network.
> > >>> Ignoring the splice failure means closing of the metadata channel
> > >>> (maybe??) but need not affect the traces channel (right ?)
> > >>> Attached is a debug log of each thread of the sessiond, right after
> > >>> invoking "*./lttng start*". (with extra informative my prints)
> > >>>
> > >>> Please keep me in touch with any progress in this issue,
> > >>> Thank you,
> > >>> Amit.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> ---------- Forwarded message ----------
> > >>> From: Amit Balboul <amit.balboul at shinesec.com>
> > >>> Date: Wed, Feb 27, 2013 at 4:37 PM
> > >>> Subject: Re: [lttng-dev] compiling LTTng for android
> > >>> To: PLSTC <b0mb00z.it at gmail.com>
> > >>>
> > >>>
> > >>> Hey Pierre,
> > >>>
> > >>> Some major progress has been achieved, following is the summary:
> > >>>
> > >>> 1. Modules issue:
> > >>> I built (for ARM/Android) and installed latest stable version of
> busybox
> > >>> on the device.
> > >>> Seeing the code tries to run (hardcoded) /sbin/modprobe, made a soft
> > >>> link to busybox's modeprobe.
> > >>> Also, created /lib/modules/<version+build> directory and pushed the
> > >>> <version+build> directory from /lib/modules on the machine.
> > >>> Now session daemon modprobes the desired modules successfully, (some
> are
> > >>> not present though as mentioned before) - no need to use insmod.
> > >>>
> > >>> 2. epoll_create1 issue:
> > >>> epoll_create1 patch was OK, I accidentally defined EPOLL_CLOEXEC as
> > >>> 0x02000000 instead of 02000000 (fixed).
> > >>>
> > >>> The running scenario:
> > >>>
> > >>> 1. Run ./lttng-sessiond -d -vvv
> > >>>
> > >>> Then: (commands are in bold, output is in blue for readability)
> > >>>
> > >>> root at android:/data/lttng/install_sysroot/bin # *./lttng create s1*
> > >>>
> > >>> Session s1 created.
> > >>> Traces will be written in /data/lttng-traces/s1-20130227-161145
> > >>> root at android:/data/lttng/install_sysroot/bin # *./lttng
> enable-channel
> > >>> ch -k*
> > >>> Kernel channel ch enabled for session s1
> > >>> root at android:/data/lttng/install_sysroot/bin # *./lttng
> enable-event ev
> > >>> -k -a*
> > >>> All kernel events are enabled in channel channel0
> > >>> root at android:/data/lttng/install_sysroot/bin # *./lttng list s1*
> > >>> Tracing session s1: [inactive]
> > >>> Trace path: /data/lttng-traces/s1-20130227-161145
> > >>>
> > >>> === Domain: Kernel ===
> > >>>
> > >>> Channels:
> > >>> -------------
> > >>> - channel0: [enabled]
> > >>>
> > >>> Attributes:
> > >>> overwrite mode: 0
> > >>> subbufers size: 262144
> > >>> number of subbufers: 4
> > >>> switch timer interval: 0
> > >>> read timer interval: 200
> > >>> output: splice()
> > >>>
> > >>> Events:
> > >>> None
> > >>>
> > >>> - ch: [enabled]
> > >>>
> > >>> Attributes:
> > >>> overwrite mode: 0
> > >>> subbufers size: 262144
> > >>> number of subbufers: 4
> > >>> switch timer interval: 0
> > >>> read timer interval: 200
> > >>> output: splice()
> > >>>
> > >>> Events:
> > >>> None
> > >>>
> > >>> root at android:/data/lttng/install_sysroot/bin # *./lttng list -k *
> > >>>
> > >>> Kernel events:
> > >>> -------------
> > >>>
> > >>> root at android:/data/lttng/install_sysroot/bin # *./lttng start*
> > >>> Tracing started for session s1
> > >>> root at android:/data/lttng/install_sysroot/bin # *./lttng stop *
> > >>>
> > >>> Waiting for data availability
> > >>> Tracing stopped for session s1
> > >>> root at android:/data/lttng/install_sysroot/bin #
> > >>>
> > >>> *Now: (this is not surprising because the kernel events list is
> > >>> empty...)*
> > >>> the folder /data/lttng-traces/s1-20130227-161145/kernel contains:
> > >>> total 0
> > >>> -rwxrwxrwx 1 0 0 0 Feb 27 14:18 ch_0
> > >>> -rwxrwxrwx 1 0 0 0 Feb 27 14:18 ch_1
> > >>> -rwxrwxrwx 1 0 0 0 Feb 27 14:18 channel0_0
> > >>> -rwxrwxrwx 1 0 0 0 Feb 27 14:18 channel0_1
> > >>> -rwxrwxrwx 1 0 0 0 Feb 27 14:18 metadata
> > >>>
> > >>> *By the way:*
> > >>> When running the same scenario but creating the channel with
> *--output
> > >>> mmap*, still no data but the size of the first two files in the
> traces
> > >>> directory are 4Kb (I didn't bother to investigate them as I assume
> it is
> > >>> just the header - not the traces payload).
> > >>>
> > >>> Another issue: at this point, listing the sessions gives:
> > >>> root at android:/data/lttng/install_sysroot/bin # *./lttng list s1 *
> > >>>
> > >>> Tracing session s1: [inactive]
> > >>> Trace path: /data/lttng-traces/s1-20130227-161145
> > >>>
> > >>> === Domain: Kernel ===
> > >>>
> > >>> Error: No kernel consumer detected
> > >>> 99|root at android:/data/lttng/install_sysroot/bin # *./lttng list -k
> *
> > >>>
> > >>> Error: Unable to list kernel events
> > >>> Error: Command error
> > >>> 1|root at android:/data/lttng/install_sysroot/bin #
> > >>>
> > >>> So currently I'm facing these issues:
> > >>> 1. Kernel events list is empty.
> > >>> 2. Listing the session/ kernel events after creating session,
> channel,
> > >>> event, start, stop - results in "no kernel consumer detected"
> > >>>
> > >>> If you have some insights please share them with me..
> > >>>
> > >>> Thanks
> > >>>
> > >>> Amit.
> > >>>
> > >>>
> > >>> On Tue, Feb 26, 2013 at 7:35 PM, PLSTC <b0mb00z.it at gmail.com> wrote:
> > >>>
> > >>>> The modules you can't find are the same I am also missing I
> believe; I
> > >>>> think they are only compiled when certain kernel config defines are
> met
> > >>>> (and those might simply be unavailable under ARM).
> > >>>>
> > >>>> As for what you pointed in your first mail, I believe modprobe isn't
> > >>>> available on ARM, did you mean that some modules were not found
> when using
> > >>>> insmod?
> > >>>>
> > >>>> For the epoll_create1 problem, what kind of patch did you apply to
> add
> > >>>> support for the epoll_create1 function?
> > >>>>
> > >>>>
> > >>>> On Tue, Feb 26, 2013 at 11:29 AM, Amit Balboul <
> > >>>> amit.balboul at shinesec.com> wrote:
> > >>>>
> > >>>>> Ok I got :
> > >>>>> lttng-kretprobes.ko
> > >>>>> lttng-kprobes.ko
> > >>>>> , the other two are missing.
> > >>>>>
> > >>>>>
> > >>>>> ---------- Forwarded message ----------
> > >>>>> From: Amit Balboul <amit.balboul at shinesec.com>
> > >>>>> Date: Tue, Feb 26, 2013 at 5:49 PM
> > >>>>> Subject: Re: [lttng-dev] compiling LTTng for android
> > >>>>> To: PLSTC <b0mb00z.it at gmail.com>
> > >>>>>
> > >>>>>
> > >>>>> One more thing:
> > >>>>>
> > >>>>> The list of modules you gave my is not identical to mine:
> > >>>>> a. I pushed the modules from my machine to my folder in the device
> > >>>>> (not to /system/lib) as you directed me, and insmoded them
> manually.
> > >>>>> b. I pushed the whole tree under /lib/modules/<KERNEL_VER_BUILD>/
> > >>>>> which includes the modules.* and the sub directories:
> > >>>>>
> > >>>>> /lib/modules/3.0.31-gd5a18e0/extra$ ll
> > >>>>> total 2464
> > >>>>> drwxr-xr-x 4 root root 4096 Feb 26 15:58 ./
> > >>>>> drwxr-xr-x 3 root root 4096 Feb 26 15:58 ../
> > >>>>> drwxr-xr-x 2 root root 4096 Feb 26 15:58 lib/
> > >>>>> -rw-r--r-- 1 root root 167184 Feb 26 15:58
> > >>>>> lttng-ring-buffer-client-discard.ko
> > >>>>> -rw-r--r-- 1 root root 167206 Feb 26 15:58
> > >>>>> lttng-ring-buffer-client-mmap-discard.ko
> > >>>>> -rw-r--r-- 1 root root 178586 Feb 26 15:58
> > >>>>> lttng-ring-buffer-client-mmap-overwrite.ko
> > >>>>> -rw-r--r-- 1 root root 178564 Feb 26 15:58
> > >>>>> lttng-ring-buffer-client-overwrite.ko
> > >>>>> -rw-r--r-- 1 root root 137179 Feb 26 15:58
> > >>>>> lttng-ring-buffer-metadata-client.ko
> > >>>>> -rw-r--r-- 1 root root 137233 Feb 26 15:58
> > >>>>> lttng-ring-buffer-metadata-mmap-client.ko
> > >>>>> -rw-r--r-- 1 root root 213451 Feb 26 15:58 lttng-statedump.ko
> > >>>>> -rw-r--r-- 1 root root 1314235 Feb 26 15:58 lttng-tracer.ko
> > >>>>> drwxr-xr-x 2 root root 4096 Feb 26 15:58 probes/
> > >>>>>
> > >>>>> /lib/modules/3.0.31-gd5a18e0/extra/lib$ ll
> > >>>>> total 732
> > >>>>> drwxr-xr-x 2 root root 4096 Feb 26 15:58 ./
> > >>>>> drwxr-xr-x 4 root root 4096 Feb 26 15:58 ../
> > >>>>> -rw-r--r-- 1 root root 738964 Feb 26 15:58 lttng-lib-ring-buffer.ko
> > >>>>>
> > >>>>> /lib/modules/3.0.31-gd5a18e0/extra/probes$ ll
> > >>>>> total 2872
> > >>>>> drwxr-xr-x 2 root root 4096 Feb 26 15:58 ./
> > >>>>> drwxr-xr-x 4 root root 4096 Feb 26 15:58 ../
> > >>>>> -rw-r--r-- 1 root root 162872 Feb 26 15:58 lttng-probe-asoc.ko
> > >>>>> -rw-r--r-- 1 root root 171049 Feb 26 15:58 lttng-probe-block.ko
> > >>>>> -rw-r--r-- 1 root root 81165 Feb 26 15:58
> lttng-probe-compaction.ko
> > >>>>> -rw-r--r-- 1 root root 333215 Feb 26 15:58 lttng-probe-ext4.ko
> > >>>>> -rw-r--r-- 1 root root 80413 Feb 26 15:58 lttng-probe-gpio.ko
> > >>>>> -rw-r--r-- 1 root root 84256 Feb 26 15:58 lttng-probe-irq.ko
> > >>>>> -rw-r--r-- 1 root root 135453 Feb 26 15:58 lttng-probe-jbd2.ko
> > >>>>> -rw-r--r-- 1 root root 105399 Feb 26 15:58 lttng-probe-kmem.ko
> > >>>>> -rw-r--r-- 1 root root 76240 Feb 26 15:58 lttng-probe-lttng.ko
> > >>>>> -rw-r--r-- 1 root root 88059 Feb 26 15:58 lttng-probe-module.ko
> > >>>>> -rw-r--r-- 1 root root 154032 Feb 26 15:58 lttng-probe-napi.ko
> > >>>>> -rw-r--r-- 1 root root 142038 Feb 26 15:58 lttng-probe-net.ko
> > >>>>> -rw-r--r-- 1 root root 93564 Feb 26 15:58 lttng-probe-power.ko
> > >>>>> -rw-r--r-- 1 root root 85530 Feb 26 15:58 lttng-probe-regulator.ko
> > >>>>> -rw-r--r-- 1 root root 138121 Feb 26 15:58 lttng-probe-sched.ko
> > >>>>> -rw-r--r-- 1 root root 152909 Feb 26 15:58 lttng-probe-scsi.ko
> > >>>>> -rw-r--r-- 1 root root 107491 Feb 26 15:58 lttng-probe-signal.ko
> > >>>>> -rw-r--r-- 1 root root 142711 Feb 26 15:58 lttng-probe-skb.ko
> > >>>>> -rw-r--r-- 1 root root 181983 Feb 26 15:58 lttng-probe-statedump.ko
> > >>>>> -rw-r--r-- 1 root root 126731 Feb 26 15:58 lttng-probe-timer.ko
> > >>>>> -rw-r--r-- 1 root root 86591 Feb 26 15:58 lttng-probe-workqueue.ko
> > >>>>> -rw-r--r-- 1 root root 133886 Feb 26 15:58 lttng-probe-writeback.ko
> > >>>>> -rw-r--r-- 1 root root 30863 Feb 26 15:58 lttng-types.ko
> > >>>>>
> > >>>>> Looking at the files shows I miss:
> > >>>>> lttng-kretprobes.ko
> > >>>>> lttng-kprobes.ko
> > >>>>> lttng-ftrace.ko
> > >>>>> lttng-probe-kvm.ko
> > >>>>>
> > >>>>>
> > >>>>> On Tue, Feb 26, 2013 at 3:56 PM, PLSTC <b0mb00z.it at gmail.com>
> wrote:
> > >>>>>
> > >>>>>> Back on the last email:
> > >>>>>>
> > >>>>>> Here's the insmod list I ended up building; you might not have
> > >>>>>> compiled all those modules, depending on your kernel config and
> on the
> > >>>>>> architecture used, so some might simply be absent from your output
> > >>>>>> directory.
> > >>>>>>
> > >>>>>> insmod /system/lib/modules/lttng-types.ko
> > >>>>>> insmod /system/lib/modules/lttng-kretprobes.ko
> > >>>>>> insmod /system/lib/modules/lttng-kprobes.ko
> > >>>>>> insmod /system/lib/modules/lttng-ftrace.ko
> > >>>>>> insmod /system/lib/modules/lttng-lib-ring-buffer.ko
> > >>>>>> insmod /system/lib/modules/lttng-statedump.ko
> > >>>>>> insmod /system/lib/modules/lttng-tracer.ko
> > >>>>>> insmod /system/lib/modules/lttng-probe-timer.ko
> > >>>>>> insmod /system/lib/modules/lttng-probe-statedump.ko
> > >>>>>> insmod /system/lib/modules/lttng-probe-signal.ko
> > >>>>>> insmod /system/lib/modules/lttng-probe-sched.ko
> > >>>>>> insmod /system/lib/modules/lttng-probe-lttng.ko
> > >>>>>> insmod /system/lib/modules/lttng-probe-kvm.ko
> > >>>>>> insmod /system/lib/modules/lttng-probe-irq.ko
> > >>>>>> insmod /system/lib/modules/lttng-probe-block.ko
> > >>>>>> insmod
> /system/lib/modules/lttng-ring-buffer-metadata-mmap-client.ko
> > >>>>>> insmod /system/lib/modules/lttng-ring-buffer-metadata-client.ko
> > >>>>>> insmod /system/lib/modules/lttng-ring-buffer-client-overwrite.ko
> > >>>>>> insmod
> /system/lib/modules/lttng-ring-buffer-client-mmap-overwrite.ko
> > >>>>>> insmod
> /system/lib/modules/lttng-ring-buffer-client-mmap-discard.ko
> > >>>>>> insmod /system/lib/modules/lttng-ring-buffer-client-discard.ko
> > >>>>>>
> > >>>>>>
> > >>>>>> We also haven't had time recently to test if the
> kprobes/kretprobes
> > >>>>>> worked, but they probably do; we decided to focus a bit more on
> the
> > >>>>>> 'tracepoints' aspect instead.
> > >>>>>>
> > >>>>>> Anyway, good luck with your exploration, and if you find something
> > >>>>>> interesting, I'd love to know more about it!
> > >>>>>>
> > >>>>>> -PL
> > >>>>>>
> > >>>>>> On Tue, Feb 26, 2013 at 8:06 AM, PLSTC <b0mb00z.it at gmail.com>
> wrote:
> > >>>>>>
> > >>>>>>> Hey Amit,
> > >>>>>>>
> > >>>>>>> Good news indeed it seems!
> > >>>>>>>
> > >>>>>>> When it comes to pushing the libs/bin, we haven't found any
> better
> > >>>>>>> way than using adb push yet; of course, if all the projects were
> included
> > >>>>>>> directly in Android's external, we would simply flash the device
> after each
> > >>>>>>> build, but currently we're still having trouble generating the
> correct
> > >>>>>>> Android makefiles.
> > >>>>>>>
> > >>>>>>> As for the modules, I might still have a dep load list somewhere
> I
> > >>>>>>> could send you in a few hours, I remember fighting to get the
> order right...
> > >>>>>>>
> > >>>>>>> Also, once everything loads, could you tell me what kind of
> output
> > >>>>>>> 'lttng list -k' provides you? Here, we're having trouble listing
> the
> > >>>>>>> 'default' kernel trace points provided by HAVE_TRACEPOINTS, and
> the
> > >>>>>>> returned list is simply empty (which is a bit strange).
> > >>>>>>>
> > >>>>>>> -PL
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >
>
> > _______________________________________________
> > lttng-dev mailing list
> > lttng-dev at lists.lttng.org
> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20130317/3c4d6034/attachment-0001.html>
More information about the lttng-dev
mailing list