Prepend a 0 to match the new sequence-number style, though this module
doesn't really need/use it.
bug:5864209
Change-Id: Iacbcddaced6fe8bb01d186596a916e4fb4805fef
We don't have a toolchain anymore, we don't have working original
kernel headers, and nobody is maintaining this so there is really
no point in keeping this here. Details of the patch:
- removed code paths from Android.mk files related to the SuperH
architecture ("sh")
- removed libc/arch-sh, linker/arch-sh, libc/kernel/arch-sh
- simplified libc/SYSCALLS.TXT
- simplified the scripts in libc/tools/ and libc/kernel/tools
Change-Id: I26b0e1422bdc347489e4573e2fbec0e402f75560
Signed-off-by: David 'Digit' Turner <digit@android.com>
The flag to avoid calling ELF constructors recursively (in the case
of recursive .so dependencies) was being set after the dangerous
recursive constructor call had already been made.
This fixes the libc's debug malloc implementation.
Change-Id: I5e601f0ea19ab1df81b8b1ad4df25c3eab0ccda4
This optimization improves the performance of recursive locks
drastically. When running the thread_stress program on a Xoom,
the total time to perform all operations goes from 1500 ms to
500 ms on average after this change is pushed to the device.
Change-Id: I5d9407a9191bdefdaccff7e7edefc096ebba9a9d
Write a message to the log file if the signal handler is not able
to connect to debuggerd. This is especially handy if the failure
was caused by running out of file descriptors, since there's some
chance that the lack of fds relates to the crash.
Sample:
F libc : Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)
F libc : Unable to open connection to debuggerd: Too many open files
Bug 5926330
Change-Id: I0ff210d82ab1db39b08f328bae5e08f67a69e5d7
32 enteries perhaps was ok for per-process caching with ipv4 only
but adding ipv6 records makes it effectively 16 entries and making
it system wide makes is pretty useless. Increasing to 640 entries.
bug:5841178
Change-Id: I879f8bf4d3c4d8c1708bb46d46a67c1f64b1861f
The x86 asm headers define __u64 regardless of __STRICT_ANSI__.
The linux/videodev2.h header requires __u64 to be defined, thus
this fixes compiling with -std=c99 when including the
linux/videodev2.h header.
In glibc, the asm/types.h header defines __u64 regardless of
__STRICT_ANSI__.
This is the change for the generated arch-arm/asm/types.h
header, as produced by the update_all.py script (without all
the other unrelated changes that the script produces).
FWIW, the same issue also is present in
arch-sh/asm/types.h, but there are no source headers for
arch-sh in external/kernel-headers (and regenerating the
headers simply removes that file).
Change-Id: If05fcc9ed6ff5943602be121c7be140116e361fe
This fixes a bug that was introduced in the latest pthread optimization.
It happens when a recursive lock is contented by several threads. The main
issue was that the atomic counter increment in _recursive_increment() could
be annihilated by a non-conditional write in pthread_mutex_lock() used to
update the value's lower bits to indicate contention.
This patch re-introduces the use of the global recursive lock in
_recursive_increment(). This will hit performance, but a future patch
will be provided to remove it from the source code.
Change-Id: Ie22069d376cebf2e7d613ba00b6871567f333544
The Linux kernel provides an AT_SECURE auxv flag to inform userspace
whether or not a security transition has occurred. This is more reliable
than directly checking the uid/gid against the euid/egid, because it covers
not only setuid/setgid but also file capabilities, SELinux, and AppArmor
security transitions. It is also a more efficient test since it does
not require any additional system calls.
Change-Id: I9752a4f6da452273258d2876d13b05e402fb0409
The xattr system calls are required for the SE Android userspace in
order to get and set file security contexts. In particular, libselinux
requires these calls.
Change-Id: I78f5eb3d8f3384aed0a5e7c6a6f001781d982017
