Ensure we don't call sigchain's sigaction64 from bionic's sigaction by
extracting sigaction64 to a static function.
Test: treehugger
Change-Id: I16226c6ac580ece7000c335beb1d3b76429d2a06
If a signal handler is blocking all of their signals, we should
probably respect that and not silently unblock bionic's reserved
signals for them. Otherwise, user code can deadlock, run out of stack,
etc. through no fault of their own, if one of the reserved signals
comes in while they've pivoted onto their signal stack.
Bug: http://b/122939726
Test: treehugger
Change-Id: I6425a3e7413edc16157b35dffe632e1ab1d76618
Previously, we were zeroing out the reserved signals, when we actually
wanted to have TIMER_SIGNAL always be blocked, and the other signals
always be unblocked. This resulted in process termination when a
SIGEV_THREAD timer callback calls sigprocmask(SIG_SETMASK, ...) with
any signal mask value, and then subsequently fails to complete its
callback and reach the sigtimedwait in bionic before the next timer
iteration triggers.
Add a how argument to filter_reserved_signals to appropriately
block/unblock our reserved signals.
Bug: http://b/116783733
Test: bionic-unit-tests32/64
Change-Id: Ie5339682cdeb914711cd4089cd26ee395704d0df
This is a follow up to I47b0560a30aa33a9b1f1978dfb7f84d2e3d389b8.
This fixes MIPS32 build.
Test: successful build and boot aosp_mips-eng
Change-Id: Ia5b245f5536d8fd037f1798bbdf6215c5f059045
gdb was happy with what we had, but libgcc and libunwind weren't.
libgcc is happy with the kernel's restorer (because of the extra nop),
though libunwind looks like it's going to need code changes regardless.
We could make our restorer more like the kernel's one, but why bother
when we can just let the kernel supply the canonical one?
Bug: 17436734
Change-Id: I330fa5e68f23b1cf8133aa552896657b0b873ed3
* LP32 should use sa_restorer too. gdb expects this, and future (>= 3.15) x86
kernels will apparently stop supporting the case where SA_RESTORER isn't
set.
* gdb and libunwind care about the exact instruction sequences, so we need to
modify the code slightly in a few cases to match what they're looking for.
* gdb also cares about the exact function names (for some architectures),
so we need to use __restore and __restore_rt rather than __sigreturn and
__rt_sigreturn.
* It's possible that we don't have a VDSO; dl_iterate_phdr shouldn't assume
that getauxval(AT_SYSINFO_EHDR) will return a non-null pointer.
This fixes unwinding through a signal handler in gdb for all architectures.
It doesn't fix libunwind for arm and arm64. I'll keep investigating that...
Bug: 17436734
Change-Id: Ic1ea1184db6655c5d96180dc07bcc09628e647cb
Also clean up <signal.h> and revert the hacks that were necessary
for 64-bit in linker/debugger.cpp until now.
Change-Id: I3b0554ca8a49ee1c97cda086ce2c1954ebc11892
