| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
|
|
|
|
|
| |
Since glibc 2.32 [1], sigemptyset() no longer clears the entire sigset_t.
[1] "signal: Use <sigsetops.h> for sigemptyset, sigfillset" (9f6bd1f6057e57cce9b07844c28f15859ab15d49)
|
|
|
|
| |
In NixOS, coreutils aren't in their FHS-mandated locations.
|
|
|
|
| |
See #222 and #227. The tests are so fragile :(
|
| |
|
|
|
|
|
|
| |
unw_step should return zero for _MIPS_SIM != _ABI64 when dwarf_step failed.
This restores unw_step behaviour before 5eec9a2ecb9a93996d566bbfbcdbe006f64b7e16
for _ABIN32 and _ABIO32 interfaces.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This commit adds support for Linux on RISC-V. Only 64-bit is supported
at the moment.
|
| |
|
| |
|
|
|
|
|
|
| |
Some cfis may access registers that aren't saved on the trace path.
Set all these registers to null locations, so that attempting to use
them causes us to fall back to the slow path.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
https://bugs.gentoo.org/586092
this might not be correct, but at least it builds, and doesn't crash.
|
|
|
|
|
|
|
|
|
|
| |
coredump/_UPT_get_dyn_info_list_addr.c
is almost identical to
ptrace/_UPT_get_dyn_info_list_addr.c
It's clearly an __ia64 implementation copy.
|
| |
|
|
|
|
|
| |
PPC32 support was confirmed in #127, but this info was not added to the README.
To make things clear, add ppc32 to the supported arch/os table.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Fix unwinding GPRs that were saved in FPRs
Since DWARF_FPREG_LOC locations satisfy *both* DWARF_IS_REG_LOC
and DWARF_IS_FP_LOC, code that has to distinguish between the
two must check DWARF_IS_FP_LOC *first*.
This fixes a failure in test-ptrace on Ubuntu 20.04.
- Fix build using (older versions of) clang
Use fully-qualified register names (%r15) in inline asm.
Those work with all existing compilers.
- Add missing s390x include in include/tdep/dwarf-config.h
- Add s390x files to CMakeLists.txt to enable cmake build
|
|
|
|
| |
Signed-off-by: Mikhail Durnev <mikhail_durnev@mentor.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nm shows that those two symbols are undefined, it happens when
./configure --target=host is used and when --enable_debug_frame is set.
nm src/.libs/libunwind-aarch64.so.8.0.1
...
U _Uelf64_find_section
U _Uelf64_load_debuglink
...
This change will prevent build issues until there is remote debug_frame
support on arm.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When creating a local x86_64 cursor, its `dwarf.as_arg` member is set to
point to the cursor itself, making it a self-referential struct. This
does not allow to safely keep a copy of a cursor, as stated in the
documentation. In addition, the self-reference is used to access just
two members: `uc` and `validate`.
This commit modifies `dwarf.as_arg` to pack together both `uc` and
`validate`, so the x86_64 cursor is not self-referential anymore and no
additional memory allocation is performed. Since `uc` points to a
`ucontext_t`, which is at least 2-byte aligned, it is safe to store the
`validate` bit in the LSB of the `uc` pointer.
Additional checks were added to verify that the `validate` bit is not
set when the cursor is non-local.
|
| |
|
|
|
|
| |
offet.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
While cross-compiling strace against libunwind for ARM, the configure
script of strace failed with:
libunwind-ptrace.h:40:27: error: a parameter list without types is only
allowed in a function definition
it turns out that we do not have a definition for what pid_t should be,
so include sys/types.h to remedy that.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
read/executable program header offsets not always aligned on a page size.
For example, the same library, linked with ld.bfd will show these PT_LOAD mappings:
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x000000000002b3d0 0x000000000002b3d0 R 0x1000
LOAD 0x000000000002c000 0x000000000002c000 0x000000000002c000
0x000000000001b729 0x000000000001b729 R E 0x1000
LOAD 0x0000000000048000 0x0000000000048000 0x0000000000048000
0x000000000000fb17 0x000000000000fb17 R 0x1000
LOAD 0x0000000000057fb0 0x0000000000058fb0 0x0000000000058fb0
0x00000000000010b0 0x0000000000001508 RW 0x1000
while ld.lld, from the very same .o files, will link it like this:
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x000000000003b32c 0x000000000003b32c R 0x1000
LOAD 0x000000000003b330 0x000000000003c330 0x000000000003c330
0x000000000001b740 0x000000000001b740 R E 0x1000
LOAD 0x0000000000056a70 0x0000000000058a70 0x0000000000058a70
0x0000000000001050 0x0000000000001050 RW 0x1000
LOAD 0x0000000000057ac0 0x000000000005aac0 0x000000000005aac0
0x0000000000000060 0x00000000000004b3 RW 0x1000
Failure to identify the load_offset from iterating the program header lead to later being unable
to find the correct proc_info for a given symbol.
|
|
|
|
| |
Also delete > 10 year old entries.
|
|
|
|
| |
This disallows frame reuse for tail and other sibling calls.
|
| |
|
|
|
|
|
|
| |
I am not sure why it should lie about the PC register and use a
different random value (LR), when the actual value is also easily
available. The rate of passing tests seems to be the same.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Better support unw_resume, by returning r0 from the user, instead of
hard-coding it to zero (also incidentally fixing a compiler warning
about an unused expression). This better mimics a real function call,
instead of hard-coding the return value. When in thumb mode, this also
means we also need to avoid switching between thumb and ARM upon return
to this point, so we need to set the pc accurately to point after the
return instruction. When in ARM mode, we need an extra nop also to point
at the correct return instruction (since the stored value of pc in the
context runs ahead by 8 bytes, while stmia is only 4 bytes).
|
|
|
|
|
|
| |
The test is unwinding a precise number of frames, which assumes the
compiler will not inline these functions. Mark this explicitly to be
more reliable, and add some more verbose debugging aids.
|
|
|
|
|
| |
Previously the PC value was being set to the LR instead, causing many
tests to fail.
|
|
|
|
|
|
|
| |
Based on:
- dl_iterate_phdr() patch by Jeff Muizelaar.
- maps_next() improvement from AOSP: 7d46a21.
- unwi_unwind_method and x86_local_resume() from AOSP: 1c82a52.
|
|
|
|
|
| |
Typically resulting in a crash during local unwinding on e.g.
Android/arm64, where the calculated load_offset would be zero.
|
|
|
|
|
| |
According to GLIBC headers those are in fact double (8 Byte) not
long double (16 Byte)
|
|
|
|
|
|
|
|
|
|
| |
Missing open paren.
fixes: #210
blame:
77ac8f1c6366192407735b8829253b3810417dea
|
|
|
|
|
|
|
|
| |
Currently failing cxx exception test. Need to debug.
Blames to f1cee65e7594db55244723c418559b425297e7e1
hoever, this just exposed the problem by building the test,
it's probably been broken for a while (so a revert won't help)
|
|
|
|
| |
Conditionally check for NT_FILE note coredump handling.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Prelinker updates section .eh_frame but does not change section .debug_frame.
Libunwind can work with prelinked .eh_frame, but if fails to find call frame
info in unmodified .debug_frame because it does not add the load offset.
ELF load offset from PT_LOAD p_vaddr has to be used to correctly interpret
addresses in the .debug_frame section.
Signed-off-by: Mikhail Durnev <mikhail_durnev@mentor.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The libunwind code base uses __linux__ already in many locations, but
some others relied on __linux instead. Apparently on some older
toolchain configurations, such as Ubuntu Trusty that's still used for
AppImage generation sometimes, __linux is never defined - only
__linux__ is. Fixes compiler warning on such platforms:
```
coredump/_UPT_get_dyn_info_list_addr.c: In function 'get_list_addr':
coredump/_UPT_get_dyn_info_list_addr.c:86:3: warning: #warning Implement get_list_addr(), please. [-Wcpp]
# warning Implement get_list_addr(), please.
^
```
|