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.org> wrote:

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