GitLab

This patch ensures that the shell system libraries that are
generated by gen-platforms.sh never ever expose any symbol from
libgcc.a.

Fact is that libgcc.a is linked against any shared library on
Android (be it a system or application library). Because the
symbols in this library don't have hidden visibility by default,
they get re-exported by the binaries (e.g. /system/lib/libc.so
exports __div0 or _Unwind_Resume).

When using the standalone toolchain, one can naively do something
like the following:

  gcc -shared -o libfoo.so foo.o -lc

Which gcc will translate as a link command that looks like:

  ld -o libfoo.so foo.o $SYSROOT/usr/lib/libc.so /path/to/libgcc.a

In this case, references in foo.o to symbols like __div0, which
are automatically created by the compiler under various circumstances,
will result in a dynamic import for the '__div0' symbol, that will
be looked inside the system libc.so at runtime.

This is problematic because when we upgrade the toolchain used to
build the system, we change the set of libgcc symbols exported by
/system/lib/libc.so, and this may result in ABI breakages.

What we want instead is for libfoo.so to have its own copy of
__div0 et al. If our shell library in $SYSROOT/usr/lib/libc.so
doesn't export the symbol, its code will be taken from libgcc.a
and added to libfoo.so directly.

Note that when we use the NDK build system, it ensures that libgcc.a
is placed before any shared library in the final link command, i.e.
that something like the following is used:

  ld -o libfoo.so foo.o /path/to/libgcc.a $SYSROOT/usr/lib/libc.so

In this case, the problem doesn't exist because our build system
enforces the correct ordering. This cannot be guaranteed when using
the standalone toolchain unless this change is implemented.

Change-Id: Ic195d21fe56c7118366c2536efa5fc264a7fb263