Needed for __BEGIN_DECLS/__END_DECLS. Currently fine because it's being
included after other files that do this.
Change-Id: I1f12368fc461f6ef5ca90992cf19f317f0b5d7af
Removes the leading underscores from __android_set_abort_message() and
moves its declaration into a public header file.
Bug: 17059126
Change-Id: I470c79db47ec783ea7a54b800f8b78ecbe7479ab
<features.h> is supposed to take user-settable stuff like _GNU_SOURCE
and _BSD_SOURCE and turn them into __USE_GNU and __USE_BSD for use in
the C library headers. Instead, bionic used to unconditionally define
_BSD_SOURCE and _GNU_SOURCE, and then test _GNU_SOURCE in the header
files (which makes no sense whatsoever).
Bug: 14659579
Change-Id: Ice4cf21a364ea2e559071dc8329e995277d5b987
Fix and use __RENAME (and lose ___RENAME --- two underscores should be
enough for anybody). This was the point of this change, because I want
to use __RENAME to support the two basename variants and the two
strerror_r variants.
Lose a bunch of macros that weren't being used.
Lose three dead files from the DNS code.
Change-Id: I3ef645c566b16a52217bc2e68c7d54b37c7c9522
1. Add test for __attribute__((constructor/destructor))
and static constructor
2. Compile C++ testlibs with -std=gnu++11
Change-Id: I67f9308144a0c638a51f111fcba8e1933fe0ba41
This is an alternate, somewhat simpler, fix that makes it safe to
include both <atomic> and <stdatomic.h> from C++ code in either order.
It means that C code consistently uses one implementation of atomics
and C++ another. We still have to make sure that those two
implementations interoperate correctly at runtime; in particular,
any flavor of atomic object needs to be represented exactly like the
underlying type, with the proper alignment constraint.
Bug:17007799
Change-Id: Iffcfc5220d8fa150f89dd083a121b24d23f268fc
Reduce randomization of the test by (1) replacing random() & 255
with hard-coded char and (2) by making State *Iteration function
visit every possible alignment combination instead of 10 random ones.
Change-Id: I0ff0b4ca817ba9fbbcce53e09b25eb10a1a853c2
Glibc calls theirs __ctype_get_mb_cur_max. Make ours match to cut down
on differences between bionic and glibc.
Bug: 11156955
Change-Id: Ib7231f01aa9676dff30aea0af25d597bfe07bc73
Also scan NDK's unwanted symbols list (to show the things that we're
exporting but the NDK isn't. Symbols hidden in the NDK will be marked
with a *.
Add a -u (--unwanted) flag to disable the first two printed groups
(all symbols in bionic, all symbols in glibc). This is helpful when
wanting to grep in the list of unwanted symbols.
Finally, update the list of known differences between us and glibc.
Change-Id: I6fdb4126823098430454763c391bd8cd369a75bb
Do not run symbol lookup on already visited soinfos
Not taking into account already visited libraries
dramatically slows down dlsym in cases when there
are multiple occurrences of a large library in
dependency tree.
Bug: 16977077
Change-Id: I1379f30ed8b06758dd1cc76b80833ac8589afa50
Now that -Bsymbolic is fixed, we can hide __libc_malloc_dispatch without
breaking ASAN.
Bug: 11156955
Change-Id: Ia2fc9b046a74e666b33aa6c6c5435f70a63b8021
The old definition only worked for functions that didn't use numbered
local labels. Upstream uses '666' not only as some kind of BSD in-joke,
but also because there's little likelihood of any function having
labels that high.
There's a wider question about whether we actually want to go via the
PLT at all in this code, but that's a question for another day.
(cherry-pick of 72d7e667c7e926cb120c4edb53cbf74c652ab915.)
Bug: 16906712
Change-Id: I3cd8ecc448b33f942bb6e783931808ef39091489
Add an ordering constraint/fence to __system_property_serial.
This slows down a read on a Nexus 5 from about 50 to about 70 ns,
but avoids the possibility of seeing an inconsistent property value.
Use C11 atomic operations where easy and appropriate.
This code remains not fully C++11 memory model conformant, but
I would now expect the generated code to now be correct with current compilers.
Bug:14970171
Change-Id: I0891ff1d0f914ae5c3857e3d76b6a7c8a4a07d83
ifuncs now work in i386 and x86_64 when called in the same library as
well as in a different library.
Bug:6657325
Change-Id: Ic0c48b1b0a76cb90f36c20c79f68294cc3fd44a1
