[lttng-dev] compiling LTTng for android

Thu Feb 21 13:37:57 EST 2013

Hey Amit,

For the gettid issue, we were considering adding a #ifndef __ANDROID__ (all
mentions of gettid in urcu) #endif type of solution (which seems to work
for us at the moment), which also brings us to the last point: __ANDROID__
should be defined by default whenever you compile with the NDK's toolchain
(we have not added this variable anywhere ourselves and so far, it's been
very useful in all the projects). As for the patch itself, I personally
have no clue if this would break any convention already in place for
liburcu/LTTng in general; we have not been pushing any part of our
progression so far as nothing as been tested, and some changes we made
locally are extremely device/version specific (and would most likely
break functionalities in other environments).

For the syscall.h issue, we avoided including directly
"$SYSROOT/usr/include/sys",
since some files in that folder are not safe to use directly (see errno.h
and statfs.h for example). This seems to be the 'agreed-upon' logic used in
the AOSP source tree; possible alternatives are setting up new Android
#ifdef barriers in liburcu itself, or trying to push an empty, logically
linked  syscall.h file (identical the above errno.h and statfs.h) to
"$SYSROOT/usr/include"
(which would probably not be accepted in the AOSP source).

If your next plan after liburcu is porting the LTTng modules to Android,
you'll most likely hit the missing kernel config options (syscall/hook
related) in 3.0.x like we did; this will require some specific patching we
have yet to complete. This work has been done in Torvalds's kernel
(post-3.5 I believe, see his git for more info), but considering how
different the current Android device kernels still are from the official
ones, we might still have a lot to do.

On another note, we peeked a little bit into porting UST to Android, but
here again, replacing the SysV shmem implementation by Android's ashmem
proved a lot more complicated than we had anticipated. Currently, we are
only focusing on kernel tracing, so LTTng-modules + liburcu + LTTng-tools.
So far, we successfully built the modules (with limited support), liburcu
and the tools (also with limited support), but we have yet to start tracing.

Feel free to ask away if you have any more questions, although other people
on the mailing list might have better answers for LTTng-related questions.

-PL

On Thu, Feb 21, 2013 at 12:08 PM, Amit Balboul <amit.balboul at shinesec.com>wrote:

> Hey Pierre,
> Thank you for the fast response.
>
> I'm also using the pre-built NDK environment (r8d),
> I continue to work on it, I'll let you know if I'm still having those
> errors.
> About the "static inline pid_t gettid(void)" issue:
> I cannot find any better solution than modifying the userspace-rcu sources
> to avoid static declaration.
> I dont see the connection to building to Android, because unistd.h
> "extern"s gettid anyway, so it cannot be defined as static in any of the
> files (i just removed the "static" from the inline definition).
>
> How do you want me to make this patch ?
>
> About the syscall.h issue:
> applying the SYSROOT/usr/include/sys folder AFTER the SYSROOT/usr/include
> in the CPPFLAGS solves the issue (looks like it is better than the link
> solution).
>
> About the __ANDROID__ definition:
> May I add this symbol to configure.ac and use it in the sources, ?
>
>
> Amit.
>
>
>
>
> On Thu, Feb 21, 2013 at 3:18 PM, Pierre-Luc St-Charles <
> pierre-luc.st-charles at polymtl.ca> wrote:
>
>> Forwarded to mailing list:
>>
>> Hey Amil,
>>
>> Sorry we kept you out of the loop, we've been struggling on some issues
>> in the later projects; as for liburcu, we've come across the same problems
>> you cited, except the last one:
>>     - syscall.h / lpthread / gettid : your solutions, or a #ifdef
>> __ANDROID__ barrier, seems to work as a temp fix.
>>     - rand_r : after substituting for the regular (not-thread-safe) rand,
>> we decide to go with our own implementation, but the one you found might
>> actually be better
>>     - rpl_malloc : same fix here, but we also found
>> that ac_cv_func_realloc_0_nonnull *might* also help in some cases (along
>> with ac_cv_func_malloc_0_nonnull)
>>
>> As for the __sync_synchronize error, we haven't encountered those and we
>> managed to successfully build the library.
>>
>> Possible differences:
>> We opted for AOSP's own pre-built & packaged NDK toolchain, (which can be
>> found here: http://developer.android.com/tools/sdk/ndk/index.html) and
>> pointed the sysroot variable to its platforms/android-14/arch-arm/
>> directory (latest). By default, it doesn't include some
>> module/kernel headers, but it should be enough for liburcu. We are
>> currently considering adding the liburcu project itself (along with the
>> others) directly in the android external modules, so that it may be
>> compiled with exactly the SAME settings as the rest of the
>> libraries/binaries/modules, using the same NDK (but for that, we'll need to
>> drop the autoconf/automake stuff, and that's another story).
>>
>> The rest should be identical, we might have used some extra parameters
>> here and there that might be based on our environment in the build process,
>> but here they are anyway:
>>     in ./configure, add : --target=arm-linux-androideabi
>> --prefix=$SYSROOT/usr
>>     make sure you provide $SYSROOT/usr/lib instead of $SYSROOT/lib as the
>> default library path
>>
>> Keep us informed if the problem still happens, we'll try to debug your
>> issue further.
>>
>> On Thu, Feb 21, 2013 at 5:13 AM, Amit Balboul <amit.balboul at shinesec.com>wrote:
>>
>>> Hi all,
>>>
>>> In continue to posts from
>>> http://www.mail-archive.com/lttng-dev@lists.lttng.org/msg02542.html,
>>>
>>> I'm trying to build the LTTng kernel-tracer for Android on ARM:
>>> (JB4.2.1 - kernel 3.0.31 - on Galaxy Nexus).
>>> I'm having some trouble completing the process, didn't find any usable
>>> information so far, maybe u can help.
>>>
>>> I want to build the: (I've managed in the past to build the modules for
>>> goldfish's 2.6.29 but this required patching the kernel).
>>> (1) userspace-rcu
>>> (2) modules
>>> (3) tools
>>> I'm currently stuck in the first phase (building userspace-rcu).
>>>
>>> My steps and the issues I've encountered are:
>>> 1. Clone the userspace-rcu git repository
>>> 2. Generate a sysroot for arm-linux-androideabi from google's NDK (using
>>> its "make-standalone-toolchain.sh" script with arm-linux-androideabi-4.4.3
>>> toolchain).
>>> 3. Run ./bootstrap - creating config.h.in, Makefile.in, configure, ...
>>> 4. Run ./configure with --host=arm-linux-androideabi and the relevant
>>> environment variables (CC, LD, CPPFLAGS, CFLAGS, LDFLAGS, LIB), pointing to
>>> the NDK ARM SYSROOT.
>>> 5. Run make
>>>
>>> Some errors I encoutered and their fixes (workarounds), while trying as
>>> much as I can leave the sources untouched:
>>> 1. syscall.h not found. In some files, the <syscall.h> is included. In
>>> NDK SYSROOT the syscall.h lays in sys/
>>> FIX: created a link: SYSROOT/include/syscall.h ->
>>> SYSROOT/include/sys/syscall.h
>>> 2. Android's libraries includes the pthread lib automatically, thus not
>>> having a stand-alone pthread library.
>>> FIX: removed "-lpthread" from Makefile.am, tests/Makefile.am
>>> 3. static declaration of "gettid" follows non-static declaration (in
>>> SYSROOT/include/unistd.h, "gettid" is declared as "external")
>>> For the mean time I commented this declaration... Maybe adding "#ifndef
>>> gettid" before the declaration of  "static gettid" in the sources will fix
>>> it ?
>>> 4. rand_r not declared - added a module that implements rand_r (as seen
>>> in
>>> https://github.com/xbmc/xbmc/tree/master/xbmc/android/bionic_supplement)
>>> 5. undefined reference to rpl_malloc
>>> FIX: setting ac_cv_func_malloc_0_nonnull=yes before launching
>>> ./configure.
>>>
>>> now, after running ./configure and make, still not completed. I get many
>>> "undefined reference to __sync_syncronize" messages. the
>>> urcu/arch/generic.h defines the memory barriers functions as cmm_* but
>>> their implementation is not taken from urcu/arch/arm.h but from Line 46 in
>>> the same file (generic.h).
>>> Can u help with this?
>>> Am I missing something here ?
>>>
>>> Also, how does the build system use the kernel 3.0.31 (or any other)
>>> sysroot ?
>>>
>>> Thank you
>>>
>>> Amit.
>>>
>>> _______________________________________________
>>> lttng-dev mailing list
>>> lttng-dev at lists.lttng.org
>>> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20130221/728f6332/attachment-0001.html>