src/ptrace/_UPT_find_proc_info.c: In function 'get_unwind_info':
src/ptrace/_UPT_find_proc_info.c:67: warning: implicit declaration of function 'ia64_find_unwind_table'
Add support for the 32bit SuperH architecture running Linux.
Specifically, support is added for SH4, and support for earlier SH
versions and to the 64bit SH5 are left out. This was tested in qemu with
a little-endian SH4 debian image & GCC 4.7 cross compiler.
Add MIPS support to the coredump library. Explicit support for the MIPS
program counter register is added so that we can start backtracing from
the program counter value we read from a core dump. The PC register
support was not strictly required for local backtracing, and we will in
fact just plug the return address to the PC register in getcontext().
I have only tested the 32bit "OABI" paths.
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]
In file included from src/ia64/Ginit_remote.c:26:0:
src/ia64/init.h: In function 'common_init':
src/ia64/init.h:32:12: warning: variable 'natp' set but not used [-Wunused-but-set-variable]
We can use the __sync builtin atomics also on other architectures than
IA64. GCC 4.7 documentation notes that these builtins are ``legacy'' --
adding support for the newer GCC __atomic atomics should be fairly easy.
Instead of maintaining a pointer to the `sos_memory' array, maintain an
index that tells the next free position. When atomic operations are
available, the allocation boils down to a single fetch-and-add
operation.
To ensure that we return properly aligned pointers from sos_alloc(),
MAX_ALIGN must be a power-of-two. On i386 the power-of-two assumption
fails as sizeof(long double) = 12. Fix this by rounding up to 16.
Use the __BIGGEST_ALIGNMENT__ macro provided by GCC for sos_alloc()
allocation alignment. The macro gives ``the largest alignment ever used
for any data type on the target machine you are compiling for.''
__BIGGEST_ALIGNMENT__ also has some other nice properties, e.g. it is
power-of-two on all architectures (note that on i386, sizeof(long
double) = 12), and on some architectures (e.g. SuperH) the alignment
requirement can be lower than sizeof(long double).
tdep_get_func_addr in ppc64 passes NULL for the last argument of
as->access_mem. tdep_get_func_addr is called by elf_w(lookup_symbol),
which in turn is called by elf_w(get_proc_name_in_image).
elf_w(get_proc_name_in_image) is part of the API, and is only passed an
unw_addr_space_t, not a unw_cursor_t, meaning that we cannot recover the
UPT_info on the PPC64 platform.
This could be fixed by giving libunwind the knowledge to perform
relocations itself, thus not needing to look at the running image to
determine function addresses.
