[lttng-dev] Fwd: compiling LTTng for android
Mathieu Desnoyers
mathieu.desnoyers at efficios.com
Fri Mar 15 11:08:06 EDT 2013
* 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
More information about the lttng-dev
mailing list