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.
dwarf: If the dwarf_readu8 call to set op fails, and if there are register
states pushed onto the stack, the stack is not emptied before the function
returns. This change addresses that.
Most of the rest is eliminating ‘goto fail’ from the code.
0-valued hints are used when they are just initial values with no use as
hints. And I think there were some other problems as well.
This patch cleans up and stores hint values with 1 added, so that 0-valued
hints can be ignored.
In src/ppc64/Gstep.c, we use fetch32 to fetch instruction from the
inferior process. In UNW_REMOTE case, fetch32 asserts that the
address we are fetching from is aligned.
But if the inferior is corrupt, we can get unaligned IP, and hit the assert.
Attached patch removes the assert, and makes fetch32 (and fetch16)
return -UNW_EINVAL instead.
unw_get_proc_info must always load the unwind info so that unw_resume
works with GNU_args_size expressions, but must not update
use_prev_expr unless we are unw_step()ing.
blame rev: 4b63a536ee
reported-by: Doug Moore <dougm@rice.edu>
