GitLab

Change-Id: Ia454a2181b5058ed9783dc02b6b1805d0e4d2715
(cherry picked from commit 53c3c271)

Change-Id: I023d2d8b547fbc21d4124bb7510d42b06a0dc501

Remove the linker's reliance on BSD cruft and use the glibc-style
ElfW macro. (Other code too, but the linker contains the majority
of the code that needs to work for Elf32 and Elf64.)

All platforms need dl_iterate_phdr_static, so it doesn't make sense
to have that part of the per-architecture configuration.

Bug: 12476126
Change-Id: I1d7f918f1303a392794a6cd8b3512ff56bd6e487

The x86_64 build was failing because clone.S had a call to __thread_entry which
was being added to a different intermediate .a on the way to making libc.so,
and the linker couldn't guarantee statically that such a relocation would be
possible.

  ld: error: out/target/product/generic_x86_64/obj/STATIC_LIBRARIES/libc_common_intermediates/libc_common.a(clone.o): requires dynamic R_X86_64_PC32 reloc against '__thread_entry' which may overflow at runtime; recompile with -fPIC

This patch addresses that by ensuring that the caller and callee end up in the
same intermediate .a. While I'm here, I've tried to clean up some of the mess
that led to this situation too. In particular, this removes libc/private/ from
the default include path (except for the DNS code), and splits out the DNS
code into its own library (since it's a weird special case of upstream NetBSD
code that's diverged so heavily it's unlikely ever to get back in sync).

There's more cleanup of the DNS situation possible, but this is definitely a
step in the right direction, and it's more than enough to get x86_64 building
cleanly.

Change-Id: I00425a7245b7a2573df16cc38798187d0729e7c4

Change-Id: I2c1f3d34c33685799aade8866eec44479ff9f963

Bug: 7959813
Change-Id: I8db4b8912ba649bfe668c6f22aa44690ddd401a2

There's now only one place where we deal with this stuff, it only needs to
be parsed once by the dynamic linker (rather than by each recipient), and it's
now easier for us to get hold of auxv data early on.

Change-Id: I6314224257c736547aac2e2a650e66f2ea53bef5

The AT_RANDOM changes broke setuid / setgid executables
such as "ping". When the linker executes a setuid program,
it cleans the environment, removing any invalid environment
entries, and adding "NULL"s to the end of the environment
array for each removed variable. Later on, we try to determine
the location of the aux environment variable, and get tripped
up by these extra NULLs.

Reverting this patch will get setuid executables working again,
but getauxval() is still broken for setuid programs because of
this bug.

This reverts commit e3a49a86.

Change-Id: I05c58a896b1fe32cfb5d95d43b096045cda0aa4a

Populate the stack canaries from the kernel supplied
AT_RANDOM value, which doesn't involve any system calls.
This is slightly faster (6 fewer syscalls) and avoids
unnecessarily reading /dev/urandom, which depletes entropy.

Bug: 7959813

Change-Id: If2b43100a2a9929666df3de56b6139fed969e0f1

The dynamic linker applies relro before the preinit and init
arrays are executed, so we should be consistent for statically
linked executables.

Change-Id: Ia0a49d0e981a6e8791f74eed00280edf576ba139

Add support for getauxval().  This method allows a program an easy way
to retrieve information from the kernel auxiliary vector, and will
hopefully replace other clumsy ways of accessing this same information.

This particular function was also added to glibc in glibc 2.16.
See the following URLs for more details.

  * http://lwn.net/Articles/519085/
  * http://www.gnu.org/software/libc/manual/html_node/Auxiliary-Vector.html

This change is a prerequisite for bug 7959813.

Bug: http://code.google.com/p/android/issues/detail?id=38441
Change-Id: Iba19d899df334bddc6f4899077ece2fc87564ea8

In 9ec0f03a, we added dynamic
linker support for GNU_RELRO protections. These protections
make certain regions of memory read-only, helping protect certain
data structures from accidental or deliberate modifications.

This change adds GNU_RELRO support to STATIC executables.  We can
determine if we're compiled with relro protections by examining
our own program headers, which is passed to us by the kernel
in the AT_PHDR and AT_PHNUM auxiliary vectors.

Parts of this code were stolen from the dynamic linker.

Change-Id: Ic17eb5f932218538ec25347ece314d4dc7549de1

Several previous changes conspired to make a mess of the thread list
in static binaries. This was most obvious when trying to call
pthread_key_delete(3) on the main thread.

Bug: http://code.google.com/p/android/issues/detail?id=36893
Change-Id: I2a2f553114d8fb40533c481252b410c10656da2e

None of the supported ARCHs actually populate these sections,
so there is no point in keeping them in the binaries.

Change-Id: I21a364f510118ac1114e1b49c53ec8c895c6bc6b
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@gmail.com>

Since e19d702b, dlsym and friends use recursive mutexes that
require the current thread id, which is not available before the libc
constructor. This prevents us from using dlsym() in .preinit_array.

This change moves TLS initialization from libc constructor to the earliest
possible point - immediately after linker itself is relocated. As a result,
pthread_internal_t for the initial thread is available from the start.

As a bonus, values stored in TLS in .preinit_array are not lost when libc is
initialized.

Change-Id: Iee5a710ee000173bff63e924adeb4a4c600c1e2d

Orig-Change-Id: Ia840a19a45257128eccdcf25d105f500f2d90741
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>

Change-Id: Ia840a19a45257128eccdcf25d105f500f2d90741
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>

This change allows an executable to call its destructor functions
(declared with __attribute__((destructor))) to be properly called
when it normally exits.

Note that this is different from calling the destructors of a shared
library when it is unloaded with dlclose() or through program exit,
which are already supported.

Bug: 3106500
Change-Id: I1412ef5407f13b613fc6cb6103e0a691dbee4b1a

This change is intended to eliminate need to replace libc.so with libc_debug.so in order to enablememory allocation debugging.
This is also the first step towards implementing extended memoryallocation debugging using emulator's capabilities in monitoring memory access.

Some libc changes were preventing the initialization call from being made.
The basic problem appears to be that libc_init_common.c is only built once,
and it's only built for the non-debug libc.

This allows libc.so to run the C runtime initializer as soon as the
dynamic linker loads the shared library, i.e. before any other initializers
(e.g. static C++ constructors in other shared libraries the executable depends
on).

This also removes the bug where the initializers from the executable itself
were run twice: once by the dynamic linker, and another time by __libc_init
as defined by libc_init_dynamic.c

This reverts commit 03eabfe6.

The problem was due to the fact that, in the case of dynamic executables,
the dynamic linker calls the DT_PREINIT_ARRAY, DT_INIT and DT_INIT_ARRAY
constructors when loading shared libraries and dynamic executables,
*before* calling the executable's entry point (i.e. arch-$ARCH/bionic/crtbegin_dynamic.c)
which in turns call __libc_init() in libc.so, as defined by bionic/libc_init_dynamic.c

The latter did call these constructors array again, mistakenly.

The patch also updates the documentation of many related functions.

Also adds a new section to linker/README.TXT explaining restrictions on
C library usage.

The patch has been tested on a Dream for stability issues with
proprietary blobs:

- H264 decoding works
- Camera + Video recording works
- GPS works
- Sensors work

The tests in system/extra/tests/bionic/libc/common/test_static_cpp_mutex.cpp has been
run and shows the static C++ constructor being called only once.