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
Bero,
On 26/04/13 22:17, Bernhard Rosenkränzer wrote:
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.
So technically if you don't provide these functions somewhere in your toolchain you aren't ABI compliant. And this hack looks odd.
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.
Has the symbol visibility of __aeabi_uidiv changed?
What are you building for? Cortex-A15 and -A7 have divide instructions, so you might have issues there.
It might also be worth seeing what libgcc_s looks like in 4.7 and 4.8 and see what has changed about the objects there.
Thanks,
Matt
Hi, I've looked into this some more today... But it still looks rather odd.
On 2 May 2013 10:23, Matthew Gretton-Dann matthew.gretton-dann@linaro.orgwrote:
Bero,
On 26/04/13 22:17, Bernhard Rosenkränzer wrote:
__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.
So technically if you don't provide these functions somewhere in your toolchain you aren't ABI compliant. And this hack looks odd.
True, but it seems to work well enough -- it makes sure the symbols are imported and used, so they get linked into the library.
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.
Has the symbol visibility of __aeabi_uidiv changed?
Apparently not... I've checked a diff between gcc-4.7/libgcc and gcc-4.8/libgcc and didn't find any changes that seem related. Given I also didn't see any relevant ABI changes, I ran a little experiment and removed libgcc.a from 4.8, and copied in libgcc.a from 4.7 (yes, I know that's pure evil ;) ).
Interestingly enough, that toolchain produces a fully functional (including blobs) Android build.
I still don't see anything relevant in the diff - but of course another difference is that 4.7's libgcc.a is compiled with 4.7 while 4.8's is compiled with 4.8, so it may be related to something 4.8 does differently while building libgcc.a.
What are you building for? Cortex-A15 and -A7 have divide instructions, so
you might have issues there.
Cortex-A9 (targeting Galaxy Nexus).
ttyl bero
On 04/05/13 00:21, Bernhard Rosenkränzer wrote:
Hi, I've looked into this some more today... But it still looks rather odd.
Has the symbol visibility of __aeabi_uidiv changed?
Apparently not... I've checked a diff between gcc-4.7/libgcc and gcc-4.8/libgcc and didn't find any changes that seem related. Given I also didn't see any relevant ABI changes, I ran a little experiment and removed libgcc.a from 4.8, and copied in libgcc.a from 4.7 (yes, I know that's pure evil ;) ).
How did you diff gcc-4.7/libgcc and gcc-4.8/libgcc? What does readelf give as the symbol types and visibility?
Interestingly enough, that toolchain produces a fully functional (including blobs) Android build.
I still don't see anything relevant in the diff - but of course another difference is that 4.7's libgcc.a is compiled with 4.7 while 4.8's is compiled with 4.8, so it may be related to something 4.8 does differently while building libgcc.a.
This looks like a linkage issue and as 4.7's libgcc works even with 4.8 built objects I think its a change in the libgcc library (and not how things are getting called - although that would be worth checking - what's the difference between the callers from both objects).
So if you could diff the objects within libgcc.a that contain __aeabi_uidiv that would be great.
Thanks,
Matt
On 7 May 2013 10:37, Matthew Gretton-Dann matthew.gretton-dann@linaro.orgwrote:
On 04/05/13 00:21, Bernhard Rosenkränzer wrote:
How did you diff gcc-4.7/libgcc and gcc-4.8/libgcc?
Checked out the sources and looked at the output of diff -urN gcc-4.7/libgcc gcc-4.8/libgcc
What does readelf give as the symbol types and visibility?
Symbol visibility does seem to have changed (even though I didn't spot it in the source)...
4.7: File: libgcc.a(_udivsi3.o) 16: 00000000 0 FUNC GLOBAL DEFAULT 1 __aeabi_uidiv
4.8: File: libgcc.a(_udivsi3.o) 16: 00000000 0 FUNC GLOBAL HIDDEN 1 __aeabi_uidiv
Will take another look to see where it changed... Either I missed it or it's a default setting outside of the libgcc directory.
ttyl bero
Bero,
So looking at how I build GCC __aeabi_uidiv is HIDDEN for 4.7 and 4.8.
Looking at the source for libgcc one way the use of the hidden attribute is determined at configure time with an assembler test.
So can you you post your libgcc/config.log somewhere for 4.7 & 4.8, and point us to them? (To save time I'm also probably going to want the complete build log at some stage for libgcc - so it is probably worth posting those as well).
In particular I am interested in the values of vs_hide and libgcc_cv_hidden_visibility_attribute.
Thanks,
Matt
On 08/05/13 10:10, Bernhard Rosenkränzer wrote:
On 7 May 2013 10:37, Matthew Gretton-Dann matthew.gretton-dann@linaro.orgwrote:
On 04/05/13 00:21, Bernhard Rosenkränzer wrote:
How did you diff gcc-4.7/libgcc and gcc-4.8/libgcc?
Checked out the sources and looked at the output of diff -urN gcc-4.7/libgcc gcc-4.8/libgcc
What does readelf give as the symbol types and visibility?
Symbol visibility does seem to have changed (even though I didn't spot it in the source)...
4.7: File: libgcc.a(_udivsi3.o) 16: 00000000 0 FUNC GLOBAL DEFAULT 1 __aeabi_uidiv
4.8: File: libgcc.a(_udivsi3.o) 16: 00000000 0 FUNC GLOBAL HIDDEN 1 __aeabi_uidiv
Will take another look to see where it changed... Either I missed it or it's a default setting outside of the libgcc directory.
ttyl bero
Hi,
On 8 May 2013 12:41, Matthew Gretton-Dann matthew.gretton-dann@linaro.orgwrote:
So looking at how I build GCC __aeabi_uidiv is HIDDEN for 4.7 and 4.8.
Odd... I always get DEFAULT __aeabi_uidiv with 4.7 and HIDDEN with 4.8.
So can you you post your libgcc/config.log somewhere for 4.7 & 4.8, and point us to them? (To save time I'm also probably going to want the complete build log at some stage for libgcc - so it is probably worth posting those as well).
I've attached the config logs - full builds are still running.
In particular I am interested in the values of vs_hide and libgcc_cv_hidden_visibility_attribute.
vs_hide isn't set in either config.log, libgcc_cv_hidden_visibility_attribute is yes in both.
ttyl bero
On 8 May 2013 15:29, Bernhard Rosenkränzer <bernhard.rosenkranzer@linaro.org
wrote:
I've attached the config logs - full builds are still running.
I've figured out what's going on.
In libgcc/Makefile.in, lines 368+ (in 4.8)/lines 375+ (in 4.7), there's some AWK trickery to add .hidden to asm code.
The difference is that in 4.7, that code is inside
ifeq ($(enable_shared),yes)
while 4.8 moved it outside of that block.
The result is that on regular Linux, you'd have the symbols hidden in both 4.7 and 4.8 -- but on Android (where for whatever reason the decision was not to have a libgcc_s), it gets hidden only in 4.8.
The problematic upstream commit is svn 190588.
I think for now I'll just revert that change in Android toolchain builds to keep the hack in Bionic working - but I wonder what a proper fix could look like (or rather, a proper fix that we can do - meaning one that doesn't involve fixing up blobs we don't have the source to or getting Android upstream to introduce libgcc_s).
ttyl bero
On 08/05/13 20:53, Bernhard Rosenkränzer wrote:
On 8 May 2013 15:29, Bernhard Rosenkränzer <bernhard.rosenkranzer@linaro.org
wrote:
I've attached the config logs - full builds are still running.
I've figured out what's going on.
In libgcc/Makefile.in, lines 368+ (in 4.8)/lines 375+ (in 4.7), there's some AWK trickery to add .hidden to asm code.
The difference is that in 4.7, that code is inside
ifeq ($(enable_shared),yes)
while 4.8 moved it outside of that block.
The result is that on regular Linux, you'd have the symbols hidden in both 4.7 and 4.8 -- but on Android (where for whatever reason the decision was not to have a libgcc_s), it gets hidden only in 4.8.
The problematic upstream commit is svn 190588.
I think for now I'll just revert that change in Android toolchain builds to keep the hack in Bionic working - but I wonder what a proper fix could look like (or rather, a proper fix that we can do - meaning one that doesn't involve fixing up blobs we don't have the source to or getting Android upstream to introduce libgcc_s).
The original discussion about this patch is here:
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01462.html
Thanks,
Matt
On 8 May 2013 22:07, Matthew Gretton-Dann matthew.gretton-dann@linaro.orgwrote:
On 08/05/13 20:53, Bernhard Rosenkränzer wrote:
The problematic upstream commit is svn 190588.
The original discussion about this patch is here:
Bug report and patch here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57221
Not too optimistic about getting the patch accepted though, since the proper fix really would be to just rebuild the *****ing blobs.
ttyl bero
linaro-toolchain@lists.linaro.org
-
Bernhard Rosenkränzer -
Matthew Gretton-Dann