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 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
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
When looping over the current list of sockets we are connected to,
use getpeername() not getsockname() to find out who the remote
end is. This change avoids spurious close() and (rare) failure.
Origin: ISC bug #18625 and fixed in libbind 6.0
Change-Id: I5e85f9ff4b98c237978e4bf4bd85ba0a90d768e6
The function bcopy() is marked as LEGACY in POSIX.1-2001 and removed in
POSIX.1-2008. memcpy (POSIX.1-2001) is its recommended replacement.
Change-Id: I2cc0cc4673d1368255afd11132ddbfd3f87b530b
Add bionic libc to support readahead system call.
This is needed to enable sreadahead to work.
Change-Id: I3856e1a3833db82e6cf42fd34af7631bd40cc723
Author: Winson Yung <winson.w.yung@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Issue:
The kernel will pad the entry->d_reclen in a getdents64 call to a
long-word boundary. For very long records, this could exceed the
size of a struct dirent. The mismatch in the size was causing error
paranoid checking code in bionic to fail... thus causing an early
"end" when reading the dirent structures from the kernel buffer.
Test:
ls
mkdir abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstu
ls
Change-Id: I75d1f8e45e1655fdd7bac4a08a481d086f28073a
Author: Bruce Beare <bruce.j.beare@intel.com>
Fix dead loops in file ./bionic/libc/unistd/pathconf.c
Change-Id: I7a1e6bcd9879c96bacfd376b88a1f899793295c8
Author: Jin Wei <wei.a.jin@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
When forking of a new process in bionic, it is critical that it
does not allocate any memory according to the comment in
java_lang_ProcessManager.c:
"Note: We cannot malloc() or free() after this point!
A no-longer-running thread may be holding on to the heap lock, and
an attempt to malloc() or free() would result in deadlock."
However, as fork is using standard lib calls when tracing it a bit,
they might allocate memory, and thus causing the deadlock.
This is a rewrite so that the function cpuacct_add, that fork calls,
will use system calls instead of standard lib calls.
Signed-off-by: christian bejram <christian.bejram@stericsson.com>
Change-Id: Iff22ea6b424ce9f9bf0ac8e9c76593f689e0cc86
Pass kernel space sigset_t size to __rt_sigprocmask to workaround
the miss-match of NSIG/sigset_t definition between kernel and bionic.
Note: Patch originally from Google...
Change-Id: I4840fdc56d0b90d7ce2334250f04a84caffcba2a
Signed-off-by: Chenyang Du <chenyang.du@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Chars are signed for x86 -- correct the comparison semantics.
Change-Id: I2049e98eb063c0b4e83ea973d3fcae49c6817dde
Author: Liubov Dmitrieva <liubov.dmitrieva@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Fix the compile warning to let the libc.debug.malloc=10 works well
Due to unsuitable value comparison, which cause compiler optimize the
code of comparing two digits.
Change-Id: I0bedd596c9ca2ba308fb008da20ecb328d8548f5
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Author: liu chuansheng <chuansheng.liu@intel.com>
(1) in pthread_create:
If the one signal is received before esp is subtracted by 16 and
__thread_entry( ) is called, the stack will be cleared by kernel
when it tries to contruct the signal stack frame. That will cause
that __thread_entry will get a wrong tls pointer from the stack
which leads to the segment fault when trying to access tls content.
(2) in pthread_exit
After pthread_exit called system call unmap(), its stack will be
freed. If one signal is received at that time, there is no stack
available for it.
Fixed by subtracting the child's esp by 16 before the clone system
call and by blocking signal handling before pthread_exit is started.
Author: Jack Ren <jack.ren@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
When running the stress test of pthread create/destroy, a crash may
oocur in __get_tls(). That is caused by the race condition with __set_tls( ):
Author: Jack Ren <jack.ren@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
android linker doesn't check machine type, it may load some
libraries which it doesn't support sometimes.
Author: Zhenghua Wang <zhenghua.wang@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Without this change strcmp size is zero (not set), and it gets
ignored by Valgrind. Changes to memcpy and atexit don't affect the
generated binary in any way.
Change-Id: I05818cb5951f75901dc8c0eef02807a2e83a9231
