We can mark a whole version "introduced=" rather than doing every line
separately.
Bug: N/A
Test: builds
Change-Id: I3219edc755a42ce5ff6258efb744fb5e05967a3a
iOS 10 has <sys/random.h> with getentropy, glibc >= 2.25 has
<sys/random.h> with getentropy and getrandom. (glibc also pollutes
<unistd.h>, but that seems like a bad idea.)
Also, all supported devices now have kernels with the getrandom system
call.
We've had these available internally for a while, but it seems like the
time is ripe to expose them.
Bug: http://b/67014255
Test: ran tests
Change-Id: I76dde1e3a2d0bc82777eea437ac193f96964f138
This is the FreeBSD implementation, plus some tests. The FreeBSD
implementation includes the GNU extensions and seems to be what
iOS is using too, which should provide bug compatibility for app
developers.
The code unfortunately uses a lot of stack, and uses FreeBSD locale
implementation that we don't have, but it does seem better maintained
than the other BSDs.
Bug: http://b/29251134
Test: ran tests
Change-Id: Ie477b45e42a6df1319b25712098519d2b33adf67
The linux kernel requires that the ELF interpreter (runtime linker)
that's referenced by PT_INTERP be either an absolute path, or a relative
path from the current working directory. We'd prefer a relative path
from the binary, similarly to how we handle looking up shared libraries,
but that's not supported.
Instead, extract the LOAD segments from the runtime linker ELF binary
and embed them into each host bionic binary, omitting the PT_INTERP
declaration. The kernel will treat it as a static binary, and we'll use
a special entry point (linker_wrapper) to fix up the arguments passed by
the kernel before jumping to the embedded linker. From the linker's
point of view, it looks like the kernel loaded the linker like normal.
Bug: 31559095
Test: Enable host bionic, build and run libdemangle_test
Change-Id: I1753401ef91eecbf0ae3376faca31eec1c53842b
Return EAGAIN rather than aborting if we fail to set up the TLS for a new
thread.
Add a test that uses all the VMAs so we can properly test these edge cases.
Add an explicit test for pthread_attr_setdetachstate, which we use in the
previous test, but other than that has no tests.
Remove support for ro.logd.timestamp/persist.logd.timestamp, which doesn't
seem to be used, and which prevents us from logging failures in cases where
mmap fails (because we need to mmap in the system property implementation).
Bug: http://b/65608572
Test: ran tests
Change-Id: I9009f06546e1c2cc55eff996d08b55eff3482343
This also fixes a long-standing bug where the guard region would be taken
out of the stack itself, rather than being -- as POSIX demands -- additional
space after the stack. Historically a 128KiB stack with a 256KiB guard would
have given you an immediate crash.
Bug: http://b/38413813
Test: builds, boots
Change-Id: Idd12a3899be1d92fea3d3e0fa6882ca2216bd79c
(Where errno is relevant.)
Also consistently use -1 as the fd for anonymous mmaps. (It doesn't matter,
but it's more common, and potentially more intention-revealing.)
Bug: http://b/65608572
Test: ran tests
Change-Id: Ie9a207632d8242f42086ba3ca862519014c3c102
We can cut a lot of stuff out of the NDK's libandroid_support with this,
and reduce unnecessary relocations for all LP32 code. LP64 code should
be unaffected.
Bug: https://issuetracker.google.com/64450768
Bug: https://github.com/android-ndk/ndk/issues/507
Test: ran tests, plus manual readelf on the _test.o files
Change-Id: I3de6015921195304ea9c829ef31665cd34664066
strace 4.19 causes clang to emit a questionable warning:
external/strace/nlattr.c:254:35: error: format specifies type 'unsigned long' but the argument has type 'unsigned long long' [-Werror,-Wformat]
tprintf("htobe64(%" PRIu64 ")", be64toh(num));
~~~ ^~~~~~~~~~~~
bionic/libc/include/sys/endian.h💯20: note: expanded from macro 'be64toh'
#define be64toh(x) htobe64(x)
^~~~~~~~~~
bionic/libc/include/sys/endian.h:80:17: note: expanded from macro 'htobe64'
#define htobe64 __swap64
^
bionic/libc/include/sys/endian.h:48:18: note: expanded from macro '__swap64'
#define __swap64 __builtin_bswap64
^
What's happened here is:
* be64toh is __builtin_bswap64
* PRIu64 is "lu"
* __builtin_bswap64 is internally declared a "ULLiULLi"
All of which leads to the `unsigned long` != `unsigned long long` complaint.
It seems like __builtin_bswap64 should be ULiULi on 64-bit architectures,
where `long` rather than `long long` is the natural way to refer to 64-bit
types, as evidenced by the "lu" for PRIu64.
As long as clang behaves like this, though, we can work around it with a cast.
Also clean up the other casts in the file, be more consistent about whether
these function-like macros are defined with an argument, and remove an
incorrect comment.
Bug: http://b/65495954
Test: ran tests, built strace 4.19 without warnings
Change-Id: I8e06d4bf71e95d62f556eab8661033e04d487e0d
clang is the default compiler since Android nougat
Test: mma & verified it´s still build with clang
Change-Id: Id8b5361d18c1b2febb2dc6cc44502feaa08f605c
Signed-off-by: Lennart Wieboldt <lennart.1997@gmx.de>
For treble enabled devices, still return the appropriate shell depending
on whether the process is a vendor process or a system one.
Test: Manual testing: on a bullhead device, ran test programs from
/vendor/bin which used popen() and system(). The calls succeeded.
Bug: 65054230
Bug: 64516799
Merged-In: I15dfdbb107cfca7c0f92f337c9bb46b9876eb38e
Change-Id: I15dfdbb107cfca7c0f92f337c9bb46b9876eb38e
(cherry picked from commit 1e52871773)
For non-zygote spawned processes, we might want to dump the backtrace
data. Provide a method to send a signal to a process and then dump the
data to a file.
Adds a method to dump the backtrace data on exit.
Update documentation and explain format of heap dump data.
Test: Ran unit tests, enabled new options and used them.
Change-Id: Ie2fa706694160731afe02c1382b037d06df1d069
I'm unable to find a bug, but we've had requests for this internally
once or twice (though I pointed those folks at the STL), and there's
code we build for the host or in our bootloaders that would use this,
and there's reasonable-looking FreeBSD implementation ready and waiting.
Bug: N/A
Test: ran tests
Change-Id: I6ddee4b71bea4c22ed015debd31d3eaac4fcdd35
/usr/bin/python may be python3. We should respect PATH to find the python
executable so it can be locally overridden to be python2.
Test: Build libc, repo upload
Change-Id: Iaddd7cd4a1c2177c32786e4fa0fc664ab0ad36de
Also start breaking up the monolithic top level README.md, pulling the
32-bit ABI stuff out into its own file, and moving the remaining benchmark
documentation in with the rest of the benchmark documentation.
Bug: N/A
Test: N/A
Change-Id: Ic1b9995e27b5044199ed34883cc0b8faa894df0e
Because there was an accidental ABI breakage in 21, and we can't fix
the past. It seems more useful to refuse to build code that won't work
on any current or future device.
Bug: https://issuetracker.google.com/37051826
Test: builds
Change-Id: I4b5c30f899e2c7307642e2fb20e43a3ca14ae7fe
Spotted while adding syncfs(2). I'd previously seen that this file already
had names, but apparently not inspected them. A couple were missing, a
couple (pipe/pipe2) could usefully have a more specific type, and many
hadruntogethercstylenames.
Bug: http://b/64613623
Test: builds
Change-Id: I6b4a131bf51bf04825317ec481bc55e87c88c2b3
The NDK gen_stub_libs.py doesn't support introduced=P yet:
Traceback (most recent call last):
File "build/soong/cc/gen_stub_libs.py", line 439, in <module>
main()
File "build/soong/cc/gen_stub_libs.py", line 429, in main
versions = SymbolFileParser(symbol_file, api_map).parse()
File "build/soong/cc/gen_stub_libs.py", line 234, in parse
versions.append(self.parse_version())
File "build/soong/cc/gen_stub_libs.py", line 269, in parse_version
symbols.append(self.parse_symbol())
File "build/soong/cc/gen_stub_libs.py", line 286, in parse_symbol
tags = decode_api_level_tags(tags, self.api_map)
File "build/soong/cc/gen_stub_libs.py", line 76, in decode_api_level_tags
raise ParseError('Unknown version name in tag: {}'.format(tag))
__main__.ParseError: Unknown version name in tag: introduced=P
Bug: N/A
Test: builds
Change-Id: Ifd91e525b30f3aa9ad8c889c9564cd769a3a603a
On LP32 mem_unit will be 4096 to allow more than 4GiB in the "ulong"
fields, but we need to promote to a 64-bit type before we multiply.
Bug: N/A
Test: tested manually with an x86 static binary on my 64GiB desktop.
Signed-off-by: YiPing Xu <xuyiping@hisilicon.com>
Change-Id: Id663932503b75793bb7c26a008129f3e2e4cccbf
GMM calls this system call directly at the moment. That's silly.
Bug: http://b/36405699
Test: ran tests
Change-Id: I1e14c0e5ce0bc2aa888d884845ac30dc20f13cd5
This used to be used by the ARM longjmp implementation, but hasn't been in
libc.so for as long as we've used a linker script.
Bug: N/A
Test: builds
Change-Id: I3dff4d154d5e317955c349c9eaa08b982cbf0285
libc++ actually provides overloads for all the standard C library stuff,
so we just need to handle the POSIX and GNU extensions, of which there
are just two more: memrchr and strcasestr.
Bug: http://b/22768375
Test: builds
Change-Id: Ie9ed1fbcc794e14a0c9bba13b5307ad677949613
- Rewrite BufferOutputStream to handle 0 sized buffers and to get rid
of an unnecessary loop.
- Add tests to verify overflow corner cases.
- Implement async_safe_format_buffer to call async_safe_format_buffer_va_list
instead of duplicate the code.
Test: Ran new unit tests, booted on angler.
Change-Id: I7fb13e209f5b7443d212f55aab4b05ff2e0e8219
Library calls like system() and popen() invoke the shell executable
pointed to by '_PATH_BSHELL' in order to run the command passed into the
function. The _PATH_BSHELL points to /system/bin/sh by default and thus
breaks any vendor process trying to use system() / popen(), as they are
denied access to system shell by selinux.
This CL make necessary changes, so the implmentations of system() and popen()
can use the appropriate shell (e.g. /vendor/bin/sh for processes running
out of /vendor partition). Also, changes the implementation of system()
and popen().
Bug: 64832610
Test: Manual, Using a test program running from /system/bin and
/vendor/bin to ensure correct shell is being used.
Change-Id: Ie7168d69decb1ae98284446ae7db34dec930dc33
Merged-In: Ie7168d69decb1ae98284446ae7db34dec930dc33
Signed-off-by: Sandeep Patil <sspatil@google.com>
(cherry picked from commit aa3e32422c)
FORTIFY's *_chk functions mess with ASAN's library function
interceptors, which can apparently result in false-positives.
Since adding even more complexity to every run-time check condition in
FORTIFY doesn't seem like a great idea, and the majority of our builds
will still use FORTIFY anyway, turning FORTIFY off here seems
reasonable.
Bug: 63104159
Test: checkbuild on internal master + CtsBionicTestCases. No new
failures.
Change-Id: Id32e551e28ee70a9815ad140c3253b86f03de63f
pthread's and semaphore's default behavior is to use CLOCK_REALTIME,
however this behavior is essentially never intended, as that clock is
prone to change discontinuously.
What users really intend is to use CLOCK_MONOTONIC, however only
pthread_cond_timedwait() provides this as an option and even there, a
large amount of existing code does not opt into CLOCK_MONOTONIC.
We have seen numerous bugs directly attributable to this difference.
Therefore, we provide this general workaround to always use
CLOCK_MONOTONIC for waiting, regardless of what the input timespec
is.
Specifically this impacts the below APIs:
pthread_mutex_timedlock()
pthread_cond_timedwait()
pthread_rwlock_timedrdlock()
pthread_rwlock_timedwrlock()
sem_timedwait()
Test: boot bullhead, boot sailfish
Test: bionic pthread/semaphore unit tests
Test: check that pthread_cond_timedwait() timeouts are uneffected by
CLOCK_REALTIME time changes
Bug: 64694413
Bug: 64623895
Bug: 35756266
Bug: 35678943
Change-Id: Ibba98f5d88be1c306d14e9b9366302ecbef6d534
This reverts commit 9af9120091 (a revert
of 079bff4fa5), now the versioner bug is
fixed.
Bug: http://b/64613623 # header bug
Bug: http://b/64802958 # versioner bug
Change-Id: I1cb9d7832d4b3aecdc57a9285e2291443e59d02d
This reverts commit 079bff4fa5.
Broke builds with SANITIZE_HOST=address with an asan failure in versioner.
Change-Id: I22b113fd5405589d1a25e5e137c450aaba1ade5f
GCC's FORTIFY required optimizations to be enabled in order to function
properly. Clang's FORTIFY doesn't have this limitation, so it seems
pointless to keep it disabled due to a GCC-specific limitation.
Bug: 12231437
Test: Checkbuild on bullhead internal master + CtsBionicTestCases. No
new failures.
Change-Id: I74aa35f9d3f3d2a6b11a7adfe72a787e3d7f7f36
The versioner doesn't handle C++ blocks yet, so these guards won't be
added and it will appear as though the functions are always available
in C++, but based on API level in C.
Test: make checkbuild
Bug: https://github.com/android-ndk/ndk/issues/440
Change-Id: I31a20fa1596d836b280ffc6d7feb863afccca6c7
I've half a mind to make this a warning instead, since this sort of
call isn't UB. That said:
- if the user really wants this (I can't imagine why they would), they
can just put NULL in a non-const variable,
- we're slowly moving to -Werror ~everywhere anyway, and
- it's presumably easier to change this from an error to a warning than
the other way around
Bug: 12231437
Test: m checkbuild on bullhead internal master. No new
CtsBionicTestCases failures.
Change-Id: Ie8bf5a3455f663686fda4a7450fb35d147fa745e
The assembly in arm's generic strlen implementation contains deprecated
instruction sequence:
it eq ; start of IT block
ldreq ... ; 32-bit T32 insruction in IT block deprecated in armv8
This will cause compiler error because of -Winline-asm and -Werror.
The fix here is to change the sequence:
it eq
ldreq ...
bne 1f
to equivalent sequence:
bne 1f
ldr ...
The resulted sequence is (1 instruction) shorter.
See ARM for ARMv8 for details:
F6.2 Partial Deprecation of IT
... All uses of IT that apply to instructions other than a single
subsequent 16-bit instruction from a restricted set are deprecated, ...
Bug: 62895439
Test: "bionic-unit-tests-static --gtest_filter=*strlen*" on Nexus 4
(krait), emulator (armv7), and sailfish (armv8).
The test binary for the first 2 is built with armv7-a as its
TARGET_CPU_ARCH; The test binary for the last is built with
armv8-a as its TARGET_2ND_CPU_ARCH.
TARGET(_2ND)_CPU_VARIANTs of both binaries are set to "generic".
Change-Id: Ia2208b4e2ba2cad589975bc7b4617688cbb8826a
Since there is no 64-bit before 21, there's no need for us to talk about
bitness at all.
Bug: https://github.com/android-ndk/ndk/issues/481
Test: builds
Change-Id: I307466997df35d7f1d0eef7dc7cb35ac3033d25d
Strictly, the mode isn't really meaningful unless you supply O_EXCL,
but the kernel will take it and fstat will return it even if you
never give the file a name.
Also warn for O_TMPFILE without a mode at compile time where possible.
Bug: N/A
Test: ran tests
Change-Id: I729b6d6e6190676fd017a1190b6200bf9abdbfd8
This whole file is bogus, but if we're going to have it, we may as well
make an effort. Add LOG_NFACILITIES. Also stop using octal like it's 1970,
and so I can have some confidence that these constants are actually right.
Bug: N/A
Test: built inetutils with a modified standalone toolchain
Change-Id: Ifd6f661f87845bcc5843d68474cb836afb698058
This reverts commit ea3df0c52b, and
increases the address limit on non-aarch64 64-bit platforms as well.
RLIMIT_AS problem fixed in a different commit.
Bug: 63141434, 64293803
Test: device boots
Change-Id: I1284c4196cc1f0c9d97c3ced97a19de328050d21
This reverts commit 89d6c321f8.
Reason for revert: Still a bunch of branches/builds depending on this incorrectly.
Change-Id: I8de678848b0e5445837c02c0942f7388d27dbfd7
The ordering of __attribute__ and __asm__ matters for GCC.
Test: `#include <stdio.h>` with gcc
Bug: https://github.com/android-ndk/ndk/issues/72
Change-Id: I20bcd7cac2f96d220746e389f0ca467dc95c37c2
I was intending to change our behavior to match POSIX, but reality convinced
me otherwise.
Also add missing argument names to the header file on the assumption they'll
be shown in Studio one day.
Bug: http://b/26203902
Test: ran tests
Change-Id: I2aaea48a88d408a32925033fc8f17448fb63252e
This also has a handful of style fixups, to make this file more
consistent. And removes __bionic_zero_size_is_okay_t, since there's a
better workaround available.
Bug: 12231437
Test: m checkbuild on bionic internal master; CtsBionicTestCases show
no new failures.
Change-Id: I75a020630dbab0ce828563502900cba14ae992d1
Since realpath no longer needs to be overloaded, we can restore the
upstream source to purity. We'll be able to do this with most of the
other functions when we pull a newer clang in.
Bug: 12231437
Test: m checkbuild on bionic internal master; CtsBionicTestCases show
no new failures.
Change-Id: I484221bba0b291273fece23d2be2f5f9fd713d2c
This also throws in some reformatting to match the GCC FORTIFY style in
this file (e.g. 4 space standard indent).
Per b/36984245, some function protos are unwrapped beyond 100 chars, as
well.
Bug: 12231437
Test: m checkbuild on bionic internal master; CtsBionicTestCases show
no new failures.
Change-Id: I6dce60ec14d5cd703d9e724699634a197ca11023
Bug: 12231437
Test: m checkbuild on bionic internal master; CtsBionicTestCases show
no new failures.
Change-Id: I7dbdeca12c46d1ee3804f13546b11c3f3b3a7596
Bug: 12231437
Test: m checkbuild on bionic internal master; CtsBionicTestCases show
no new failures.
Change-Id: I4a31d9e65ed5820a581261a7e8f63a83e44936c3
Implement __freading and __fwriting, and clarify the documentation that was
the cause of these not being implemented for years.
Bug: http://b/17157253
Test: ran tests
Change-Id: I89542c8131b13889e2585417a024050ecf2abcb7
Also:
- remove a NULL check. The bug that's been working around has been
fixed since clang r298431, and our compiler is built from r300080, and
- unwrap some function prototypes, per b/36984245.
If you're interested, here's what a new error versus an old one looks
like: https://drive.google.com/file/d/0B-8OBPboNJ_4MVdlYXdJbUFBYUk/view
Bug: 12231437
Test: m checkbuild on bullhead internal master; CtsBionicTestCases show
no new failures.
Change-Id: Ibafe61198988b4c8bee8391bcdf01bcbc04233de
We've never really used __restrict: only <string.h> and <stdio.h> (which
are still very similar to upstream BSD headers) consistently have these
annotations. Neither clang nor GCC warns for trivial cases, and there's
little obvious documentation benefit.
Bug: http://b/30833514
Test: builds
Change-Id: I3e4384281865475d0c55d764b546d8166419ee31
I plan on having one review per file for the enable_if->diagnose_if
FORTIFY migration. Having this in means that no one review is dependent
on another.
Bug: 12231437
Test: m.
Change-Id: Ic0b07d7f7f6782e371c8792eb1e40cdfa32d3e35
The new kernel headers changed this and lots of parts of the tree
want the old definition, so restore the previous version.
Test: Builds.
Change-Id: I725e56bb7c51c9fcd23ebc4b67eac33d66e196e7
At least one warning only triggers in files that are included, instead
of being passed directly. Switch to compiling with -include, and fix
the resulting warnings.
Bug: https://github.com/android-ndk/ndk/issues/474
Test: mma -j && versioner
Test: python tools/versioner/run_tests.py
Change-Id: I784698c18540c9cc30f372f279a1cec1d75721ea
This patch cleans up our standard headers by moving most of the FORTIFY
cruft out in to its own sandbox. In order to include the *_chk and
*_real declarations, you can either enable FORTIFY, or `#define
__BIONIC_DECLARE_FORTIFY_HELPERS`.
Both sys/select.h and strings.h are explicitly ignored by this patch.
Both of these files have very small __BIONIC_FORTIFY blocks, and don't
define any actual FORTIFY'ed functions (just macros, and 3 *_chk
functions).
This patch also makes the versioner ignore the FORTIFY implementation
headers, since we're guaranteed to pick the FORTIFY'ed headers up when
looking at the regular headers. (...Not to mention that making the
FORTIFY'ed headers freestanding would be annoying to do and maintain for
~no benefit).
We bake the knowledge of where FORTIFY headers live directly into the
versioner. We could go with a more general approach (e.g. adding an -X
IGNORED_FILE flag that tells the versioner to ignore
$HEADER_PATH/$IGNORED_FILE), but we'd then have to repeat that for every
test, every manual invocation of the versioner, etc. for no benefit
that's obvious to me.
Bug: 12231437
Test: m checkbuild on bullhead internal master + CtsBionicTestCases. no
new errors.
Change-Id: Iffc0cc609009b33d989cdaddde0a809282131a5b
And then -Wno-gcc-compat in the right place this time. (But leaving the
other one because I don't care in the non-crtbegin code either.)
Bug: N/A
Test: builds without warnings now
Change-Id: Id2cfa3392ee80c045644ebfdf92c6d341db90964
Old versions of Android called these fdprintf and vfdprintf out of
fears that the glibc names would collide with user debug printfs.
Allow users to just use dprintf and vfdprintf on any version by
renaming those calls to their legacy equivalents if needed.
Test: built trivial NDK module targeting android-14 and using dprintf
Test: make checkbuild
Bug: https://github.com/android-ndk/ndk/issues/72
Change-Id: I90de149278f931380418536abaef47c5cee5c195
I've added some things like __ANDROID_MAJOR__ to an ndk-version.h, but
that is only in the NDK itself and so doesn't help the platform. Add
__ANDROID_NDK__ to identify that you're building for the NDK and not
the platform.
Test: make checkbuild
Bug: https://github.com/android-ndk/ndk/issues/407
Change-Id: I2d1f1c28e3764e4e658cf675b290b7a17253ee33
"Although not explicitly required by this volume of POSIX.1-2008, a good
implementation of append (a) mode would cause the O_APPEND flag to be set."
Yeah, about that...
Bug: N/A
Test: ran tests
Change-Id: I23c4bc5c1ebc92e0cb44025d2d313f321f9ffa68
This addresses post-commit feedback from
I88c39ca166bacde0b692aa3063e743bb046a5d2f. With this, our FORTIFY impl
now sits in one file.
Bug: 12231437
Test: mma; no new CtsBionicTestCases failures on bullhead internal
master.
Change-Id: I6f9ff81c3e86cf9d6a0efa650eb5765f1e2fa09c
