== Progress ==
* 3.3 Release
- Running tests on Pandas and Calxeda, Ubuntu 12.04 and 12.10
- Chromebook arriving next week
- Calxedas died a couple of times this week for no reason (somebody else
turned it off?)
- Many bootstrap failures on 12.04: check-all, test-suite, etc on all
phases
- Fixing a bug that allows to bootstrap on Ubuntu 12.10
* EuroLLVM 2013
- Published the questionnaire results, wrote a post on the blog
- http://blog.llvm.org/2013/05/eurollvm-2013-paris-france.html
* Extra
- Studying C++11 atomics
== Issues ==
There's no way to tell when someone will turn the Calxeda server off, so
relying on its results or usability is folly. Not to mention that the
designers should have had a bit more care on the interface to power up and
configure nodes.
== Plan ==
* Spend the weekend testing on the Pandaboard with Ubuntu 12.10 and see if
the fix is good, commit
* Install Ubuntu on Chromebook arriving on Monday, run release tests on them
* Hope that Ubuntu 12.10 will be less hemorragic than 12.04 for the LLVM
release...
Short week (3 days)
== Progress ==
* Disable-peeling: got results vs reference, shared with team.
* Revert-coalesce vars: got results vs reference, showing regressions.
* Libsanitizer: committed upstream.
* Neon intrinsics: shared initial proposal of dejagnu-ization of my
existing tests.
* Branch reviews
* Internal support
== Next ==
* Disable-peeling: investigate regression on eon
* Revert-coalesce: discuss how to handle it with team
* Libsanitizer: enable on aarch64
* Neon intrinsics: continue improving crc with vuzp
* Neon intrinsics tests: continue dejagnu-ization
== Progress ==
* Four day week and traditional bank holiday cold slowed progress.
* Tested glibc memcpy patch on big endian and got it committed.
* Submitted some generic IFUNC patches for binutils upstream.
* Further work on AArch64 IFUNC support in binutils.
== Issues ==
* cbuild seems to not be doing much building at the moment.
== Plan ==
* Complete AArch64 IFUNC support and submit a patch.
* Look further at gdb bug if I get time.
--
Will Newton
Toolchain Working Group, Linaro
[three day week]
Progress:
* VIRT-49 [cp15 migration]
** lots of patch cleanup; nearly ready to submit but ideally
I'd like to test KVM migration with Andre's kernel changes first
** improved arndale setup by switching to USB hard disk; confirmed
I can build and boot my own kernel
* VIRT-50 [cp15 reset]
** it turns out that the VIRT-49 patches on their own break
reset handling for the KVM case, so we need to include VIRT-50
work in the same patchset. Fortunately it turns out to be a small
extension; patch done and tested, and will be submitted as part
of the VIRT-49 patchset
* misc
** discussions about early-printk in a virtual machine. I still think
it's important to be able to have a device tree binding to tell
the kernel where its early-printk uart is. Grant Likely said he
and Nico actually tossed this idea around in the past, it just
never got implemented.
Plans:
* VIRT-49/50: test against Andre's kernel timer save/load patches,
then submit
* more in-depth review and test of John Rigby's mach-virt and
aarch64 patchsets
-- PMM
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