Historically, Android defaulted to EXPLICIT but with a special case
because SCHED_NORMAL/priority 0 was awkward. Because the code couldn't
actually tell whether SCHED_NORMAL/priority 0 was a genuine attempt to
explicitly set those attributes (because the parent thread is SCHED_FIFO,
say) or just because the pthread_attr_t was left at its defaults.
Now we support INHERIT, we could call sched_getscheduler to see whether
we actually need to call sched_setscheduler, but since the major cost
is the fixed syscall overhead, we may as well just conservatively
call sched_setscheduler and let the kernel decide whether it's a
no-op. (Especially because we'd then have to add both sched_getscheduler
and sched_setscheduler to any seccomp filter.)
Platform code (or app code that only needs to support >= P) can actually
add a call to pthread_attr_setinheritsched to say that they just want
to inherit (if they know that none of their threads actually mess with
scheduler attributes at all), which will save them a sched_setscheduler
call except in the doubly-special case of SCHED_RESET_ON_FORK (which we
do handle).
An alternative would be "make pthread_attr_setschedparams and
pthread_attr_setschedprio set EXPLICIT and change the platform default
to INHERIT", but even though I can only think of weird pathological
examples where anyone would notice that change, that behavior -- of
pthread_attr_setschedparams/pthread_attr_setschedprio overriding an
earlier call to pthread_attr_setinheritsched -- isn't allowed by POSIX
(whereas defaulting to EXPLICIT is).
If we have a lot of trouble with this change in the app compatibility
testing phase, though, we'll want to reconsider this decision!
-*-
This change also removes a comment about setting the scheduler attributes
in main_thread because we'd have to actually keep them up to date,
and it's not clear that doing so would be worth the trouble.
Also make async_safe_format_log preserve errno so we don't have to be
so careful around it.
Bug: http://b/67471710
Test: ran tests
Change-Id: Idd026c4ce78a536656adcb57aa2e7b2c616eeddf
e210488e0d in 2013 added this, which seems
to have been a workaround for the linker at the time that was never removed.
Bug: N/A
Test: ran tests
Change-Id: I171c3f4b7c34638ab75b8e49616b3a9c24ab3fcb
And add more tests.
Bug: N/A (but I'm here because a recent test broke existing tests)
Test: ran tests
Change-Id: Ib78430f179b43484a49bb50ff447ea6870c1ee3a
Applications fopening files and then blindly trying to read are
widespread, leading to a recurring problem of SELinux tightening
resulting in segfaults. Add a friendly diagnostic for this case.
Bug: http://b/67455242
Test: bionic-unit-tests32/64 on sailfish
Change-Id: I1734fa94487c4eff9b55a02c6b01baf6b265d236
I was unable to find a single use of this anywhere, and the networking
folks point out https://tools.ietf.org/html/rfc6093:
"""
5. Advice to New Applications Employing TCP
As a result of the issues discussed in Section 3.2 and Section 3.4,
new applications SHOULD NOT employ the TCP urgent mechanism.
"""
Applications that think they want to do these tricksy things should be
referred to section 3.4, wherein it's noted that these semantics are
effectively dead and it's middleboxes what killed 'em:
"""
3.4. Interaction of Middleboxes with TCP Urgent Indications
As a result of the publication of Network Intrusion Detection System
(NIDS) evasion techniques based on TCP urgent indications [phrack],
some middleboxes clear the urgent indications by clearing the URG
flag and setting the Urgent Pointer to zero. This causes the "urgent
data" to become "in line" (that is, accessible by the read(2) call or
the recv(2) call without the MSG_OOB flag) in the case of those TCP
implementations that interpret the TCP urgent mechanism as a facility
for delivering "out-of-band" data (as described in Section 3.1). An
example of such a middlebox is the Cisco PIX firewall [Cisco-PIX].
This should discourage applications from depending on urgent
indications for their correct operation, as urgent indications may
not be reliable in the current Internet.
"""
Bug: N/A
Test: N/A
Change-Id: I73280db1d803bb7bd93954c13c653fa0cd3daff9
These are still needed for backwards compatibility with code built by old
versions of the NDK, but we don't need to pollute the headers with them.
Also lose the hand-written code for these. The compiler-generated code
is either the same or better, and no new code is calling these functions
anyway.
Bug: N/A
Test: ran tests
Change-Id: Ib01ad9805034433e0105aec882608cc8e6526f78
They're POSIX, and they're implemented in iOS and glibc, but they're
not actually used in any codebase I have access to. They're *defined*
in several places, and some of those places have a handful of tests,
but I couldn't find a single genuine caller.
Bug: N/A
Test: N/A
Change-Id: Id3e2c36183fcff323aa5a2e3a3dabaa8378fae56
I'm skeptical about the usefulness of this, but it's in POSIX, it's
in glibc (but not iOS), and it is used in some internal source (test
runners and container code).
Bug: N/A
Test: ran tests
Change-Id: I92c5398f2a679b21a33fba92bc8e67e3ae2eb76f
Surprisingly to me, there are actual uses of `swab` in the codebases
I have available to search, including one with a #ifndef __ANDROID__
around it.
Bug: N/A
Test: ran tests
Change-Id: Ic91b78ae22bb65c346cb46dd38916f48d979abe0
Went through the POSIX spec for the _POSIX* and _XOPEN* constants.
Bug: http://b/32776472
Test: ran tests
Change-Id: I389100dbc7de354eae9056e44b0a7fa8c37374e3
We store a pointer to the long ro. property within the shared property
area, as we know that this pointer will never change locations or be
invalidated and it saves us from needing to allocate arbitrarily sized
storage for the property.
Bug: 23102347
Bug: 34954705
Test: bionic-unit-tests
Change-Id: I9f9147a2f951f20f51e4664c6faf9ff7f6a9502a
This reverts commit 9cb8639b18.
Fixed all the broken builds that were reported to me before this was
reverted.
Test: make checkbuild # kikey960, marlin, aosp_arm64; master and aosp
Add a static library containing the non-pthread dependent parts of
libc.
Bug: http://b/64400027
Test: sailfish boots
Test: bionic-unit-tests32/64, no new failures
Test: bionic-unit-tests-static32/64, no new failures
Change-Id: I93dc3811acddad7936d11b369b98cefd945ee2d5
Add all the missing <netdb.h> functions.
Also fix getservbyport to handle a null protocol correctly.
Also fix getservbyname/getservbyport to not interfere with getservent.
Also fix endservent to reset getservent iteration.
Also reduce unnecessary differences from upstream NetBSD sethostent.c.
The servent implementation is still horrific, and we should
probably support protoent too so that debugging tools can use
getprotobyname/getprotobynumber.
Bug: N/A
Test: ran tests
Change-Id: I639108c46df0a768af297cf3bbce857cb1bef9d9
We don't want to be exposing so much through the headers for the
implementation details unless we have to.
Test: make checkbuild
Bug: None
Change-Id: Ieca9cd8106725e08887a3e9fde60d1eef64ef98b
They're marked obsolescent in POSIX, don't clearly mean anything, aren't
portable because the values don't mean anything, and are no-ops in other
C libraries that do "implement" them.
Bug: N/A
Test: N/A
Change-Id: I07342a0a6a5f6616a8432bfea24ed944c7971d27
This fixes mips and mips64 build failures.
Test: successful aosp_mips-eng and aosp_mips64-eng builds
Change-Id: I6648b9cae876cda13369cf10edf61ce9fdca342c
We have no utmp, and we're ignoring getutxent/setutxent, and endutxent
belongs in the same group.
Bug: N/A
Test: N/A
Change-Id: Ide032960a0f95750f3bb8f2e62a25e5e7d25c7b6
<machine/asm.h> was internal use only.
<machine/fenv.h> is quite large, but can live in <bits/...>.
<machine/regdef.h> is trivially replaced by saying $x instead of x in
our assembler.
<machine/setjmp.h> is trivially inlined into <setjmp.h>.
<sgidefs.h> is unused.
Bug: N/A
Test: builds
Change-Id: Id05dbab43a2f9537486efb8f27a5ef167b055815
If (2nd) arch is "arm", (2nd) arch variant is "armv7-a-neon" or
"armv8-a", and (2nd) cpu variant is "generic", current Android.bp only
uses generic ARM assmebly or C code, even though they all have NEON.
This change use functions optimized for cortex-a15 (for these generic
cores), which are a reasonable balance for most ARM cores with Neon.
Also build script for specific armv7/armv8 cores are refactored to
take advantage of the common part (mostly cortex-a15 code), so more
than 150 repeated lines are removed.
Bug: 66064745
Test: For armv7-a-neon/armv8-a "generic" core
- boot with GSI on sailfish
- related cortex-a15 function are built and linked.
All libc.a/libc.so built are identical for the following cores:
- cortex-a7, cortex-a8, cortex-a9, cortex-a15, krait
- cortex-a53, cortex-a53.a57, cortex-a73, denver, kryo
$ lunch aosp_arm64 # with TARGET_2ND_CPU_VARIANT unset
# For each $core listed above
$ TARGET_2ND_CPU_VARIANT=$core m -e -j libc
Change-Id: Ia565d3ea09e034adcd014e7467a5b791cff908cb
We need to be able to store build fingerprints that are over 92 characters
long, which is the current restriction for system property value
length.
Increasing the value maximum across the board has plenty of caveats,
particularly that an allocator would be required to handle
deallocation when replacing long property values with short values.
There is also no compelling reasons to do this.
But, increasing the length of simply read-only properties, such as the
build fingerprint, has less caveats as there will never be a
deallocation of these strings.
This change uses spare bits in the top of serial (only spare for
read-only properties) to indicate if a property is 'long' or not. The
information required to access these 'long' properties is stored in a
union where the legacy property value is located. An error message is
retained for legacy callers.
The new property is readable via __system_property_read_callback() and
most importantly android::base::GetProperty and higher level (Java,
`getprop`) callers. All code should move to these higher level
functions as much as possible.
Bug: 23102347
Bug: 34954705
Test: bionic unit tests
Change-Id: Ia85e0d979b92afff601cc52b39114379617a0c64
Autosubmit fired before the CL was actually ready (forgot to hit "y"
on the repo upload).
Test: make checkbuild
Test: copied into the NDK and ran mmap64_fob64 test.
Bug: lots
Change-Id: I8c0400a703f319e8e230f7ba9178009ed7c88be0
While this was never an inline, this function alone has caused most of
the bug reports related to _FILE_OFFSET_BITS=64. Providing an inline
for it should allow a lot more code to build with _FILE_OFFSET_BITS=64
when targeting pre-L.
Test: make checkbuild
Test: built trivial cc_binary for LP32 against API 14 with
_FILE_OFFSET_BITS=64 set
Bug: lots
Change-Id: I8479d34af4da358c11423bee43d45b59e9d4143e
On aarch64/x86/x86_64 add a macro that inserts a cfi directive that will
stop unwinding.
For arm, clang doesn't allow emitting .cantunwind, so add a comment and
leave it the same as it current is.
Add this macro to __libc_init and __start_thread.
Also, remove duplicate compilation of libc_init_static.cpp that already
includes the static library that includes that file.
Bug: 15469122
Test: Did unwinds using new unwinder tool (unwind) and debuggerd -b
Test: and verified new unwinder works on aarch64/x86/x86_64.
Test: Verified that it works on old unwinder for aarch64/x86, but
Test: x86_64 doesn't work properly, but as well as before.
Change-Id: I77302e8f6c7ba1549d98a4a164106ee82c9ecadc
The newest of these clocks was added in Linux 2.6.12, so no need for runtime
checks.
Add CTS tests that we can actually use the various clocks.
Bug: http://b/67458266
Test: ran tests
Change-Id: I3cfd7982043d6f8d4ebdc2b29e8722334f443ce5
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
