Currently setcontext for x86_64 restores the signal mask, even
though it is never saved anywhere. This means the signal mask
is often garbage after an unw_resume.
(changed in commit f8a15e9679)
It looks like this was a fix for the Gtest-resume-sig function -
testing if signal masks are restored across signal frames. The
root issue looks like that x86_64 only uses sigreturn for the exact
signal frame, and not for any decedant frames as well (as i64 does).
Instead, modify Gresume to use sigreturn if *any* frame on the stack
is a signal frame, so that we correct fixup the signal mask and any
sigaltstacks. The sigreturn os-specific functions are changed slightly
to copy in the saved ucontext structure if we are jumping farther
up the stack.
This should fix sigprocmask reported issues such as
https://github.com/dropbox/pyston/blob/master/libunwind_patches/0002-pyston-stop-x86_64-setcontext-restoring-uninitialize.patch
Tests pass on freebsd, linux
Read the address using strtoul(). If strtol() is used and the number is
bigger than LONG_MAX, LONG_MAX is returned instead, which leads to a failure
if the mapping address is 0x80000000 or larger on 32-bit platforms (and
similarly for 64-bit platforms).
If we don't link to libexecinfo, as detected by the
AC_SEARCH_LIBS(backtrace, execinfo) configure probe, we get
```
test-coredump-unwind.o: In function `handle_sigsegv':
/home/libunwind/tests/test-coredump-unwind.c:246: undefined reference to
`backtrace_symbols_fd'
collect2: error: ld returned 1 exit status
Makefile:1187: recipe for target 'test-coredump-unwind' failed
```
and
```
Gtest-init.o: In function `do_backtrace()':
Gtest-init.cxx:(.text+0x2f): undefined reference to `_Ux86_64_getcontext'
Gtest-init.cxx:(.text+0x48): undefined reference to `_Ux86_64_init_local'
Gtest-init.cxx:(.text+0x63): undefined reference to `_Ux86_64_get_reg'
Gtest-init.cxx:(.text+0x96): undefined reference to `_Ux86_64_get_proc_name'
Gtest-init.cxx:(.text+0x171): undefined reference to `_Ux86_64_step'
collect2: error: ld returned 1 exit status
Makefile:1063: recipe for target 'Gtest-init' failed
```
There are 2 XFAIL and 6 FAIL tests, but it's a start
Add dummy assign statements at the top so we don't have to trace all
the different if paths to see where the value is initially assigned.
Now all code paths just append it.
It looks like the dynamic frame support isn't fully baked on
non-ia64, leading to lots of mailing list comments about broken
tests (even though they're marked as supposed to fail, it's still
confusing).
This is similar to commit c90a2e02b3
"Mark run-ptrace-mapper and run-ptrace-misc as XFAIL on MIPS".
Starting with 2.6.39, ARM Linux returns -EIO for PTRACE_SINGLESTEP, so
we need to mark this as XFAIL for ARM too.
The Linux commit that changed this is
commit 425fc47adb5bb69f76285be77a09a3341a30799e
Author: Will Deacon <will.deacon@arm.com>
Date: Mon Feb 14 14:31:09 2011 +0100
ARM: 6668/1: ptrace: remove single-step emulation code
see: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=425fc47adb5bb69f76285be77a09a3341a30799e
Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
Though PTRACE_SINGLESTEP is defined on MIPS Linux, the kernel does
not support that kind of request. The ptrace call failed and sets
errno to EIO and paused process is not resumed. In case of
run-ptrace-mapper and run-ptrace-misc this leads to hanged execution
because next call to wait4 never returns.
This change adds run-ptrace-mapper and run-ptrace-misc to the list
of 'expected failed' tests on MIPS targets.
Signed-off-by: Simon Atanasyan <simon@atanasyan.com>
On systems where the system compiler supports Altivec by default,
the libunwind Makefile will attempt to build an extra test case
ppc64-test-altivec. Unfortunately, the link step will fail since
the Makefile does not actually link against the libunwind library.
Fixed by adding the appropriate LDADD macro.
Signed-off-by: Ulrich Weigand <uweigand@de.ibm.com>
The crasher test is used as part of the coredump test suite,
but is being built regardless of whether that support has been
configured or not. This patch changes the build so that it is
only built when coredump support is enabled.
Currently, libunwind-setjmp is built whenever local unwinding is
built. This patch adds an explicit flag to control it instead.
The default if not specified is to follow the old behavior.
This change adds a manual override to control building of the ptrace
library, similar to the existing --enable-coredump option. The
default is set based on the existence of sys/ptrace.h, allowing it
to be automatically disabled for platforms that do not have ptrace.
We do not really need to care if the system provides `backtrace()',
since we will want to test the one provided in libunwind, not the one
that is provided by the system. The `backtrace()' calls should already
be aliased to `unw_backtrace()', but if that is not working for whatever
reason, we can call `unw_backtrace()' explicitly.
We are building only a UNW_LOCAL_ONLY build of `test-nocalloc', and the
"generic" build would not be very interesting. Roll the whole test into
`Ltest-nocalloc.c'.
Only build a "local-only" version of `rs-race'. The "generic" build is
not very entertaining, as the `unw_set_caching_policy()' calls
manipulate the `unw_local_addr_space' in libunwind-$arch.so, while the
`backtrace()' calls use the address space object from libunwind.so
behind the scenes.
Cleanup dynamically allocated memory before exit in tests in a few
places where missing. While such cleanups right before exit do not
usually make much sense (as the operating system would cleanup anyway,
so manual cleanups only burn CPU cycles), we will want to catch any
potential problems in libunwind related to the cleanups. This also stops
valgrind complaining about unreleased memory.
tests/test-coredump-unwind.c: In function 'handle_sigsegv':
test-coredump-unwind.c:216:15: warning: variable 'uc' set but not used [-Wunused-but-set-variable]
This one is for architectures that we have not specifically added
support for in `tests/test-coredump-unwind.c'.
tests/test-coredump-unwind.c: In function 'handle_sigsegv':
test-coredump-unwind.c:238:10: warning: 'ip' is used uninitialized in this function [-Wuninitialized]
Disable the building of libunwind-coredump except on x86_64 and x86
(where implimentations exsist).
Allow overriding of this autodetection via --enable-coredump and
--disable-coredump.
test-varargs is checking how `backtrace()' provided by the system
behaves when varargs are used. Let's make the test more useful by
changing it to test the `backtrace()' provided by libunwind.
Change the testcase to return 0/1 for success/failure, and add it to the
set of checks, so that it gets run on `make check'. Also call
`unw_backtrace()' explicitly so that we do not need to bother with
`execinfo.h' and `backtrace()' prototype.
Fixup commit 39b83981 ("Flush icache with __builtin___clear_cache() in
tests when compiling with GCC") to fix compilation with older GCC
versions that do not provide __builtin___clear_cache().
When compiling with GCC, use the builtin instruction cache flushing
mechanism in all tests where it is needed.
Quoting GCC docs: ''If the target does not require instruction cache
flushes, __builtin___clear_cache has no effect. Otherwise either
instructions are emitted in-line to clear the instruction cache or a
call to the __clear_cache function in libgcc is made.''.
