I tried to build libunwind for arm target and got a build error. Type
for "uc" argument is inconsistent between unw_init_local2 and
unw_init_local_common.
From 54fb6483e47916836c314a38715e8e0ce8c3da44 Mon Sep 17 00:00:00 2001
From: Guillaume Blanc <guillaume.blanc@parrot.com>
Date: Tue, 22 Aug 2017 16:46:20 +0200
Subject: [PATCH] arm: Fix unw_init_local2 argument type
Attached is a corrected version of my previous patch for aarch64 PLT
entry recognition. The comparison in the is_plt_entry function should
have been:
ret = (((w0 & 0xff0000009f000000) == 0xf900000090000000)
&& ((w1 & 0xffffffffff000000) == 0xd61f022091000000));
We were testing libunwind-coredump and got some warnings about
uninitialized eh_valid_mask.
The code was working fine because the default value of the mask was 0, but
it could potentially take a wrong branch if there's garbage in memory.
If I configure with ./configure --prefix= --enable-shared --disable-static, a
broken symlink lib/libunwind-generic.a is installed that points to a missing
architecture-specific version of that library (e.g. lib/libunwind-x86_64.a). I
suppose that not installing that library is the intended behavior with these
configuration settings, so the symlink should not be there in the first place.
Reported-by: MarcoKoch
Some binaries contain a gnu_debuglink, even though the actual
file it points to doesn't exist. In those cases, continue
to use the existing binary instead of trying to load the debuglink file.
The ARM Thumb implementation of unw_tdep_getcontext switches to ARM
mode (".code 32"), but doesn't switch back to Thumb mode.
In gcc, this is fine (it automatically switches back to Thumb mode
at the end of an asm block), but in clang, this causes bad assembly
output (thumb instructions generated by C/C++ code later on are
interpreted as ARM mode assembly, which can't work).
Switching back to Thumb mode manually fixes clang, and is a no-op for gcc.
If Thumb is used, the least bit of the retrived IP value is set,
which makes the retrived opcode based on the IP invalid.
This patch fixes such behavior and adds a missed condition
found with glibc built for recent ARMv7l with Thumb2.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
CC: Yvan Roux
CC: Arun Sharma
CC: David Mosberger
Let's not drop error code or zero-return unconditionally.
This has been incurring occasional indefinite loop in
dotnet core when it already had hit the bottom by
continously returning 1 from unw_step();
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
The and mask trick only works for power-of-two sized things,
but must be computed using the full size. This incorrectly
resulted in a very small cache size.
Found using bisect and 'make perf' in tests directory.
blame rev: 0b51f5892d
In remote ptrace mode, we currently use PTRACE_PEEKUSER to read the registers.
PTRACE_PEEKUSER only works on x86 or arm 32 bit compatibility mode on linux. On aarch64 system,
it always return -EIO. https://github.com/torvalds/linux/blob/master/kernel/ptrace.c#L885-L1102
PTRACE_GETREGSET is the newer and more supported way of reading registers. Use that if it's available.
We've tried to run slightly modified test-coredump-unwind.c built with
tcmalloc, and it promptly crashed. Attached patch fixes the heap buffer
overflow bug which caused it.
Add register state and state iterate functions to ppc32 and ppc64
directories. They were added to other arch directories in change
502ba27753... but not these, for some reason.
Commit dbce594d33
added unconditional dwarf usage into unw_get_proc_name.
Unfortunately ia64 is the only architecture that
does not support it in libunwind (configure.ac):
```
if test x$target_arch != xia64; then
use_dwarf=yes
else
use_dwarf=no
fi
```
As a result build fails on ia64 as:
```
ia64-unknown-linux-gnu-gcc ... -c mi/Lget_proc_name.c ...
In file included from mi/Lget_proc_name.c:4:0:
mi/Gget_proc_name.c: In function '_ULia64_get_proc_name':
mi/Gget_proc_name.c:107:8: error: 'struct cursor' has no member named 'dwarf'
if (c->dwarf.use_prev_instr)
^~
mi/Gget_proc_name.c:111:8: error: 'struct cursor' has no member named 'dwarf'
if (c->dwarf.use_prev_instr && offp != NULL && error == 0)
^~
```
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Usage of the single_fde field in cb_data suggests that it should be
set only when dwarf_extract_proc_info_from_fde has completed successfully,
but instead it is set before the linear search for the matching ip has
begun. Set it only when that search has completed successfully, and
has thus extracted the proc_info.
Ben Avison (bavison@riscopen.org) has observed that when a synthetic
eh_frame_hdr is generated, there is no space in it for the eh_frame,
so the eh_frame value is written to, and later read from, memory that
is not assigned to this purpose, with unpredictable results.
This change adds a new field to the dwarf_eh_frame_hdr type, to
make room for that value, and adds the (packed) attribute to the
struct defintion to avoid a problem with unused space in the struct.
This allows libunwind to work in situations with limited stack size (ie. fibers). 512 is still more than enough for storing the cursor with some slack. (#25)
Rather than using a copy of dwarf_find_proc_info that differs from it slightly.
By using dwarf_find_proc_info, a potential search of the di table is
allowed, where it is omitted now. Also, for ARM, avoid runtime
checks about which kind of unwind table search to use after dl_iterate_phdr.
A couple of Debug() warnings about ip lookup failure are lost here.
The dwarf callback struct defintion is moved to Gfind_proc_info-lsb.c,
which becomes the only source file that needs it.
previous stack frame was the last, just as unw_step does. For x86_64,
drop the null check for ret_addr_column, since that check is made already
in apply_reg_state.
so that it will get saved and restored with the register state. Initialize
the rs_state version of ret_addr_column at the some time the dwarf_cursor
version is initialized, and don't bother copying ret_addr_column explicitly
from cursor to cache since it's copied implicitly as part of reg_state.
Use the reg_state version in apply_reg_state, instead of the cursor version.
Which brings up the question: why do we have ret_addr_column in the dwarf_cursor?
We call find_reg_state before calling apply_reg_state, so the value of ret_addr_column
in the cursor when dwarf_step gets called gets overwritten before it is used. So
it's initial value doesn't matter. But some architectures do funky things with
cursor->ret_addr_column, even though I don't see how they matter.
So I'm not deleting dwarf_cursor->ret_addr_column, even though I suspect this
patch makes it useless.
