All,
During Connect the suggestion was made that each working group should have
its own IRC Channel for discussions and topics relating to the group in
particular (as opposed to #linaro which is 'generic' Linaro conversations).
Therefore I have just set up #linaro-tcwg on Freenode for the Toolchain
Working Group.
This channel is public and open to anyone who wants to talk with the TCWG
group about anything toolchain related.
Thanks,
Matt
--
Matthew Gretton-Dann
Toolchain Working Group, Linaro
Hi,
I'm running into an interesting problem with driver blobs when building
Android with the 4.8 toolchain:
E/libEGL ( 1219):
load_driver(/vendor/lib/egl/libEGL_POWERVR_SGX540_120.so): Cannot load
library: soinfo_link_image(linker.cpp:1635): could not load library
"libIMGegl.so" needed by "libEGL_POWERVR_SGX540_120.so"; caused by
soinfo_link_image(linker.cpp:1635): could not load library "libsrv_um.so"
needed by "libIMGegl.so"; caused by soinfo_relocate(linker.cpp:975): cannot
locate symbol "__aeabi_uidiv" referenced by "libsrv_um.so"...
__aeabi_uidiv is a libgcc.a function (Android doesn't have libgcc_s) - and
the blob makers didn't link libgcc.a properly, so it is understandable why
this would be missing.
However, Android's libc has an ugly but (up until now) working workaround
that is supposed to address this sort of issue.
It includes libgcc_compat.c, which comes down to
#define COMPAT_FUNCTIONS_LIST \
XX(__aeabi_uidiv) \
... (same for other libgcc functions)
#define XX(f) extern void f(void);
COMPAT_FUNCTIONS_LIST
#undef XX
void __bionic_libgcc_compat_hooks(void)
{
#define XX(f) f();
COMPAT_FUNCTIONS_LIST
#undef XX
}
Running nm on libc.so shows the symbol is actually in libc.so, and it seems
to be visible.
$ nm /system/lib/libc.so |grep aeabi_uidiv
0004f5d8 t __aeabi_uidiv
0004f680 t __aeabi_uidivmod
libsrv_um.so is linked to libc too, so it should see it...
$ objdump -x /vendor/lib/libsrv_um.so |grep libc.so
NEEDED libc.so
Can anyone think of a reason why this would work fine if the system is
built with the 4.7 toolchain, but break with 4.8?
My first thought was that 4.8 might have miscompiled the dynamic linker -
but the problem remains if I copy in /system/bin/linker from the 4.7 build.
ttyl
bero
Hi,
I'm trying to build the aarch64 tool chain from source on a Redhat machine. I see that build.mk in the crosstool package requires a few .deb packages. If I want to build this on a Redhat machine, what are the changes I have to do?
Thanks,
Kalai
Hi,
I am looking for pre-build (binary, tar) GCC for native ARM e.g. I need to
use in Angstrom FS and panda board to compile the code.
Thanks & regards,
Sukumar
Hi,
I am trying to compile Qt 4.8 for ARMv8. I need following packages.
libqt4-dev libqt4-opengl-dev libphonon-dev libicu-dev libsqlite3-dev
libxext-dev libxrender-dev gperf libfontconfig1-dev libphonon-dev
libpng12-dev libjpeg62-dev
I could not find these or any such packages on Linaro website. Is there any
website which maintains packages compiled for ARMv8?
I downloaded Qt4.8 source code. But it seems I need to do many hacks to get
it compiled for ARMv8. Is it already available some where?
Any help will be appreciated.
Thanks
Aparna
== Progress ==
* Compared gdb test suite results in arm native none and arm remote
gdbserver configurations. Filled up the googledoc sheet with the
comparison.
* Created a patch for dwarf failures still need to sync it with gdb main
trunk and then need to test it on chrome book and submit after review.
* Investigated gdb.mi test suite failures most of them seems to be occuring
due to long delay. Will retest on chrome book and update.
* Received chrome book on Friday started configuration created a recovery
disk and SD card, facing a kernel panic for now.
* 1:1 with Matt
== Plan ==
* Complete chrome book configuration.
* Run arm test suite in different configurations on chrome book.
* Update the comparison sheet of gdb test suite results in different
configurations after running tests on chrome book.
* Public Holiday on 1st of May
== Progress ==
* AARCH64 - Gprof support.
Make GCC generate profile information (On-going).
Defined hook and macros in GCC to emit "mcount" instrumented calls.
Looked at ARM implementation and veener code in glibc which implements mcount.
Discussed with Matt, and decided to use generic "mcount"
implementation in glibc for aarch64.
The generic uses built_in_return_address. Looking at defining macros
and function which traverses
frames back and returns the desired frame address.
== Plan ==
* Continue gprof support work for Aarch64
Planned leaves:
1 May: Labor Day's holiday.
== Summary ==
- http://cards.linaro.org/browse/TCWG-14
- ran into space issues with chromebook and issues running spec2000
locally due to that. Finally reinstalled Ubuntu on 32GB card and set-up
everything.
- There is a potential issue with zero/sign extension based VRP.
- 254.gap goes into infinite loop. Investigating it.
- checked VRP for improvement of zero/sign extension (missing case
in CRC).
== Plan==
- http://cards.linaro.org/browse/TCWG-14
- Find the cause for 254.gap infinite loop and fix it.
- Find a solution to missing case in CRC
Summary:
* Enhance Linaro crosstool-ng.
Details:
1. Work with Bero to release 4.8 binary build.
2. Update Linaro crosstool-ng to use ISL/CLooG for 4.8 build (lp:1172595).
3. Rebase conditional compare experimental codes to lp:gcc-linaro/4.8.
Plan:
* Investigate the impact of conditional compare on optimizations.
Planned leaves:
* 29 April - 1 May: Labor Day's holiday.
Best Regards!
-Zhenqiang
== Issues ==
* None
== Progress ==
* Libunwind AArch64 support:
- Fixed signal frame issue.
- Sent patch upstream for review.
- Delivered patch to OE team for early testing.
* LRA on ARM and AArch64:
- Start to look at what is missing.
== Plan ==
* 3 days off next week
* Continue on LRA.