I'll come back and remove the separate files (and change the regular 'generate'
script) when the separate files are obsolete, but in the interim period, it's
easier to have both old and new files available.
Bug: 7012465
Change-Id: I36e2fd49c08ff79ded6eca1c5bc4c08837cc490a
This patch updates the C library headers to provide ucontext_t
definitions for three architectures.
+ Fix <signal.h> to always define 'struct sigcontext'.
The new declarations are announced with new macros defined in
<sys/cdefs.h> in order to make it easier to adapt client code
that already defines its own, incompatible, versions of the
structures seen here.
http://code.google.com/p/android/issues/detail?id=34784
Change-Id: Ie78c48690a4ce61c50593f6c39639be7fead3596
I gave up trying to use the usual thread-local buffer idiom; calls to
calloc(3) and free(3) from any of the "dl" functions -- which live in
the dynamic linker -- end up resolving to the dynamic linker's stubs.
I tried to work around that, but was just making things more complicated.
This alternative costs us a well-known TLS slot (instead of the
dynamically-allocated TLS slot we'd have used otherwise, so no difference
there), plus an extra buffer inside every pthread_internal_t.
Bug: 5404023
Change-Id: Ie9614edd05b6d1eeaf7bf9172792d616c6361767
LONG_LONG_MIN, LONG_LONG_MAX and ULONG_LONG_MAX are
GLibc-specific macros that are better defined in <limits.h>
instead of the current exotic location (<pthread.h>).
Note that GCC's <limits.h> only defines these macros
when __GNU_LIBRARY__ is also defined. This is only the
case when building against GLibc, so manually redefine
the macros here.
Note that using LLONG_MIN/LLONG_MAX/ULLONG_MAX is the
C99-compliant way to get these values, but it's easier
to define these compatibility macros for the sake of
porting existing code.
Change-Id: I8023918d73b4685238054932f94a4006c1ca7d03
The tests for a NULL pointer and size 0 were the wrong way round.
From Intel's patch 9cae4f2ffc4778ed82be04711d8775a84092d4e2.
Change-Id: I118aff3358aa5f34126d74bfaa43f6e2f1a89055
Add unit tests for dlerror(3) in various situations. I think We're at least
as good as glibc now.
Also factor out the ScopedPthreadMutexLock and use it here too.
Bug: http://code.google.com/p/android/issues/detail?id=38398
Change-Id: I040938b4366ab836e3df46d1d8055b92f4ea6ed8
perf_event_open syscall has a different syscall number for
the 3 supported architectures: arm, x86 and mips. Currenlty
only the arm syscall number is defined for all architectures.
Tracing tools like perf will not work on other architectures
than arm.
Add the different values for perf_event_open on x86 and mips
and run gensyscalls.py to update generated headers.
Change-Id: I2ed78bd42c0e5df8dbc51d784be49cccda5fab30
Author: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Shuo Gao <shuo.gao@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Now we use private variables in transform-o-to-executable to support
build executables against the NDK.
Cherry-picked from master.
Bug: 7170098
Change-Id: Ic8f1d36a116fce24f3ea6a3ff5e9bfab6cafee99
Now we use private variables in transform-o-to-executable to support
build executables against the NDK.
Bug: 7170098
Change-Id: I6e505b33001b76f4b11fcbbb1d35392c4ddf4c70
Our debugger signal catcher expects to receive three args, but if
somebody cleared SA_SIGINFO we only get one, and bad things happen
when we try to use the second one. Test to see if SA_SIGINFO is
still set before we try to use the argument.
(cherry-pick of f84bc8d6f6368f1c846124a8168761ee8cc589c0.)
Bug: 7272866
Change-Id: I69a65c25e833aea70acb78f9ba40ed93308583e6
