Mbstowcs and wcstombs cannot get correct return value when called in the environment below api 21, and need to raise the API level to solve the problem.
Test: None
fix bug 1108 https://github.com/android/ndk/issues/1108
Change-Id: Iabcf1bff0be087288646687732ef68870630b48a
They're in glibc, though not in musl.
Also add basic doc comments to the whole of <sys/uio.h>.
Bug: http://b/203002492
Test: treehugger
Change-Id: Ic607f7f349e5b7c9bf66c25b7bd68f827da530d6
Also delete some fdsan code that attempts to check for the post-fork
state, but never will, because we update the cached pid upon fork.
Bug: http://b/174542867
Test: /data/nativetest64/bionic-unit-tests/bionic-unit-tests
Test: treehugger
Change-Id: I9b748dac9de9b4c741897d93e64d31737e52bf8e
In order to disable memory initialization for a process, the following
command can be used:
android_mallopt(M_DISABLE_MEMORY_MITIGATIONS, nullptr, 0);
Since this is needed in vendor processes, this is exposing this
functionality to llndk. For convenience (and adding standard logging),
a helper function is being added into libcutils in order to use this,
w/o having to get into so many details.
Bug: 166675194
Test: use function from libcutils
Change-Id: Ia816089a9f3469c50c70afaa7244abeac5a51dcd
Introduce an android_mallopt(M_DISABLE_MEMORY_MITIGATIONS) API call
that may be used to disable zero- or pattern-init on non-MTE hardware,
or memory tagging on MTE hardware. The intent is that this function
may be called at any time, including when there are multiple threads
running.
Disabling zero- or pattern-init is quite trivial, we just need to set
a global variable to 0 via a Scudo API call (although there will be
some separate work required on the Scudo side to make this operation
thread-safe).
It is a bit more tricky to disable MTE across a process, because
the kernel does not provide an API for disabling tag checking in all
threads in a process, only per-thread. We need to send a signal to each
of the process's threads with a handler that issues the required prctl
call, and lock thread creation for the duration of the API call to
avoid races between thread enumeration and calls to pthread_create().
Bug: 135772972
Change-Id: I81ece86ace916eb6b435ab516cd431ec4b48a3bf
This is already covered by the existing test by virtue of being used for
all threads.
Bug: http://b/168258494
Test: treehugger
Change-Id: I5c872fd7f30a4c79de1d70e7702f4b12d4e94cd3
(Based on proposal at https://sourceware.org/glibc/wiki/ThreadPropertiesAPI)
This includes API to:
- locate static and dynamic TLS
- register thread-exit and dynamic TLS creation/destruction callbacks
Change-Id: Icd9d29a5b2f47495395645e19d3b2c96826f19c8
POSIX added these GNU extensions for issue 8.
I've made these always inline without the usual "until API level X"
proviso because they're single instructions that the compiler can inline
and there's really no point providing these if they add function call
overhead --- everyone should just use __builtin_ffs() and friends
instead in that case.
Bug: https://austingroupbugs.net/view.php?id=617
Test: treehugger
Change-Id: I33fc4b8648ea25917329e81c1b4c60eb9a66d667
This function will be used by Scudo and GWP-ASan to efficiently collect
stack traces for frames built with frame pointers.
Bug: 135634846
Bug: 135772972
Change-Id: Ic63efdbafe11dfbb1226b5b4b403d53c4dbf28f3
Merged-In: Ic63efdbafe11dfbb1226b5b4b403d53c4dbf28f3
Add a hook that's called upon file descriptor creation to libc, and a
library that uses it to capture backtraces for file descriptor creation,
to make it easier to hunt down file descriptor leaks.
Currently, this doesn't capture all of the ways of creating a file
descriptor, but completeness isn't required for this to be useful as
long as leaked file descriptors are created with a function that is
tracked. The primary unhandled case is binder, which receives file
descriptors as a payload in a not-trivially-parsable byte blob, but
there's a chance that the leak we're currently trying to track down
isn't of a file descriptor received over binder, so leave that for
later.
Bug: http://b/140703823
Test: manual
Change-Id: I308a14c2e234cdba4207157b634ab6b8bc539dd9
(cherry picked from commit b7eccd4b15)
This supports the soong commit which causes most platform binaries to stop
statically linking against the unwinder implementation. The soong commit
message has more motivation for this change.
ARM32 uses LLVM libunwind, while all other platforms use libgcc as the
unwinder implementation. This matches the current choices of unwinders on
the various architectures, but means that apps which were directly linking
against the libc.so unwinder symbols on ARM32 are now using LLVM libunwind
instead of libgcc.
Set libc_headers sdk_version to 1 so that libunwind_llvm can depend on it,
and stop statically linking libunwind into libc_malloc_debug.
Bug: 144430859
Change-Id: I52c7f7893d93f500383aeb0b76086c3b6f1935a5
This commit removes several symbol versions (API 14 and 15) from
`libc.map.txt` because we no longer support NDK with those API levels.
This also matches the versioner annotations in the header files.
This commit also annotates twalk() with __INTRODUCED_IN(21). It was
accidentally removed in aosp/1157510.
Test: source development/vndk/tools/header-checker/android/envsetup.sh && \
source build/envsetup.sh && \
lunch aosp_arm64-userdebug && \
m versioner && \
./bionic/tools/versioner/run_tests.py
Change-Id: I211fe5b7b1b66793d5e76a8676f9d18825f96b5e
We have data that indicates that we no longer need to export the libgcc
unwinder's implementation detail symbols from libc.so, as well as the entire
unwinder interface from libm.so, so stop exporting them.
Bug: 144430859
Change-Id: Iebb591c4a121abe6368d9854ec96819abe70a006
The APIs that are tagged with # vndk are actually for LLNDK libraries.
Although LLNDK is part of VNDK, calling those APIs 'vndk' has given
users a wrong perception that the APIs don't need to be kept stable
because that's the norm for most of the VNDK libraries that are not
LLNDK.
In order to eliminate the misunderstanding, rename the tag to 'llndk' so
that people introducing new such API will realize what they are signing
themselves up for.
Bug: 143765505
Test: m
Merged-In: I56e49876410bd43723a80d0204a9aef21d20fca9
(cherry picked from commit 3e2cd44aa4)
Change-Id: I56e49876410bd43723a80d0204a9aef21d20fca9
As of I2037548cc2061e46c379931588194c21dfe234b4, these are no longer
used. Since they're new in R, we can remove them instead of keeping
backwards compat 'forever'. Take that opportunity now.
Bug: 141267932
Test: TreeHugger
Change-Id: I13f94cdcff6e75ad19b964be76445f113f79559b
These are old enough now that the latest devices will have kernels that
support them.
Also add basic doc comments to <sys/mman.h>.
Test: treehugger
Change-Id: I1b5ff5db0b6270f5c374287cac1d6a751a0259f5
This also adds _2-variants for these functions, for extra glorious
checking
Bug: 131861088
Test: mma
Change-Id: I80475ff4bb220c0c47894e9532426f53412f176f
Historical research (see bug) suggests that these functions were all in
22. The map file believed this with one (presumably typoed) exception,
but the header file didn't match the map file. It looks like the map was
correct (modulo the one typo), so fix up all the disagreement.
Bug: http://b/113618851
Test: treehugger
Change-Id: Ia579f4e6163206abfac79aa54dc98c792f00ee86
Add the malloc symbols used by libmemunreachable to the VNDK, and
make libc_malloc_debug_backtrace vendor_available.
Bug: 132302484
Test: m checkbuild
Change-Id: Ide555195afa084c13eaeaf0eab6ff90787b5f2d0
Added get_malloc_leak_info and free_malloc_leak_info for arm 32 bit
only so that the kindle app will continue to run.
Bug: 132175052
Test: Ran kindle app, read pdf file. Verified libKindleReaderJNI.so
Test: is loaded in memory properly.
Change-Id: Ib1ea3a37b3729f9bcc2739c5f3a584ea8f66d200
Merged-In: Ib1ea3a37b3729f9bcc2739c5f3a584ea8f66d200
(cherry picked from commit 235f35a266)
FreeBSD, glibc, and musl have all implemented C11 threads at this
point. POSIX is looking at how to align with it. Probably time to jump
on the bandwagon ourselves...
Implemented in the same style as <termios.h> so we can provide this
functionality even on older API levels. This does mean that this is
strictly more expensive than calling pthread functions directly.
Although this isn't in POSIX yet, assume that it's going to be basically
the same as C11 and add the header test anyway. We should revisit this
when POSIX actually adds <threads.h>.
Test: new tests
Change-Id: I8602d67ce71ca7f8ed1529daa0a8ea1feb083dd6
Bug: 130028357
Test: malloc_hooks unit tests.
Test: Enable backtrace for mediaserver, run dumpsys media.player -m
Test: Enable backtrace for calendar, run am dumpheap -n <PID> <FILE>
Change-Id: I6774e28ccd9b3f2310127a5b39ccd15fe696a787
Merged-In: I6774e28ccd9b3f2310127a5b39ccd15fe696a787
(cherry picked from commit 3aadc5e80a)
Remove this global variable and change the setting of it to non-zero
to a call to android_mallopt.
In addition, change the initialize function to use pass a bool* instead of
int*.
Bug: 130028357
Test: Ran malloc_debug/malloc_hooks/perfetto tests.
Change-Id: I20d382bdeaaf38aac6b9dcabea5b3dfab3c945f6
Merged-In: I20d382bdeaaf38aac6b9dcabea5b3dfab3c945f6
(cherry picked from commit 5225b342f0)
Introduce an M_SET_ALLOCATION_LIMIT enumerator for android_mallopt(),
which can be used to set an upper bound on the total size of all
allocations made using the memory allocation APIs.
This is useful for programs such as audioextractor and mediaserver
which need to set such a limit as a security mitigation. Currently
these programs are using setrlimit(RLIMIT_AS) which isn't exactly
what these programs want to control. RLIMIT_AS is also problematic
under sanitizers which allocate large amounts of address space as
shadow memory, and is especially problematic under shadow call stack,
which requires 16MB of address space per thread.
Add new unit tests for bionic.
Add new unit tests for malloc debug that verify that when the limit
is enabled, malloc debug still functions for nearly every allocation
function.
Bug: 118642754
Test: Ran bionic-unit-tests/bionic-unit-tests-static.
Test: Ran malloc debug tests and perfetto integration tests.
Change-Id: I735403c4d2c87f00fb2cdef81d00af0af446b2bb
After switching libm from libgcc to libcrt.builtins, some of the symbols
are no longer getting included in libm, causing the compiler to complain
about missing symbols from the version script. Explicitly export them in
libc (since libm depends on libc).
Bug: 122993571
Test: m checkbuild
Test: bionic-unit-tests
Change-Id: Ie91765874d20df605f557b1a8c4236619553c549
With the switch to libcrt.builtins, some symbols no longer becomes
exported. Add dummy references to them to force them to be exported.
This is to maintain backwards binary compatibility with ancient Android
versions.
x86 and x86_64 crashes with libcrt, keep using libgcc for now.
Test: bionic-unit-tests
Bug: 29275768
Bug: 122993569
Change-Id: Ieab5af354e3924af4a03d888b28c6e75090cb613
Initialize a thread's DTV to an empty zeroed DTV. Allocate the DTV and
any ELF module's TLS segment on-demand in __tls_get_addr. Use a generation
counter, incremented in the linker, to signal when threads should
update/reallocate their DTV objects.
A generation count of 0 always indicates the constant zero DTV.
Once a DTV is allocated, it isn't freed until the thread exits, because
a signal handler could interrupt the fast path of __tls_get_addr between
accessing the DTV slot and reading a field of the DTV. Bionic keeps a
linked list of DTV objects so it can free them at thread-exit.
Dynamic TLS memory is allocated using a BionicAllocator instance in
libc_shared_globals. For async-signal safety, access to the
linker/libc-shared state is protected by first blocking signals, then by
acquiring the reader-writer lock, TlsModules::rwlock. A write lock is
needed to allocate or free memory.
In pthread_exit, unconditionally block signals before freeing dynamic
TLS memory or freeing the shadow call stack.
ndk_cruft.cpp: Avoid including pthread_internal.h inside an extern "C".
(The header now includes a C++ template that doesn't compile inside
extern "C".)
Bug: http://b/78026329
Bug: http://b/123094171
Test: bionic unit tests
Change-Id: I3c9b12921c9e68b33dcc1d1dd276bff364eff5d7
On user builds, heapprofd should only be allowed to profile apps that
are either debuggable, or profileable (according to the manifest). This
change exposes extra zygote-specific knowledge to bionic, and makes the
dedicated signal handler check for the special case of being in a zygote child.
With this & the corresponding framework change, we should now be
handling the 4 combinations of:
{java, native} x {profile_at_runtime, profile_at_startup}.
See internal go/heapprofd-java-trigger for further context.
Test: on-device unit tests (shared & static) on blueline-userdebug.
Test: flashed blueline-userdebug, confirmed that java profiling activates from startup and at runtime.
Bug: 120409382
Change-Id: Ic251afeca4324dc650ac1d4f46976b526eae692a
(cherry picked from commit 998792e2b6)
Merged-In: Ic251afeca4324dc650ac1d4f46976b526eae692a
This reverts commit 220f51e566.
The internal modules that were using extra symbols are all fixed.
Bug: 120266448
Test: m ndk_translation_all in cf_x86_phone
Change-Id: I561b16de1c320d2624e7cf8e6211e0c70edc823d
By default, Clang uses this arm32 function to read the thread pointer,
either for ELF TLS or via __builtin_thread_pointer(). It's probably better
to inline the cp15 access using -mtp=cp15, but that's not the default yet.
See https://reviews.llvm.org/D34878?id=114573.
Bug: http://b/78026329
Test: bionic unit tests
Change-Id: I93b8926075f0b2cea8df9ef518d54f2820a8ff5b
Following additional symbols are temporarily exposed from the runtime APEX
to satisfy the dependencies from other non-AOSP modules. This will be
reverted when the modules are built with the boostrap bionic libraries.
Bug: 120266448
Test: m
Change-Id: I39ac40a40545723ea2aeb185b9cd293d511f802f
Bionic libs are part of the runtime APEX (com.android.runtime). In order
to be able to update the runtime APEX independetly from the platform, we
have to prevent things outside of the APEX from using bionic symbols
that are not guaranteed to be stable. Otherwise, platform could break
when a symbol is removed from the libs via the APEX update.
To achive this goal, this change adds stubs variant to the bionic libs.
With this, things outside of the runtime APEX (i.e. other APEXes and the
platform) are built with the stubs variants that provide only the
symbols that are guaranteed to be stable.
The set of symbols are basically the same as the symbols available to
NDK clients. However, there are a few additional symbols that are not
available for NDK but should be made available for platform components.
They are marked with "# apex" tag. Symbols with that tag are not exposed
to apps (via NDK stubs) or vendors (via LLNDK stubs).
Note that the stubs is a build-time only artifact. It is used just to
break the build when private symbols are used outside of the runtime
APEX. At runtime, the real library in the APEX is used.
Bug: 120266448
Test: m
Test: m bionic-unit-tests
Change-Id: I7b8d75830c81d7d7d54e2fca21a85b3417531b47
Originally a BSD extension, now in glibc too. We've used it internally
for a while.
(cherry-pick of e4b13f7e3ca68edfcc5faedc5e7d4e13c4e8edb9.)
Bug: http://b/112163459
Test: ran tests
Change-Id: I813c3a62b13ddb91ba41e32a5a853d09207ea6bc
Merged-In: I813c3a62b13ddb91ba41e32a5a853d09207ea6bc
