generic-library/bionic
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update the comments to reflect the current status.

Browse Source 
Change-Id: I3a6348b568230fe8b21d121e5b8d30561a9703c2
This commit is contained in:
Ben Cheng 2013-08-02 15:33:27 -07:00
parent a6ed05c1c4
commit 772b797b7b
1 changed files with 14 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
libc/arch-arm/bionic/libgcc_compat.c
View File

@ -30,8 +30,8 @@
* dynamic linker to copy their definition into the final libc.so binary. * dynamic linker to copy their definition into the final libc.so binary.
* *
* They are required to ensure backwards binary compatibility with * They are required to ensure backwards binary compatibility with
* Android 1.5, 1.6 and even 3.0 system images. Some applications built * libc.so provided by the platform and binaries built with the NDK or
* using the NDK require them to be here. * different versions/configurations of toolchains.
* *
* Now, for a more elaborate description of the issue: * Now, for a more elaborate description of the issue:
* *
@ -48,7 +48,9 @@
* gcc <options> -o libfoo.so foo.a libgcc.a -lc -lm * gcc <options> -o libfoo.so foo.a libgcc.a -lc -lm
* *
* This ensures that any helper function needed by the code in foo.a is copied * This ensures that any helper function needed by the code in foo.a is copied
* into the final libfoo.so. Unfortunately, the Android build system has been * into the final libfoo.so. However, doing so will link a bunch of other __cxa
* functions from libgcc.a into each .so and executable, causing 4k+ increase
* in every binary. Therefore the Android platform build system has been
* using this instead: * using this instead:
* *
* gcc <options> -o libfoo.so foo.a -lc -lm libgcc.a * gcc <options> -o libfoo.so foo.a -lc -lm libgcc.a
@ -58,9 +60,10 @@
* into libfoo.so. Instead, a symbol import definition will be added to it * into libfoo.so. Instead, a symbol import definition will be added to it
* so libfoo.so can directly call the one in libc.so at runtime. * so libfoo.so can directly call the one in libc.so at runtime.
* *
* When changing toolchains for 2.0, the set of helper functions copied to * When refreshing toolchains for new versions or using different architecture
* libc.so changed, which resulted in some native shared libraries generated * flags, the set of helper functions copied to libc.so may change, which
* with the NDK to fail to load properly. * resulted in some native shared libraries generated with the NDK or prebuilts
* from vendors to fail to load properly.
* *
* The NDK has been fixed after 1.6_r1 to use the correct link command, so * The NDK has been fixed after 1.6_r1 to use the correct link command, so
* any native shared library generated with it should now be safe from that * any native shared library generated with it should now be safe from that
@ -73,6 +76,11 @@
* but it is easier to add a single function here than asking several app * but it is easier to add a single function here than asking several app
* developers to fix their build. * developers to fix their build.
* *
* The __aeabi_idiv function is added to the list since cortex-a15 supports
* HW idiv instructions so the system libc.so doesn't pull in the reference to
* __aeabi_idiv but legacy libraries built against cortex-a9 targets still need
* it.
*
* Final note: some of the functions below should really be in libm.so to * Final note: some of the functions below should really be in libm.so to
* completely reflect the state of 1.5/1.6 system images. However, * completely reflect the state of 1.5/1.6 system images. However,
* since libm.so depends on libc.so, it's easier to put all of * since libm.so depends on libc.so, it's easier to put all of