A recent commit added code to override the unwind location for the
TOC pointer register r2:
unsigned int *inst = (unw_word_t*)c->dwarf.ip;
if (*inst == (0xE8410000 + 24)) {
// @plt call, restoring R2 from CFA+24
c->dwarf.loc[UNW_PPC64_R2] = DWARF_LOC(c->dwarf.cfa + 24, 0);
}
It is correct that such code is needed, since DWARF CFI does not
describe the unwind location for r2 on PowerPC. However, this
particular bit of code has a number of issues, which are fixed
in this patch.
First of all, the location CFA+24 is correct only for the ELFv2
ABI. In the ELFv1 ABI, the TOC location is actually CFA+40.
More problematically, attempting to read the current instruction
by just dereferencing the address in c->dwarf.ip is wrong, and
may often lead to crashes. In particular:
- During remote unwinding, this is always wrong since we're in
the wrong address space. I've used the fetch32 helper from
remote.h to use the proper access_mem under the covers.
- c->dwarf.ip may be NULL if we've reached the end-of-stack.
I've fixed this by moving the c->dwarf.ip == 0 check down
to after unwinding (instead of before), just like all other
platforms do.
- Even so, c->dwarf.ip may point to some random location if
we've gotten confused during unwinding earlier. One likely
cause for such confusion is that we did not find DWARF CFI
for some earlier frame and attempted to use the stack
backchain. The problem is that this code currently claims
all registers remain unchanges in such a frame, which is
generally wrong. In particular if the function actually
saves and modifies r31, and this is used as frame pointer
by a later frame, things will likely go quite wrong. While
it is not really possibly to completely fix this, I've at
least marked all registers as unavailable after unwinding
a frame via stack backchain.
Tested on powerpc64-linux and powerpc64le-linux. The patch fixes
about a dozen test cases that were crashing before.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
By default, the start_ip_offset in libunwind's table_entry struct is
relative to the unw_dyn_info_t's segbase. This presents a problem
for us in conjunction with using LLVM's MCJIT because it likes to
spread text sections and the corresponding eh_frame sections quite
far apart. This represents my attempt to support this use case in the
simplest manner that is backwards compatible, by adding a new format
kind (UNW_INFO_FORMAT_REMOTE_TABLE2) that indicates that the
`start_ip_offset` should be interpreted as relative to `start_ip`
rather than segbase.
Detect if current frame is a signal frame by checking for preceeding
syscall instruction. For signal frames, update the cursor correctly
from user context before calling dwarf_step.
Due to a bug in the gold linker[1], the .eh_frame and .eh_frame_hdr
sections contains garbage. When dwarf_extract_proc_info_from_fde tried
to look up the begin of the CIE subsection, it would underflow the
.eh_frame segment, resulting in a crash[2].
This patch avoids that crash by checking whether the CIE pointer is
located after the begin of the .eh_frame section. The variable "base"
was misused in various places as a boolean (decode as .debug_frame or
decode as .eh_frame). These instances have been renamed to
is_debug_frame where applicable.
Tested on Linux x86_64.
[1]: https://sourceware.org/bugzilla/show_bug.cgi?id=17639
[2]: http://lists.nongnu.org/archive/html/libunwind-devel/2014-11/msg00009.html
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Set local_addr_space.big_endian flag according to current target
endianness. Before it was set by memset to 0, which corresponds
to little endian and it worked perfectly fine for aarch64.
But it breaks aarch64_be because dwarf_readu16, dwarf_readu32,
etc functions do not read values correctly since they operate
with wrong idea about current target endianness.
Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
We've just traced a large memory increase to that patch (Google ref:
b/18069427).
It appears that labs() was there for a good reason.
Sorry about that :-(
For the curious:
unsigned long u1 = ~0UL;
unsigned long u2 = labs(u1);
assert(u1 != u2); // labs on unsigned *may* have an effect, despite
what Clang says.
Attached patch suppresses the Clang warning, while still keeping the
original behavior (which I believe to be correct).
Thanks,
--
Paul Pluzhnikov
Greetings,
Roman reports that Clang warns on unnecessary calls to labs():
taking the absolute value of unsigned type 'unw_word_t' (aka
'unsigned long') has no effect [-Werror,-Wabsolute-value]
Since rs->reg[...].val is unw_word_t and unsigned on all platforms,
this patch removes the unnecessary calls to labs().
Tested on Linux x86_64, no regressions.
Thanks,
--
Paul Pluzhnikov
Fix returning the name of the function containing the frame PC,
for the non-interrupted frames. The symbol lookup code should
take use_prev_instr value into account, otherwise it could return
the name of the function adjacent to the caller.
Mark frames which are unwound with the frame-chain walker or
syscall frame code, as non-interrupted. The return PC in the frame
points to the instruction after the call.
We already have the value computed based on the executable. Furthermore,
debuginfo need not have valid program header table, thus the result
might be bogus.
Signed-off-by: Martin Milata <mmilata@redhat.com>
When JITs generate code without unwind information, it may be possible
to continue unwinding via RBP chaining. However, we currently disallow
RBP==RSP condition even though we can make forward progress.
Relax the check a bit in the code where we switch from one type of
unwinding to another to handle this situation. JIT authors
are encouraged to use the dynamic unwind info registration API when
the underlying platform supports it.
Signed-off-by: Kevin Modzelewski <kmod@dropbox.com>
The attached patch simply modifies the Debug statements for aarch64 to use
%lx instead of %x. Tested by compiling for aarch64 using a cross-compiler.
Signed-off-by: Christopher Ferris <cferris@google.com>
The coredump/elf32/elf64/elfxx libs use lzma funcs but don't link against
it. This produces sub-shared libs that don't link against lzma and can
make the linker angry due to underlinking like so:
libtool: link: x86_64-pc-linux-gnu-gcc -O2 -march=amdfam10 -pipe -g \
-frecord-gcc-switches -Wimplicit-function-declaration -fexceptions \
-Wall -Wsign-compare -Wl,-O1 -Wl,--hash-style=gnu \
-o .libs/test-coredump-unwind test-coredump-unwind.o \
../src/.libs/libunwind-coredump.so ../src/.libs/libunwind-x86_64.so
../src/.libs/libunwind-coredump.so: error: undefined reference to 'lzma_stream_footer_decode'
../src/.libs/libunwind-coredump.so: error: undefined reference to 'lzma_index_buffer_decode'
../src/.libs/libunwind-coredump.so: error: undefined reference to 'lzma_index_size'
../src/.libs/libunwind-coredump.so: error: undefined reference to 'lzma_index_end'
../src/.libs/libunwind-coredump.so: error: undefined reference to 'lzma_index_uncompressed_size'
../src/.libs/libunwind-coredump.so: error: undefined reference to 'lzma_stream_buffer_decode'
collect2: error: ld returned 1 exit status
So add LIBLZMA to the right LIBADD for each of these libraries.
URL: https://bugs.gentoo.org/444050
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Ubuntu's libc-bin (2.15-0ubuntu20.2) on x86_64 uses DW_CFA_val_expression
in describing the pthread spinlock operations __lll_unlock_wake() and
__lll_lock_wait(). libunwind 1.1 doesn't understand that opcode and
so backtraces from those operations are truncated.
This changeset adds basic support for it, by adding a new type to
dwarf_loc_t that describes the register's actual contents rather than
its location. I've only implemented the new type for x86_64, and
stubbed it out for all other architectures -- it looks like a lot
of that code is duplicated so oughtn't to be that hard, but I don't
have test cases for them.
Tested that DW_CFA_val_expression works on x86_64 (by using
https://code.google.com/p/gperftools/ on a lock-heavy program).
Build-tested on x86, x86_64 and arm. The unit tests don't pass for me
on any of those archs, but this cset doesn't break anything that was
passing before.
Signed-off-by: Tim Deegan <tjd@phlegethon.org>
This patch adds support for the powerpc64le-linux platform. It consists
of two main features:
- Support little-endian byte order
This is done via a "big_endian" member of struct unw_addr_space,
which is evaluated by common code via the dwarf_is_big_endian
macro, and also in endian-aware code in unw_is_signal_frame.
- Support the ELFv2 ABI
This is done via an "abi" member of struct unw_addr_space. This
is currently only needed in tdep_get_func_addr, since the ELFv2
ABI does not use function descriptors.
Both new members are initialized in unw_create_addr_space and
ppc64_local_addr_space_init, following the mips precedent.
Since ppc32 and ppc64 now no longer share the unw_create_addr_space
implementation, the file is duplicated from the ppc directory into
ppc32/ppc64.
Tested on powerpc64-linux and powerpc64le-linux. Support on LE
seems to be as good as existing BE support; I have not attempted to
fix the existing shortcomings of PPC support that already cause a
number to tests to fail due to unimplemented features.
Signed-off-by: Ulrich Weigand <uweigand@de.ibm.com>
The ppc64 implementation of tdep_get_func_addr would crash when
attempting to retrieve the address of a function in a shared
library. The problem was that it needs to dereference the
function descriptor, but common code was passing the *unrelocated*
adddress of the descriptor to the tdep_get_func_addr routine.
Instead, common code would attempt to relocate the *result* of
tdep_get_func_addr, which is also wrong: the ppc64 implementation
reads the function address from the in-memory copy of the
descriptor, which is already relocation and contains the final
address.
This patch fixes the problem by relocating the descriptor address
before passing it to tdep_get_func_addr, instead of relocating
the result of tdep_get_func_addr. Since ppc64 is the only
non-trivial implementation of tdep_get_func_addr, this cannot
affect any other platform.
Signed-off-by: Ulrich Weigand <uweigand@de.ibm.com>
