Re: LTTng 2.0 pre-release for ARM
On 09/23/2011 05:00 PM, Andy Doan wrote: On 09/23/2011 06:51 AM, Turgis, Frederic wrote: Hi, Very cool. I've added this to the wiki: https://wiki.linaro.org/Resources/HowTo/LTTng Good idea ! I could move and reference page under https://wiki.linaro.org/Platform/DevPlatform/Tools if people agree. Well, I may be speaking a bit quickly as I found out https://wiki.linaro.org/KenWerner/Sandbox/LTTng that could also be merged in. Avik, Andy, Ken ? I just renamed the page and added a link from the tools page. As per Ken's work: I'm not that familiar with LTTng, so I think it might be easier for one of you guys to merge them. Hi, sorry for the delay - I've been on vacation. The wiki page (https://wiki.linaro.org/KenWerner/Sandbox/LTTng) was created when I briefly looked at the state of some developer tools an ARM Linux. The LTTng kernel stuff was an out of tree patchset that was not part of the Linaro kernel. The ARM port of the userspace tracer (UST) was not there yet. So, the wiki page just reflects the state of LTTng on ARM Linux back then. I'm not sure this is helpful for end users. According to https://wiki.linaro.org/Platform/DevPlatform/Tools/LTTng it seems the kernel part works now. The liburcu ARM port doesn't seem to be there yet. Regards Ken ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
libunwind on Android
Hi, I'm about to finish my work on libunwind [1] and I'd like to give you a brief overview on the different Android branches. The good news is that - if you don't need to unwind via DWARF debug frame information [2] - there are no additional patches required for Android. You can just pull the latest version from upstream [3], create an Android.mk and build it. This is what the "android" branch does [4]. The provided Android.mk re-uses the build system of libunwind and therefore relies on a few additional packages to be installed on the build system: autoconf libtool texlive-extra-utils. The Android.mk [5] uses autoreconf and libtool and will create three static libraries: libunwind.a libunwind-arm.a and libunwind-ptrace.a. The debuggerd of the linaro_android_2.3.5 branch requires a tiny patch [6] that adds the two libs to the LOCAL_STATIC_LIBRARIES. In case you want/prefer a classic Android.mk that doesn't use the autotools you can use the "android-2014" branch [7]. In addition to the Android.mk this one employs four header files that are normally generated by the configure script from the .in files [8]. The makefile creates static and a shared version of libunwind. The third Android related libunwind branch is called "android-20111026" [9] and exists because a Linaro-Android manifest refers to a specific commit-id of this branch. Technically it's very similar to "android-2014" but the history of the latter has been rebased. So, basically there are two ways of building libunwind for Android. Choose whatever suits your needs best. Happy unwinding! Regards Ken [1] https://wiki.linaro.org/KenWerner/Sandbox/libunwind [2] Unwinding via DWARF debug frames is nice to have but not a strict requirement on Android because most of the ELF file are stripped anyway and libunwind-ptrace can unwind the stack using the ARM specific unwind tables (-funwind-tables). Ping me if you still need the debug frame support - I've got a (hacky) patch for that on my hd. [3] http://www.nongnu.org/libunwind/download.html [4] git clone -b android git://git.linaro.org/people/kwerner/libunwind.git [5] http://git.linaro.org/gitweb?p=people/kwerner/libunwind.git;a=blob;f=Android.mk;hb=android [6] http://people.linaro.org/~kwerner/android/debuggerd/debuggerd-build.patch [7] git clone -b android-2014 git://git.linaro.org/people/kwerner/libunwind.git [8] config.h, libunwind-common.h, libunwind.h and tdep/libunwind_i.h [9] git clone -b android-20111026 git://git.linaro.org/people/kwerner/libunwind.git ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: libunwind on Android
On 11/17/2011 05:58 PM, Ken Werner wrote: Hi, I'm about to finish my work on libunwind [1] and I'd like to give you a brief overview on the different Android branches. The good news is that - if you don't need to unwind via DWARF debug frame information [2] - there are no additional patches required for Android. You can just pull the latest version from upstream [3], create an Android.mk and build it. This is what the "android" branch does [4]. The provided Android.mk re-uses the build system of libunwind and therefore relies on a few additional packages to be installed on the build system: autoconf libtool texlive-extra-utils. The Android.mk [5] uses autoreconf and libtool and will create three static libraries: libunwind.a libunwind-arm.a and libunwind-ptrace.a. The debuggerd of the linaro_android_2.3.5 branch requires a tiny patch [6] that adds the two libs to the LOCAL_STATIC_LIBRARIES. In case you want/prefer a classic Android.mk that doesn't use the autotools you can use the "android-2014" branch [7]. In addition to the Android.mk this one employs four header files that are normally generated by the configure script from the .in files [8]. The makefile creates static and a shared version of libunwind. The third Android related libunwind branch is called "android-20111026" [9] and exists because a Linaro-Android manifest refers to a specific commit-id of this branch. Technically it's very similar to "android-2014" but the history of the latter has been rebased. So, basically there are two ways of building libunwind for Android. Choose whatever suits your needs best. Happy unwinding! Regards Ken [1] https://wiki.linaro.org/KenWerner/Sandbox/libunwind [2] Unwinding via DWARF debug frames is nice to have but not a strict requirement on Android because most of the ELF file are stripped anyway and libunwind-ptrace can unwind the stack using the ARM specific unwind tables (-funwind-tables). Ping me if you still need the debug frame support - I've got a (hacky) patch for that on my hd. [3] http://www.nongnu.org/libunwind/download.html [4] git clone -b android git://git.linaro.org/people/kwerner/libunwind.git [5] http://git.linaro.org/gitweb?p=people/kwerner/libunwind.git;a=blob;f=Android.mk;hb=android [6] http://people.linaro.org/~kwerner/android/debuggerd/debuggerd-build.patch [7] git clone -b android-2014 git://git.linaro.org/people/kwerner/libunwind.git [8] config.h, libunwind-common.h, libunwind.h and tdep/libunwind_i.h [9] git clone -b android-20111026 git://git.linaro.org/people/kwerner/libunwind.git Hi, The autoconf based build approach caused trouble within the Linaro Android build (#891753). Therefore I deleted the commits that introduced the issue. The old code is still available on a new branch called android-2017. Updated footnotes: [4] git clone -b android-2017 git://git.linaro.org/people/kwerner/libunwind.git [5] http://git.linaro.org/gitweb?p=people/kwerner/libunwind.git;a=blob;f=Android.mk;hb=android-2017 Regards Ken ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Ftrace on the CA9x4 vexpress
Hi, I did some quick ftrace tests using the linaro-vexpress 2.6.35-1010.17 kernel on an ARM-Versatile Express CA9x4 board. It seems to work pretty good. I noticed only one issue with the wakeup latency tracer where /sys/kernel/debug/tracing/trace doesn't show any real information but the /sys/kernel/debug/tracing/trace_pipe does. The details can be found at: https://wiki.linaro.org/KenWerner/Sandbox/ftrace Regards Ken ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
kdump on ARM
Hi there, Does anyone know if it's possible to use kdump on an ARM board to capture a memory image of the kernel (to be later analyzed with crash for example)? I had a quick look at the kernel config options provided by the linaro-linux tree and it seems that kexec support (CONFIG_KEXEC) is there. I assume /sbin/kexec could be used to load a dump-capture kernel. Unfortunately CONFIG_CRASH_DUMP is not available, so I don't know how to configure such a kernel. Any pointers or suggestions are appreciated. Regards Ken ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: kdump on ARM
On Friday, December 10, 2010 5:54:09 pm Ken Werner wrote: > Hi there, > > Does anyone know if it's possible to use kdump on an ARM board to capture a > memory image of the kernel (to be later analyzed with crash for example)? > > I had a quick look at the kernel config options provided by the > linaro-linux tree and it seems that kexec support (CONFIG_KEXEC) is there. > I assume /sbin/kexec could be used to load a dump-capture kernel. > Unfortunately CONFIG_CRASH_DUMP is not available, so I don't know how to > configure such a kernel. Any pointers or suggestions are appreciated. I just saw that Mika Westerberg did some patches in this area. And I guess those haven't merged yet. https://lkml.org/lkml/2010/11/9/71 Ken ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro-Natty images on the PandaBoard
Hi there, When booting linaro snapshots on my PandaBoard the system hangs a few seconds after the bash prompt is shown (sometimes a little earlier). My first step was to enable magic-sysrq but the system doesn't react on them. It looks like it's already powered off - very strange. I've tried various hwpacks and headless images and also an SD-card image that works works on a pandaboard of a colleague (20110127 hwpack with 20110126 headless) but everything fails with the same symptoms. I used two different power supplies and several SD cards - also no difference. The board itself doesn't seem to be defective as the ubuntu-netbook-10.10-preinstalled-netbook-armel+omap4.img runs flawlessly for hours. I replaced the 2.6.35 omap4 kernel of the ubuntu 10.10 image with a kernel built from the latest git://git.linaro.org/ubuntu/linux-linaro- natty.git - but then the board hangs again. Attached is the output of the serial console. Any hints/suggestions on how to get the linaro kernel working on this board are much appreciated. Regards Ken Texas Instruments X-Loader 1.4.4ss (Jan 26 2011 - 10:12:48) Reading boot sector Loading u-boot.bin from mmc U-Boot 2010.12 (Jan 11 2011 - 05:00:24) CPU : OMAP4430 Board: OMAP4 Panda I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0 Using default environment In:serial Out: serial Err: serial Hit any key to stop autoboot: 0 reading boot.scr 381 bytes read Running bootscript from mmc0 ... ## Executing script at 8200 reading uImage 3636192 bytes read reading uInitrd 4497640 bytes read ## Booting kernel from Legacy Image at 8020 ... Image Name: Linux Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3636128 Bytes = 3.5 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 8160 ... Image Name: initramfs Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size:4497576 Bytes = 4.3 MiB Load Address: Entry Point: Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.37-1002-linaro-omap (buildd@actinidiaceae) (gcc version 4.5.2 (Ubuntu/Linaro ) [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP4 Panda board [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] OMAP4430 ES2.0 [0.00] SRAM: Mapped pa 0x4030 to va 0xfe40 size: 0xe000 [0.00] FIXME: omap44xx_sram_init not implemented [0.00] PERCPU: Embedded 7 pages/cpu @c0b9c000 s7712 r8192 d12768 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 117602 [0.00] Kernel command line: console=tty0 console=ttyO2,115200n8 root=UUID=c042cfbf-a219-40a2-a69d-d0be [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] allocated 2370560 bytes of page_cgroup [0.00] please try 'cgroup_disable=memory' option if you don't want memory cgroups [0.00] Memory: 463MB = 463MB total [0.00] Memory: 455056k/455056k available, 19056k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] DMA : 0xffc0 - 0xffe0 ( 2 MB) [0.00] vmalloc : 0xdd00 - 0xf800 ( 432 MB) [0.00] lowmem : 0xc000 - 0xdcf0 ( 463 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .init : 0xc0008000 - 0xc0048000 ( 256 kB) [0.00] .text : 0xc0048000 - 0xc06d9478 (6726 kB) [0.00] .data : 0xc06da000 - 0xc0738800 ( 378 kB) [0.00] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] RCU-based detection of stalled CPUs is disabled. [0.00] NR_IRQS:402 [0.00] [ cut here ] [0.00] WARNING: at /build/buildd/linux-linaro-omap-2.6.37/arch/arm/mach-omap2/clockdomain.c:868 omap2_) [0.00] clockdomain: OMAP4 wakeup/sleep dependency support is not yet implemented [0.00] Modules linked in: [0.00] [] (unwind_backtrace+0x0/0xfc) from [] (warn_slowpath_common+0x54/0x64) [0.00] [] (warn_slowpath_common+0x54/0x64) from [] (warn_slowpath_fmt+0x30/0x40) [0.00] [] (warn_slowpath
Re: Linaro-Natty images on the PandaBoard
On Monday, January 31, 2011 5:45:28 pm Tom Gall wrote: > Hi Ken, > > FWIW I'm running fairly recent linaro images on my pandaboard with success. > > hwpack in my case was from 0119. > > Your boot log looks pretty much like mine does, warnings and all. Hi Tom, Thanks for the info. First I thought I might have to do with the image creation process (different l-m-c versions for example). So I asked Dave Gilbert to sent me an SD card image that works on his PandaBoard. It's really strange but it shows the same behaviour on my board as the images I created myself. This could indicated that my board has issues. But on the other side the Ubuntu 10.10 system is running fine. There is one thing I noticed when the board "hangs" and doesn't react on anything: It seems that the temperature of the CPU/Memory is getting down quite fast and two LEDs are off. Maybe it's powered off already? Regards Ken ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro-Natty images on the PandaBoard
On Monday, January 31, 2011 11:17:35 pm Michael Hudson-Doyle wrote: > On Mon, 31 Jan 2011 19:28:35 +0100, Ken Werner wrote: > > On Monday, January 31, 2011 5:45:28 pm Tom Gall wrote: > > > Hi Ken, > > > > > > FWIW I'm running fairly recent linaro images on my pandaboard with > > > success. > > > > > > hwpack in my case was from 0119. > > > > > > Your boot log looks pretty much like mine does, warnings and all. > > > > Hi Tom, > > > > Thanks for the info. First I thought I might have to do with the image > > creation process (different l-m-c versions for example). So I asked Dave > > Gilbert to sent me an SD card image that works on his PandaBoard. It's > > really strange but it shows the same behaviour on my board as the images > > I created myself. This could indicated that my board has issues. But on > > the other side the Ubuntu 10.10 system is running fine. > > There is one thing I noticed when the board "hangs" and doesn't react on > > anything: It seems that the temperature of the CPU/Memory is getting down > > quite fast and two LEDs are off. Maybe it's powered off already? > > This sounds like > https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/708883 > to me. Thanks for the pointer - the symptoms are matching. I've disabled watchdog and and USB support from the kernel but the board still hangs. Regards Ken ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Usefulness of GCC's 64bit __sync_* ops on ARM
Hi, We've been thinking about adding support for the built-in functions for 64bit atomic memory access and I'd like to know if this is of any interest. Currently the main use of these functions seems to be to implement (SMP safe) locking mechanisms where the existent 32bit memory ops are sufficient. However, there might be code out there that implements a parallel algorithm using 64bit atomic memory operations. Currently the GCC ARM backend doesn't provide a pattern to inline 64bit __sync_* functions but the compiler emits __sync_*_8 function calls [1]. The libgcc does not provide these symbols via the usual thin wrapper around the kernel helper [2] because the ARM Linux __kernel_cmpxchg supports 32bit only. My understanding is that for ARMv7 the GCC backend could be enhanced to inline the __sync_* functions by using the LDREXD and STREXD instructions. But for ARMv5 we would still rely on a new kernel helper. Any ideas/thoughts are appreciated. [1] https://wiki.linaro.org/WorkingGroups/ToolChain/AtomicMemoryOperations#GCC [2] https://wiki.linaro.org/WorkingGroups/ToolChain/AtomicMemoryOperations#implementation_details Regards Ken ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Usefulness of GCC's 64bit __sync_* ops on ARM
On Friday, May 06, 2011 5:25:46 pm Richard Earnshaw wrote: > On Fri, 2011-05-06 at 17:06 +0200, Ken Werner wrote: > > Hi, > > > > We've been thinking about adding support for the built-in functions for > > 64bit atomic memory access and I'd like to know if this is of any > > interest. Currently the main use of these functions seems to be to > > implement (SMP safe) locking mechanisms where the existent 32bit memory > > ops are sufficient. However, there might be code out there that > > implements a parallel algorithm using 64bit atomic memory operations. > > I've been told (though I've not verified it) that the Membase NoSQL > database needs 64-bit atomic operations to work effectively > (http://www.membase.org/downloadsrc) Interesting... ..Thanks! > R. Regards Ken ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Usefulness of GCC's 64bit __sync_* ops on ARM
On 05/19/2011 12:40 PM, David Rusling wrote: Is this going to end up in a blueprint? This is the last loose end of SMP / atomic memory operations work and I'd like to see it happen Hi, Yep, there is one (kind of a skeleton) in place at: https://blueprints.launchpad.net/linaro-toolchain-misc/+spec/64-bit-sync-primitives Regards Ken ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Cortex A8 code analysis tool
On 05/24/2011 12:04 AM, Christian Robottom Reis wrote: I just noticed today an online code cycle analyzer that targets the Cortex-A8: http://pulsar.webshaker.net/ccc/index.php?lng=us Does anyone know who the author of that is, and whether he'd be interested in doing an A9 update? Interesting. I've had a quick play with the tool and it seems to display the amount of cycles for each instruction plus some pipelining infos in the left most column. This blog entry has a brief description: http://pulsar.webshaker.net/2011/05/15/program-to-count-the-cycles-of-the-a8-cortex-v0-7 . It looks like it doesn't know the dmb and ldrex/strex instructions (however, I'm not sure if makes sense to count cycles for these). The author seems to be Etienne Sobole: http://www.linkedin.com/in/webshaker Regards Ken ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Usefulness of GCC's 64bit __sync_* ops on ARM
On 05/25/2011 03:17 PM, Dave Martin wrote: On Wed, May 25, 2011 at 12:58:30PM +0100, David Gilbert wrote: On 25 May 2011 04:45, Nicolas Pitre wrote: FWIW, here's what the kernel part might look like, i.e. for compatibility with pre ARMv6k systems (beware, only compile tested): OK, so that makes a eglibc part for that pretty easy. For things like fetch_and_add (which I can see membase needs) would you expect implementation using this cmpxchg so it has a fall back or just to use ldrexd directly which I assume would be somewhat more efficient. (Question holds for both eglibc and gcc's __sync_*) It depends on the baseline architecture for the build. An eglibc built for ARMv6 and above would need to call the helper by default, though it could also use ldrexd/strexd if it determines at run- time that this is supported by the CPU. Similarly, if GCC is building for -march=marmv7-a it can inline the atomics directly using ldrex/strex and friends, but for -march=armv6 it will need to call helpers via libgcc. I would have thought that the libc does not decide this directly but just calls the GCC __sync_* routines (if build with a GCC that supports them). Then the GCC decides whether to inline them using ldrexd/strexd (ARMv6+) or emit calls to libgcc which calls the kernel helpers. Regards Ken ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Likely gcc-linaro-4.5-2011.05 misoptimization in libgui (Android)
On 05/27/2011 01:20 PM, Alexander Sack wrote: Hi Jim, On Fri, May 27, 2011 at 1:06 PM, Jim Huang wrote: Hello list, If you build Android using gcc-linaro-4.5-2011.05 [1], you will encounter a problem that bootanimation shows endless. It results from the mis-optimization in libgui, which handles the operations in Android SensorManager. To work around this problem, you can apply the following patch: --- a/libs/gui/Android.mk +++ b/libs/gui/Android.mk @@ -18,6 +18,8 @@ LOCAL_SHARED_LIBRARIES := \ LOCAL_MODULE:= libgui +LOCAL_CFLAGS += -O0 + in channel you said that -O1 is also working ... do we need O0 here? one idea would be to make a list of all optimizations that come for O2 and then spin builds with adding one at a time ... in that way we can narrow down things. Not sure if that would be helpful for fixing the issue. Hi there, I've got an android build system up and running and had a quick look into this. When using the gcc-linaro-4.5-2011.05-0 the bootanimation runs forever when compiling the libgui.so using -O[s|1|2]. For me it only works when disabling all optizations (-O0). So, I've started with -O0 and tried to bisect the various optimization switches but I didn't fail. Next I've started with -O1 and disabled all the optimizations but it didn't pass. So, this approach was a dead end. Then I realized that the build system employs some sort of a prelinker called apriori. Adding 'LOCAL_PRELINK_MODULE := false' to the makefile disables the prelink step. And the resulting ELF binary finally worked (tested with -O[s|1|2]). It would be good to understand the root cause of this because the workaround probably has drawbacks at run (load) time. Apriori gets two input files. The prelink-linux-arm.map which lists the start of the prelink addresses: libui.so0xAB90 # [~1M] libgui.so 0xAB80 # [~1M] libskia.so 0xAB10 # [~2M] and the libgui.so to be prelinked. I'd expect to see the resulting PhysAddr's somewhere nearby 0xAB80 but this doesn't seem to be the case somehow. In order to exclude a miscompiled apriori, I've prelinked libgui using an apriori binary build with the prebuilt gcc44 - no difference. Therefore I don't think gcc is miscompiling but something went wrong whith the prelink step. But still - the android prelinking remains a mystery to me as I don't know what is supposed to be prelinked and what is actually failing. However, I think we are one step further. Regards Ken project frameworks/base/ diff --git a/libs/gui/Android.mk b/libs/gui/Android.mk index 249558a..3bc7eaa 100644 --- a/libs/gui/Android.mk +++ b/libs/gui/Android.mk @@ -16,6 +16,8 @@ LOCAL_SHARED_LIBRARIES := \ libhardware \ libhardware_legacy +LOCAL_PRELINK_MODULE := false + LOCAL_MODULE:= libgui ifeq ($(TARGET_SIMULATOR),true) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: android-toolchain-eabi-4.5-2011.05 fail to compile dalvik
On 06/10/2011 09:17 AM, Barry Song wrote: we will find many compiling error like: "break strict-aliasing rules", "used uninitialized in this function" and so on. all those actually are warnings which become errors due to -Werror option. A patch like the below can make compiling pass, but we feel strange why old toolchain has no this issue. Hi Barry, I also encountered that the Android code violates the C aliasing rules. As GCC evolves it gets more strict about those errors. The fact that a GCC 4.4 based toolchain didn't complain doesn't necessarily mean that there were no bugs. :) As a workaround you may add -fno-strict-aliasing to the CFLAGS (and remove -fstrict-aliasing). There is a branch called 'dev_toolchain_preview_1105' that employs these changes. On my system it builds with the gcc-linaro-4.5-2011.05-0. However, there are at least two knows issues: 1) The boot animation runs forever. This seems to be related to prelinking and libgui.so. A workaround is to disable prelinking for that module as posted at: http://lists.linaro.org/pipermail/linaro-dev/2011-June/004993.html 2) The libaudioflinger.so segfaults. A workaround seems to build this module with -O1. Both issues are under investigation by the Linaro Android and Toolchain teams. Regards Ken ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
