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
Also move some of the stuff that should be in <link.h> out of the
private "linker.h", to make it clearer that these are public API
known to gdb that we can't change.
Bug: 12554197
Change-Id: I830e1260d3d8b833ed99bc1518f1c6b6102be8af
libc/libm support for MIPS64 targets
Change-Id: I8271941d418612a286be55495f0e95822f90004f
Signed-off-by: Chris Dearman <chris.dearman@imgtec.com>
Signed-off-by: Raghu Gandham <raghu.gandham@imgtec.com>
Most of <machine/_types.h> was either unused, wrong, or identical across
all 32-/64-bit architectures.
I'm not a huge fan of <sys/_types.h> either, but moving the bits we need
up into there is a step forward.
Bug: 12213562
Change-Id: Id13551c78966e324beee2dd90c5575e37d2a71e6
libunwind has #define inline /* empty */ which breaks our fortified headers.
glibc uses __inline but our BSD-derived headers often override that. __inline__
is the third alternative understood by GCC that -- as far as I know -- neither
the C library itself nor third-party code tries to mess with.
Bug: 12871594
Change-Id: I6677e70ea531bb7d4c46021b43af760d4ad8ecf7
As suggested here: https://android-review.googlesource.com/#/c/71267/
it may be used for x86_64 libunwind enabling.
Change-Id: I21623261a48ea7099e030d33932556e294d226ff
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
The various committees decided that everyone should get all these macros,
all the time.
Bug: 12708004
Change-Id: Ib56010dcba9b0656e5701546fefb7f78dc0bf916
These functions should print assertion violation messages and then
call abort(). They do really not return control flow afterwards.
Consider the declaration of the similar __assert_fail from glibc:
extern void __assert_fail (const char *__assertion,
const char *__file,
unsigned int __line,
const char *__function)
__THROW __attribute__ ((__noreturn__));
Bionic has __noreturn defined in sys/cdefs.h to be that GNU
noreturn attribute.
This patch has a practical value. Consider the following function:
void check(void* ptr) {
assert(ptr != NULL);
}
Without this patch applied, gcc (and presumably clang) shows even in
debug mode:
warning: unused parameter 'ptr' [-Wunused-parameter]
In release mode, NDEBUG is defined and assert() becomes a no-op, as
one should expect. Thus, the warning is shown correctly then.
Another code sample:
float array[2];
int i = 3;
...
assert(i < 2);
array[i] = 0;
gcc says,
warning: array subscript is below array bounds [-Warray-bounds]
In other words, without noreturn attribute, assertions do not
allow a compiler's static analyzer to properly understand
the preconditions.
Change-Id: I3be92e99787c528899cf243ed448c4730c00c45b
Signed-off-by: Vadim Markovtsev <gmarkhor@gmail.com>
This patch adds trivial implementations of the missing sys headers
needed by strace. All strace needs are the constants and structures,
so this is enough for now. We can come back and add the functions
if/when we ever need them.
Change-Id: Idb87c1a8b6b1c62f6e16ae94f147e1169722b48e
The situation here is a bit confusing. On 64-bit, rlimit and rlimit64 are
the same, and so getrlimit/getrlimit64, setrlimit/setrlimit64,
and prlimit/prlimit64 are all the same. On 32-bit, rlimit and rlimit64 are
different. 32-bit architectures other than MIPS go one step further by having
an even more limited getrlimit system call, so arm and x86 need to use
ugetrlimit instead of getrlimit. Worse, the 32-bit architectures don't have
64-bit getrlimit- and setrlimit-equivalent system calls, and you have to use
prlimit64 instead. There's no 32-bit prlimit system call, so there's no
easy implementation of that --- what should we do if the result of prlimit64
won't fit in a struct rlimit? Since 32-bit survived without prlimit/prlimit64
for this long, I'm not going to bother implementing prlimit for 32-bit.
We need the rlimit64 functions to be able to build strace 4.8 out of the box.
Change-Id: I1903d913b23016a2fc3b9f452885ac730d71e001
glibc has no <sys/dirent.h>. If we do have to bring this back, we
should probably just have one file #include the other.
Change-Id: I5c0bf9c03769daf3b23f69778e9f01f81c3de9ec
If glibc hadn't already done things this way round, I'd have
called the field sched_priority and the macro __sched_priority
since that would seem less likely to cause trouble, but glibc
source compatibility is probably more important.
Change-Id: I8a8a477f2aa87cae641069c5c84b4fcab3152a82
Adds the TCPOPT_* constants from NetBSD. Note that the BSDs also have
TCPOPT_SIGNATURE, but Linux calls that TCPOPT_MD5SIG and glibc doesn't
have any corresponding constant yet, so let's wait until we see which name
wins out.
Change-Id: If53cdada5595285d9a7e7248ef74cd7502d804c0
32-bit Android's dev_t was wrong too. We can't fix that without ABI breakage,
but we can at least fix 64-bit Android. And add tests.
Bug: https://code.google.com/p/android/issues/detail?id=54966
Change-Id: Ie2e42cc042b78b669a1a44e55f959dbd9c52c5c9
This patch switches to using the uapi constants. It also adds the missing
setns system call, fixes sched_getcpu's error behavior, and fixes the
gensyscalls script now ARM is uapi-only too.
Change-Id: I8e16b1693d6d32cd9b8499e46b5d8b0a50bc4f1d
Even though code built with clang won't be fully fortified
and won't contain calls to our various helpers, binaries built
with GCC will.
Change-Id: I389b2f1e22a3e89b22aadedc46397bf704f9ca79
This is a better solution than the old __warn_references because it's
a compile-time rather than link-time warning, it doesn't rely on something
that doesn't appear to be supported by gold (which is why you only used
to see these warnings on mips builds), and the errors refer to the exact
call site(s) rather than just telling you which object file contains a
reference to the bad function.
This is primarily so we can build bionic for aarch64; building libc.so
caused these warnings to fire (because link time is the wrong time) and
warnings are errors.
Change-Id: I5df9281b2a9d98b164a9b11807ea9472c6faa9e3
Since the ENTRY/END macros now have .cfi_startproc/.cfi_endproc, most of the
custom arm assembly has no unwind information. Adding the proper cfi directives
for these and removing the arm directives.
Update the gensyscalls.py script to add these cfi directives for the generated
assembly. Also fix the references to non-uapi headers to the proper uapi
header.
In addition, remove the kill.S, tkill.S, tgkill.S for arm since they are not
needed at all. The unwinder (libunwind) is able to properly unwind using the
normal abort.
After this change, I can unwind through the system calls again.
Bug: 11559337
Bug: 11825869
Bug: 11321283
Change-Id: I18b48089ef2d000a67913ce6febc6544bbe934a3
There is no uapi user.h file for arm, it was included by accident.
Move the user struct definition into the file to follow the pattern
used by the other architectures.
Change-Id: Ib9cea0deca551c9268382ddd6de9202fd32ef941
Also fix the signature of usleep, and the definition of useconds_t which
should be unsigned, as the 'u' in its name implies.
This patch also cleans up the existing FreeBSD hacks by moving the libm
stuff from <sys/cdefs.h> to a libm-private header, and adding comments
about the hacks we use to build FreeBSD source.
Change-Id: Ibe5067a380502df94a0a3a7901969b35411085b6
The kernel doesn't have an nlink_t; it just uses the equivalent of
uint32_t. We already had a usable __nlink_t in the C library, so
let's just define our nlink_t in terms of __nlink_t, which is what
__nlink_t was meant for anyway.
Note that our struct stat just follows the kernel, and doesn't refer
to nlink_t anyway.
Change-Id: I2a56e418e42404b1741b08c50554b03c11caebae
<time.h> didn't need to copy the cruft from <signal.h>, and
<signal.h> only needs the uid_t hack when it's not using
uapi headers.
pthread_exit.cpp should include what it uses.
Change-Id: I836c36abe0f0a781d41fc425b249d1c7686bb124
The old code ignored operator precedence (!), despite having two tables
of operator precedence. The code's still pretty awful, but I've cleaned
it up enough to fix this, the most important bug.
This patch lets us correctly clean the uapi unistd.h, stat.h, and swab.h files,
and also fixes the mess we were already making of various old kernel
header files. I've added a bunch more tests, fixed the existing tests that
the existing script was already failing (!), and changed the script so that
the tests are run every time the script is run.
We can probably remove some of the old kernel header files that we were
parsing incorrectly, but we can worry about that later.
Bug: 11253477
Change-Id: Ie66c65b3a7ae13b4e98ed8038a6a534f06eae0e5
The 64-bit uapi headers don't define FD_CLR and friends, so this
patch updates libc/kernel/common/linux/time.h after the change
b934bbec145e9e084bf48149a3a94ae3dd132157 in external/kernel-headers,
then fixes <sys/select.h> to work in this new world, and removes
some now-unnecessary duplication from <time.h> (with other cruft
cleaned up while I'm here).
Change-Id: Ifd26f901b4d200c65065b3e6ef1b74055127e052
<pthread.h> was missing nonnull attributes, noreturn on pthread_exit,
and had incorrect cv qualifiers for several standard functions.
I've also marked the non-standard stuff (where I count glibc rather
than POSIX as "standard") so we can revisit this cruft for LP64 and
try to ensure we're compatible with glibc.
I've also broken out the pthread_cond* functions into a new file.
I've made the remaining pthread files (plus ptrace) part of the bionic code
and fixed all the warnings.
I've added a few more smoke tests for chunks of untested pthread functionality.
We no longer need the libc_static_common_src_files hack for any of the
pthread implementation because we long since stripped out the rest of
the armv5 support, and this hack was just to ensure that __get_tls in libc.a
went via the kernel if necessary.
This patch also finishes the job of breaking up the pthread.c monolith, and
adds a handful of new tests.
Change-Id: Idc0ae7f5d8aa65989598acd4c01a874fe21582c7
(aarch64 kernels only have the newer system calls.)
Also expose the new functionality that's exposed by glibc in our header files.
Change-Id: I45d2d168a03f88723d1f7fbf634701006a4843c5
Modern architectures only get the *at(2) system calls. For example,
aarch64 doesn't have open(2), and expects userspace to use openat(2)
instead.
Change-Id: I87b4ed79790cb8a80844f5544ac1a13fda26c7b5
This patches fixes the definitions for STDINT_LIMITS on __LP64__
systems.
Change-Id: I5eb1664e9ef7c303432a2b041c99cec663816b75
Signed-off-by: Serban Constantinescu <serban.constantinescu@arm.com>
Add 64-bit stat structure mapping 64-bit stat syscall.
Change-Id: Ice517616391bee1d556b6c03e7f5ee610050e6c6
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
SOCK_CLOEXEC is used to atomically set close-on-exec flag for the new
descriptor(s), and SOCK_NONBLOCK is used to mark descriptor(s) as
non-blocking.
Change-Id: I8ba6a70543d23759e3ddcc7ff9c21b567184d681
Also clean up <signal.h> and revert the hacks that were necessary
for 64-bit in linker/debugger.cpp until now.
Change-Id: I3b0554ca8a49ee1c97cda086ce2c1954ebc11892
Previously, FORTIFY_SOURCE used single macros to define these standard
functions for use with clang. This can cause conflicts with other macros used
to call these functions, particularly when those macros expand the number of
arguments to the function. This change wraps our macro definitions, so that
expansion properly takes place for programmer arguments first.
Change-Id: I55929b1fd2a643b9d14a17631c4bcab3b0b712cf
This is basically the other half of I5de76f6c46ac87779f207d568a86bb453e2414de
from Pavel Chupin <pavel.v.chupin@intel.com>, but taking the exact upstream
_types.h instead of the modified version. (I was confused when I suggested
otherwise.)
I've also cleaned up the internal_types.h situation; we weren't gaining
anything from these empty files, and there is no upstream internal_types.h
for x86_64.
Change-Id: I802a9a6a8df1c979e820659212c75a47c2ef392e
Make sure the buffer we're dealing with has enough room.
Might as well check for memory issues while we're here,
even though I don't imagine they'll happen in practice.
Change-Id: I0ae1f0f06aca9ceb91e58c70183bb14e275b92b5
malloc and family were not declared with __attribute__((alloc_size)).
This was (sometimes) preventing FORTIFY_SOURCE related functions
from knowing the size of the buffer it's dealing with, inhibiting
FORTIFY_SOURCE protections.
Add __attribute__((alloc_size))
Information about the alloc_size attribute can be found
at http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
Change-Id: Ia2f0a445f0170a7325f69259b5e7fb35a9f14921
I've no idea what _BITSIZE was supposed to be, glibc doesn't have it,
the BSDs don't have it, and no code is currently using it. But having
it set unconditionally to 32 sounds like a bad idea.
Change-Id: I900235c1489afba891fff0bc3b43e9d593249a4f
This touches the x86 stubs too because arm, x86, and x86_64 now
all share the same header (at a source level), which causes a
reordering of the #include lines.
Change-Id: If9a1e2b2718bd41d8399fea748bce672c513ef84
Manual changes:
cpp.py: cope with macros that refer to other macros.
defaults.py: x86 no longer always implies __i386__; use __i386__ to replace
the kernel CONFIG_X86_32 flag.
asm/page.h: the upstream page.h isn't a uapi header and no longer includes
the stuff we were using it for. Let's just have our own static file, since
it's the same for all our architectures (both 32- and 64-bit).
sys/select.h: we used to use the various FD_SET-related macros from the
kernel header files, but they've gone. Adjust by adding trivial equivalent
definitions.
Automated changes:
libc/kernel/arch-x86, libc/kernel/common: regenerated from
external/kernel-headers.
Change-Id: I84fc0ed52dc742e043b4ae300fd3b58ee99b7fcd
If "n" is smaller than the size of "src", then we'll
never read off the end of src. It makes no sense to call
__strncpy_chk2 in those circumstances.
For example, consider the following code:
int main() {
char src[10];
char dst[5];
memcpy(src, "0123456789", sizeof(src));
strncpy(dst, src, sizeof(dst));
dst[4] = '\0';
printf("%s\n", dst);
return 0;
}
In this code, it's clear that the strncpy will never read off
the end of src.
Change-Id: I9cf58857a0c5216b4576d21d3c1625e2913ccc03
Fortify calls to recv() and recvfrom().
We use __bos0 to match glibc's behavior, and because I haven't
tested using __bos.
Change-Id: Iad6ae96551a89af17a9c347b80cdefcf2020c505
This adds mmap64() to bionic so that it is possible to have
large offset passed to kernel. However, the syscall mechanism
only passes 32-bit number to kernel. So effectively, the
largest offset that can be passed is about 43 bits (since
offset is signed, and the number passed to kernel is number
of pages (page size == 4K => 12 bits)).
Change-Id: Ib54f4e9b54acb6ef8b0324f3b89c9bc810b07281
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
__page_shift and __page_size were accidentally declared in unistd.h with
C linkage - their implementation needs to use the same linkage.
Going forward, though, let's stop the inlining madness and let's kill
the non-standard __getpageshift(). This patch takes getpagesize(3) out
of line and removes __getpageshift but fixes __page_shift and __page_size
for backwards binary compatibility.
Change-Id: I35ed66a08989ced1db422eb03e4d154a5d6b5bda
Signed-off-by: Bernhard Rosenkraenzer <Bernhard.Rosenkranzer@linaro.org>
Fix source location. Move declaration of __strchr_chk out of
ifdef __BIONIC_FORTIFY which should be available for strchr.cpp
compilation when __BIONIC_FORTIFY is not defined.
Change-Id: I552a6e16656e59b276b322886cfbf57bbfb2e6a7
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
Introduce __bos0 as a #define for __builtin_object_size((s), 0).
This macro is intended to be used for places where the standard
__bos macro isn't appropriate.
memcpy, memmove, and memset deliberately use __bos0. This is done
for two reasons:
1) I haven't yet tested to see if __bos is safe to use.
2) glibc uses __bos0 for these methods.
Change-Id: Ifbe02efdb10a72fe3529dbcc47ff647bde6feeca
Patch is required in NDK headers as well to be able to build multilib
GCC with libgomp support.
It's here: https://android-review.googlesource.com/#/c/62982
Change-Id: I2bec25d8cbca0e5ef1a0857008ececd92f4911be
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
Also make sysconf use PTHREAD_STACK_MIN rather than redefining its
own, different, constant.
Bug: 9997352
Change-Id: I9a8e7d2b18e691439abfb45533e82c36eee9e81d
Adds an extra mark parameter to android_getaddrinfoforiface,
android_gethostbyaddrforiface and android_gethostbynameforiface that if set
will cause all packets sent by DNS requests to have that mark
Change-Id: I6f72390e4ce5bfc3cc73183f9b2fb3705a11685f
glibc doesn't have these, and they prevent ping from building out of
the box because it assumes it can define them.
Bug: 9671560
Change-Id: I815f2a9c4fd96a0ea2952eb5a71ddf51e0763660
Linux and *BSD kernels use opposite values to indicate pass/block
in ICMPv6 filters, and assign a different value to the
ICMP6_FILTER sockopt.
Bug: 9671560
Bug: 9469682
Change-Id: Ic0f1fcd48891add992acf97632f60aebd172c1d7
On NetBSD and glibc, including sys/ioctl.h provides some
terminal ioctl data structures such as struct winsize. For
compatibility, provide these via sys/ioctl.h in bionic as well.
bionic does not have its own definitions for these structures, so
get them from the Linux kernel definitions.
Change-Id: I01345c23c0bebd60b0a80fc33668e7c0ad7356c3
This is needed to compile open-source code that wants to
expand/compress domain names itself, such as ping6.
Bug: 9469682
Change-Id: I339c6538936d05c031bc6fb0a8793aaf1429dea4
Our intptr_t and uintptr_t aren't "long". Add a compilation test so we remember
to fix this to cope with 32- and 64-bit later.
Bug: http://code.google.com/p/android/issues/detail?id=57218
Change-Id: I2f816d339edb4f7d57e4418b818fb4c602093f38
Enable FORTIFY_SOURCE protections under clang for the following
functions:
* vsprintf
* vsnprintf
and add unittests.
Change-Id: I90f8a27f7b202c78b5dd8ebf53050bf9e33496f7
* commit 'fbec57d46c42460b2381484d1610ff21922d162e':
bionic: add compatibility mode for properties
bionic: use the size of the file to determine property area size
Allow a new bionic to work with an old init property area by supporting
the old format.
(cherry picked from commit ad76c85b9c)
Change-Id: Ib496e818a62a5834d40c71eb4745783d998be893
* commit '1642edb5208fe02ef64d5734fffaf7c4a724fd2f':
bionic: store property names as variable-length strings
bionic: prevent root processes from calling __system_property_add
bionic: revert to a single (larger) property area
bionic: reimplement property area as hybrid trie/binary tree
bionic: add missing memory barriers to system properties
bionic: make property area expandable
d329697 is too complicated. Change the multiple property pages back to
a single 128K property area that's mapped in entirely at initialization
(the memory will not get allocated until the pages are touched).
d329697 has other changes useful for testing (moving property area
initialization inside bionic and adding __system_property_set_filename)
so undo the change manually rather than with git revert.
Signed-off-by: Greg Hackmann <ghackmann@google.com>
(cherry picked from commit 5f05348c18)
Change-Id: I690704552afc07a4dd410277893ca9c40bc13e5f
See the comments for an explanation of how properties are stored.
The trie structure is designed to scale better than the previous
array-based implementation. Searching an array with n properties
required average O(n) string compares of the entire key; searching the
trie requires average O(log n) string compares of each token (substrings
between '.' characters).
Signed-off-by: Greg Hackmann <ghackmann@google.com>
(cherry picked from commit 6ac8e6a46d)
Change-Id: Icbe31908572f33b4d9b85d5b62ac837cbd0f85e0
The property area is initially one 4K region, automatically expanding as
needed up to 64 regions.
To avoid duplicating code, __system_property_area_init() now allocates
and initializes the first region (previously it was allocated in init's
init_property_area() and initialized in bionic). For testing purposes,
__system_property_set_filename() may be used to override the file used
to map in regions.
Signed-off-by: Greg Hackmann <ghackmann@google.com>
(cherry picked from commit d32969701b)
Change-Id: I038d451fe8849b0c4863663eec6f57f6521bf4a7
