Commits

Anonymous committed 772b797

Update the comments to reflect the current status.

Change-Id: I3a6348b568230fe8b21d121e5b8d30561a9703c2

Comments (0)

Files changed (1)

libc/arch-arm/bionic/libgcc_compat.c

  * dynamic linker to copy their definition into the final libc.so binary.
  *
  * They are required to ensure backwards binary compatibility with
- * Android 1.5, 1.6 and even 3.0  system images. Some applications built
- * using the NDK require them to be here.
+ * libc.so provided by the platform and binaries built with the NDK or
+ * different versions/configurations of toolchains.
  *
  * Now, for a more elaborate description of the issue:
  *
  *         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
- * 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:
  *
  *         gcc <options> -o libfoo.so foo.a -lc -lm libgcc.a
  * 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.
  *
- * When changing toolchains for 2.0, the set of helper functions copied to
- * libc.so changed, which resulted in some native shared libraries generated
- * with the NDK to fail to load properly.
+ * When refreshing toolchains for new versions or using different architecture
+ * flags, the set of helper functions copied to libc.so may change, which
+ * 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
  * any native shared library generated with it should now be safe from that
  * but it is easier to add a single function here than asking several app
  * 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
  *             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