1
0
Fork 0
mirror of https://github.com/tobast/libunwind-eh_elf.git synced 2024-11-29 18:27:37 +01:00
Commit graph

1812 commits

Author SHA1 Message Date
Rene Nielsen
cfd4306cc7 mips: fix compiler warnings
This fixes a number of compiler warnings I got when compiling for mips32el with
gcc 5.3.0.
2017-02-14 08:18:49 -08:00
Bert Wesarg
b15e74a884 dwarf: Utilize ELFs find_section to find the eh_frame.
Makes it thread-safe.
2017-02-02 08:29:17 -08:00
Bert Wesarg
1b960e54e9 elfxx: Add helper to find a section in ELF image. 2017-02-02 08:29:17 -08:00
Dave Watson
316a34a36e mips/tilegx: Add missing unwind_i.h header file
reported-by: John Knight <John.Knight@belkin.com>
2017-01-25 16:23:59 -08:00
Bert Wesarg
2e60ca34d2 dwarf: Fix warning about -Wmaybe-uninitialized.
```
src/dwarf/Gfind_proc_info-lsb.c:536:16: warning: 'eh_frame' may be used uninitialized in this function [-Wmaybe-uninitialized]
   Elf_W (Addr) eh_frame;
                ^
```

Introduced-in: 25413c729a
2017-01-24 11:09:25 -08:00
Bert Wesarg
4dea379ad9 x84_64: It's only 'mcontext_t'.
Fixes warning:
```
src/x86_64/Gos-linux.c:141:36: warning: initialization from incompatible pointer type
   struct mcontext_t *sc_mcontext = &((struct ucontext*)sc)->uc_mcontext;
                                    ^
```

Introduced-in: 29483327be
2017-01-24 11:09:14 -08:00
Saleem Abdulrasool
e9e8ed73e3 dwarf: Account for multiple CFA for args_size
It is possible to have multiple CFA_args_size adjustments for a single
frame.  If the CFA_args_size adjustment is immediately following the
return from a function which can raise an exception, it is possible to
incorrectly adjust the stack pointer.  Consider the following:

  ...
  .cfi_escape 0x2e, 0x00
  call f
.Ltmp:
  .cfi_escape 0x2e, 0x10
  lea label@GOTOFF(%ebx), %eax
  ...

Because we process the CFI program up to and *INCLUDING* IP, where the
IP is the RA, we would process the associated DW_CFA_GNU_args_size for
the post-call instruction.  The result would be a DW_CFA_GNU_args_size
of 0x10 rather than 0x00, resulting in an incorrect stack adjustment.
Handle this by processing the CFI operation but not adjusting the state
record unless we are below the current IP.
2017-01-19 10:07:53 -08:00
Konstantin Belousov
9e97c9b17a dwarf: Make binary path calculation os-specific.
/proc/self/exe only works on Linux, move path computation to os-* files
2017-01-19 10:07:13 -08:00
Vitaly Kuzmichev
7885596b9c arm: ptrace: Fix order of probing unwind tables
Commit 92327a3 "ARM: prefer to unwind using DWARF info"
changes order of unwind info searching to prefer DWARF (.debug_frame)
section in prior to ARM specific (.ARM.exidx). This patch only affects
local process unwinding. Now the same is done for remote unwinding.

Sometimes probing .ARM.exidx first causes backtrace truncation
after __aeabi_ldiv0 (division by 0 handler that generates SIGFPE),
because it hits [cantunwind] generated by cross-gcc for __divsi3
function copied with __aeabi_ldiv0 from libgcc.a. Perhaps, lack of
debug info for __divsi3 causes [cantunwind], or there is a problem
converting DWARF to ARM unwind tables, but when unwinding using
DWARF, it hits proper entry, and backtrace is shown correctly.

Reported-by: Frederic Berat <fberat@de.adit-jv.com>
Signed-off-by: Vitaly Kuzmichev <Vitaly_Kuzmichev@mentor.com>
2017-01-19 10:06:24 -08:00
Saleem Abdulrasool
11a053f5ca use target dependent names for stack registers
When adjusting the stack for a DW_CFA_arg_size adjustment, ensure that
we use the target dependent register name as the generic name does not
necessarily map to the same register.  For example, on x86, ESP maps to
the eip register, which results in the wrong stack adjustment being
applied.
2017-01-18 10:17:15 -08:00
Konstantin Belousov
09a598a3da Make the code compile on FreeBSD. 2017-01-18 09:18:29 -08:00
Guy Menanteau
7c079200d0 ppc64: Make access_fpreg function accept fp and v registers 2017-01-13 08:41:45 -08:00
Martin Dorey
1f4929c05d linux: Add /usr/lib/debug symbol path checking
Debian likes to hive off symbol information to separate -dbg packages,
installing the debug information in a parallel tree rooted at /usr/lib/debug.
libunwind doesn't know how to find these files but it's easy, per the tested,
attached patch, to make it so. I don't see /usr/lib/debug at
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA
but
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Debugging_with_gdb/separate-debug-files.html
says it's not just Debian and hints it might be driven by gdb. I do see mention
of /usr/lib/debug in libunwind already, but only in a DWARF-specific part of
the code.  A minor concern might be checking errno to see if the problem is
ENOENT before trying the alternate path. That might be better than flogging a
mmap problem or being out of file handles or whatever.
2017-01-13 08:36:37 -08:00
Dave Watson
a51cf49031 dwarf: Configurable cache size
Add interface for configurable dwarf cache size

* Use item size and round up to nearest power of 2.
* Initial cache still exists in BSS.  Without this, it means we would fail
  backtrace when out of memory.  The test-mem test fails without this
2017-01-13 08:36:33 -08:00
Dave Watson
29483327be x86_64: Use sigprocmask from signal frames
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
2017-01-13 08:28:22 -08:00
Dave Watson
4b63a536ee dwarf: Correct handling of DW_CFA_GNU_args_size
When resuming execution, DW_CFA_GNU_args_size from the current frame
must be added back to the stack pointer.  Clang now generates these frequently
at -O3.  A simple repro for x86_64, that will crash with clang ~3.9 or newer:

void f(int, int,int,int,int,int,int,int,int);

int main() {
  try {
    f(0,1,2,3,4,5,6,7,8);
  } catch (int) {
    return 0;
  }
  return 1;
}

Where f is something that throws an int, but in a different translation unit to
prevent optimization.

This results in cfi instructions before the call:
 .cfi_escape 0x2e, 0x20

Grabbing the args_size means fully parsing the cfi in the current frame, which
is unfortunate because it means nearly twice the work at each step.  The logic
to grab args_size can be in unw_step or get_proc_info (since this is always
called before resuming in stack unwinding).  Putting it in get_proc_info allows
the more common unw_step code to remain fast.

It would potentially fit in nicely with a proc info cache (as mentioned in the
if0 comment block)
2017-01-13 08:28:21 -08:00
Dave Watson
f7fe1c9a7e x86_64: Add stack alignment prologue tdep_trace fastpath
GCC versions 4.9~current will often generate stack alignment prologues like:

lea 0x8(%rsp),%r10
and $0xfffffffffffffff0,%rsp
...
push %rbp
mov %rsp, %rbp
push %r10

resulting in dwarf expressions:
DW_CFA_def_cfa_expression (DW_OP_breg6: -8; DW_OP_deref)
DW_CFA_expression: r6 (rbp) (DW_OP_breg6: 0)

These prologues seem to be generated for SSE/AVX code, but sometimes
other times as well.

tdep_trace fastpath currently falls back to the slow dwarf parsing path
if it encounters any cfa_expressions. Unfortunately this is happening
often enough in our codebase to cause perf issues.  We could also fix the
fallback path (make the rs cache bigger, lock-free instead of locking, etc),
but that seems like a separate issue, and it will ever be as fast as the tracing
code.   Our binaries each have at least ~100 functions in them like this.

This patch teaches the tdep_trace about the two specific cfa_expressions,
which really just result in a single extra memory dereference of the stack
at a fixed offset from rbp.
2017-01-13 08:28:21 -08:00
Jan Willeke
e5fe9034ad coredump: align coredump description pointer
next = inote.descdata + align_power (inote.descsz, 2);

this align is missing, leading to parsing errors. In one case
libunwind only found 1 thread out of 4.
2017-01-13 08:28:21 -08:00
Jonathan Byrd
25413c729a dwarf: Improve support for binaries missing the GNU_EH_FRAME segment
Improves support for binaries missing the GNU_EH_FRAME segment
(.eh_frame_hdr section) by adding a function
'dwarf_find_eh_frame_section' that can create a synthetic one.
2017-01-13 08:28:21 -08:00
Королев Сергей
fd44f596b2 tdep_uc_addr: use +4 offset for UNW_MIPS_PC on MIPS (be)
According to mcontext_t definition its "pc" field
is also 64 bit wide and thus requires 4 byte offset
on MIPS32 (be).
2017-01-13 08:27:40 -08:00
Chris Redmon
cf2bc87561 Fixup invalid return code checks of unw_is_signal_frame()
unw_is_signal_frame() returns <= 0 if not a signal frame. Several places in
code were only checking for a "if (unw_is_signal_frame())", or
"if (!unw_is_signal_frame())".
2017-01-13 08:27:40 -08:00
Королев Сергей
ad0d7633bc dwarf: check maps_init result
This fixes GCC 4.9.3 warnings (Linux/mipsel):

dwarf/Gfind_proc_info-lsb.c: In function 'locate_debug_info':
dwarf/Gfind_proc_info-lsb.c:244:23: warning: 'mi.buf_end' may be used
uninitialized in this function [-Wmaybe-uninitialized]
   struct map_iterator mi;
                       ^
dwarf/Gfind_proc_info-lsb.c:244:23: warning: 'mi.buf' may be used
uninitialized in this function [-Wmaybe-uninitialized]
In file included from dwarf/Gfind_proc_info-lsb.c:46:0:
./os-linux.h:292:27: warning: 'mi.buf_size' may be used uninitialized in
this function [-Wmaybe-uninitialized]
       munmap (mi->buf_end - mi->buf_size, mi->buf_size);
                           ^
dwarf/Gfind_proc_info-lsb.c:244:23: note: 'mi.buf_size' was declared here
   struct map_iterator mi;
                       ^
2017-01-13 08:27:39 -08:00
Giuseppe Ottaviano
bc8698fd7e [PATCH] x86_64: fix mincore_validate
The detection logic introduced in 28f33c8ce0 is
broken, because it tests mincore using an address that is almost certainly not
page-aligned. straces confirms that msync is used all the time.

This patch fixes the logic by page-aligning the test pointer. strace now shows
that mincore is actually used. Furthermore, the return value of mincore is not
sufficient to assess whether the address can be safely dereferenced: we should
also check that the pages are mapped, through the passed mvec array. This patch
also adds this verification.

Tested on a system where unwinding a stack across a JNI boundary would cause
sporadic segfaults; no more crashes were observed after the patch.
2016-02-29 11:05:42 -08:00
Ulrich Weigand
c56fb8f99e ppc64: Fix serious regression (many crashes in test suite)
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>
2015-12-06 11:10:10 -08:00
Keno Fischer
8afc33ce9f Add an option to have start_ip_offset be relative to start_ip
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.
2015-09-15 12:18:30 -07:00
Alexander Esilevich
d1a8ca6d84 powerpc64 implementation 2015-09-07 18:08:26 -07:00
Arun Sharma
923fa78e79 Revert parts of 68a2910
The check breaks a few tests when used with gold.
2015-09-07 17:59:27 -07:00
Vyacheslav Barinov
7701522688 arm: Validate memory before access
Prevent SIGSEGV due to accessing addresses now mapped to current process

Signed-off-by: Vyacheslav Barinov <v.barinov@samsung.com>
2015-06-07 12:17:40 -07:00
Faraz Shahbazker
16bf4e5e49 Stack-unwinding through signal frames on mips
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.
2015-04-02 11:20:33 -07:00
Peter Wu
68a2910bae Check that the CIE is within the segment
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>
2014-12-05 23:39:48 -08:00
Victor Kamensky
16e98c8cf3 aarch64: fix wrong big_endian flag in aarch64_be case
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>
2014-12-03 23:28:07 -08:00
C. Bergström
3babc1d148 aarch64: Restore x0, x1, x2 and x3
These registers contain the exception pointer and selector.
2014-10-24 22:40:19 -07:00
Paul Pluzhnikov
1bca6eb8ea Remove unnecessary calls to labs()
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
2014-10-24 22:29:15 -07:00
Arun Sharma
781d5d5263 One time whitespace fixup.
for f in $(find src include -name '*.[ch]'); do
  expand -t 8 $f > $tmp; mv $tmp $f;
done
2014-09-27 09:47:23 -07:00
Arun Sharma
06e608d043 Merge branch 'fast-stack-trace-arm' of https://github.com/fillexen/libunwind 2014-09-20 08:09:55 -07:00
Arun Sharma
6046c87d8e Merge branch 'fast-stack-trace-aarch64' of https://github.com/fillexen/libunwind 2014-09-20 08:09:35 -07:00
Arun Sharma
5d79a12ec0 Merge https://github.com/zliu2014/libunwind-tilegx 2014-09-20 00:47:23 -07:00
Zhi-Gang Liu
790be1e40d Add TileGx platform support to libunwind.
"make check" passed.
======================================================
All 34 tests behaved as expected (2 expected failures)
======================================================
Zhi-Gang Liu @ Tilera
2014-09-08 16:21:53 -04:00
Arun Sharma
0808aa6737 Stop unwinding on undefined return address
Milian Wolff <mail@milianw.de> reported that this greatly
improved unwinding perf on some his apps.
2014-09-07 03:32:57 -07:00
Paul Pluzhnikov
e63cadf76d Remove unnecessary calls to labs()
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
2014-08-15 13:01:47 -07:00
Konstantin Belousov
dbce594d33 Correct name returned by get_proc_name() for some frames.
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.
2014-08-15 13:01:40 -07:00
Konstantin Belousov
3723511003 Adjust use_prev_instr for syscall and frame-chain frames.
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.
2014-08-15 13:01:36 -07:00
Konstantin Belousov
85946d9766 Use helper to walk past the syscall frames on FreeBSD/x86, similar to FreeBSD/x86_64.
The syscall trampolines in FreeBSD libc do not have unwind annotations.
2014-08-15 13:01:33 -07:00
Filip Nyback
93d8272481 Add fast stack trace on AArch64.
Port of the fast stack trace feature to AArch64.
2014-07-30 14:34:31 +03:00
Filip Nyback
e1804829ca Add fast stack trace on ARM.
Port of the fast stack trace feature to ARM.
2014-07-30 14:25:14 +03:00
Martin Milata
65ac867416 Do not compute load offset for MiniDebugInfo
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>
2014-06-07 18:07:06 -07:00
Kevin Modzelewski
4509adb853 x86_64: Handle edge conditions with zero length frames
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>
2014-05-18 19:39:26 -07:00
Christopher Ferris
2cb00c1eac AARCH64: Change Debug calls to use %lx instead of %x.
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>
2014-03-07 22:52:24 -08:00
Mike Frysinger
385c19f335 link sublibs against liblzma as needed
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>
2014-02-22 10:53:39 -08:00
Tim Deegan
4eb880e1b5 Implement DWARF DW_CFA_val_expression for x86_64
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>
2014-02-08 20:19:20 -08:00