We do not modify `_UPT_reg_offset', so let's set it `const'. Given that
the array is exported, it's technically possible that some library user
is actually modifying the content, but does not seem really all that
likely.
Add support for the 32bit SuperH architecture running Linux.
Specifically, support is added for SH4, and support for earlier SH
versions and to the 64bit SH5 are left out. This was tested in qemu with
a little-endian SH4 debian image & GCC 4.7 cross compiler.
Add MIPS support to the coredump library. Explicit support for the MIPS
program counter register is added so that we can start backtracing from
the program counter value we read from a core dump. The PC register
support was not strictly required for local backtracing, and we will in
fact just plug the return address to the PC register in getcontext().
I have only tested the 32bit "OABI" paths.
In file included from src/ia64/Ginit_remote.c:26:0:
src/ia64/init.h: In function 'common_init':
src/ia64/init.h:32:12: warning: variable 'natp' set but not used [-Wunused-but-set-variable]
Instead of maintaining a pointer to the `sos_memory' array, maintain an
index that tells the next free position. When atomic operations are
available, the allocation boils down to a single fetch-and-add
operation.
To ensure that we return properly aligned pointers from sos_alloc(),
MAX_ALIGN must be a power-of-two. On i386 the power-of-two assumption
fails as sizeof(long double) = 12. Fix this by rounding up to 16.
Use the __BIGGEST_ALIGNMENT__ macro provided by GCC for sos_alloc()
allocation alignment. The macro gives ``the largest alignment ever used
for any data type on the target machine you are compiling for.''
__BIGGEST_ALIGNMENT__ also has some other nice properties, e.g. it is
power-of-two on all architectures (note that on i386, sizeof(long
double) = 12), and on some architectures (e.g. SuperH) the alignment
requirement can be lower than sizeof(long double).
tdep_get_func_addr in ppc64 passes NULL for the last argument of
as->access_mem. tdep_get_func_addr is called by elf_w(lookup_symbol),
which in turn is called by elf_w(get_proc_name_in_image).
elf_w(get_proc_name_in_image) is part of the API, and is only passed an
unw_addr_space_t, not a unw_cursor_t, meaning that we cannot recover the
UPT_info on the PPC64 platform.
This could be fixed by giving libunwind the knowledge to perform
relocations itself, thus not needing to look at the running image to
determine function addresses.
Disable the building of libunwind-coredump except on x86_64 and x86
(where implimentations exsist).
Allow overriding of this autodetection via --enable-coredump and
--disable-coredump.
Rename the `ALIGN' macro to `UNW_ALIGN', and move it from
`_UCD_internal.h' to `libunwind_i.h' so that we can share it with the
mempool code. `ALIGN' was clashing with system headers on FreeBSD:
In file included from src/coredump/_UCD_access_reg_freebsd.c:26:
src/coredump/_UCD_internal.h:102:1: warning: "ALIGN" redefined
In file included from /usr/include/sys/param.h:115,
from src/coredump/_UCD_lib.h:52,
from src/coredump/_UCD_access_reg_freebsd.c:24:
/usr/include/machine/param.h:79:1: warning: this is the location of the previous definition
Unwinding over ptrace and unwinding coredump fail to lookup the
.debug_frame dwarf data when the ELF file text segment virtual address
is non-zero. Looking at some binaries, the virtual address is non-zero
for non-pie binaries, and zero for PIC shared libraries and PIE
executables.
The core dump unwinder can be used for demonstrating the bug. Without
this patch, the unwinding fails badly (testing with a ARM qemu image):
$ UNW_ARM_UNWIND_METHOD=1 ./test-coredump-unwind core `cat backing_files`
test-coredump-unwind: unw_get_proc_info(ip=0x86d8) failed: ret=-10
After applying this patch, we can unwind all the way until running out
of dwarf data:
$ UNW_ARM_UNWIND_METHOD=1 ./test-coredump-unwind core `cat backing_files`
ip=0x000086d8 proc=000086d4-000086dc handler=0x00000000 lsda=0x00000000
test-coredump-unwind: step
test-coredump-unwind: step done:1
ip=0x000086ef proc=000086dc-000086f2 handler=0x00000000 lsda=0x00000000
test-coredump-unwind: step
test-coredump-unwind: step done:1
ip=0x000086e7 proc=000086dc-000086f2 handler=0x00000000 lsda=0x00000000
test-coredump-unwind: step
test-coredump-unwind: step done:1
ip=0x00008597 proc=00008584-0000859a handler=0x00000000 lsda=0x00000000
test-coredump-unwind: step
test-coredump-unwind: step done:1
ip=0x76eacc3b proc=76eacba0-76eaccec handler=0x00000000 lsda=0x00000000
test-coredump-unwind: step
test-coredump-unwind: step done:1
test-coredump-unwind: unw_get_proc_info(ip=0x85c3) failed: ret=-10
Note how the binary itself is mapped to address 0x8000, the virtual
address for the text segment is 0x8000, and the .debug_frame program
counter values are relative to 0:
$ tr ' ' '\n' < backing_files
0x8000:/home/user/tests/crasher
0x76e96000:/lib/arm-linux-gnueabi/libc-2.13.so
0x76f77000:/lib/arm-linux-gnueabi/libgcc_s.so.1
0x76f88000:/lib/arm-linux-gnueabi/ld-2.13.so
$ readelf -l crasher
Elf file type is EXEC (Executable file)
Entry point 0x859d
There are 9 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
EXIDX 0x0007b0 0x000087b0 0x000087b0 0x00030 0x00030 R 0x4
PHDR 0x000034 0x00008034 0x00008034 0x00120 0x00120 R E 0x4
INTERP 0x000154 0x00008154 0x00008154 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.3]
LOAD 0x000000 0x00008000 0x00008000 0x007e4 0x007e4 R E 0x8000
LOAD 0x000efc 0x00010efc 0x00010efc 0x00148 0x00154 RW 0x8000
DYNAMIC 0x000f08 0x00010f08 0x00010f08 0x000f8 0x000f8 RW 0x4
NOTE 0x000168 0x00008168 0x00008168 0x00044 0x00044 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4
GNU_RELRO 0x000efc 0x00010efc 0x00010efc 0x00104 0x00104 R 0x1
$ readelf --debug-dump=frames crasher | grep FDE
00000010 00000024 00000000 FDE cie=00000000 pc=00008614..000086d4
00000038 0000000c 00000000 FDE cie=00000000 pc=000086d4..000086dc
00000048 00000014 00000000 FDE cie=00000000 pc=000086dc..000086f2
00000060 00000014 00000000 FDE cie=00000000 pc=00008584..0000859a
After successfully stepping the cursor on ARM, the proc info is
invalidated only in dwarf_step(). Invalidate the proc info also when
stepping with the non-dwarf based methods. This fixes
unw_get_proc_info() returning stale data.
The core dump unwinder can be used for demonstrating the bug. When
unwinding based only on DWARF data, the proc info is correct:
$ UNW_ARM_UNWIND_METHOD=1 ./test-coredump-unwind core `cat backing_files` 2>/dev/null
ip=0x000086d8 proc=000086d4-000086dc handler=0x00000000 lsda=0x00000000
ip=0x000086ef proc=000086dc-000086f2 handler=0x00000000 lsda=0x00000000
ip=0x000086e7 proc=000086dc-000086f2 handler=0x00000000 lsda=0x00000000
ip=0x00008597 proc=00008584-0000859a handler=0x00000000 lsda=0x00000000
ip=0x76e3ac3b proc=76e3aba0-76e3acec handler=0x00000000 lsda=0x00000000
When unwinding based only on the exidx method, we see the proc info
lagging behind:
$ UNW_ARM_UNWIND_METHOD=4 ./test-coredump-unwind core `cat backing_files` 2>/dev/null
ip=0x000086d8 proc=000086d4-000086db handler=0x00000000 lsda=0x00000000
ip=0x000086ef proc=000086d4-000086db handler=0x00000000 lsda=0x00000000
ip=0x000086e7 proc=000086dc-000086f3 handler=0x00000000 lsda=0x00000000
ip=0x00008597 proc=000086dc-000086f3 handler=0x00000000 lsda=0x00000000
ip=0x76e3ac3b proc=00008584-0000859b handler=0x00000000 lsda=0x00000000
ip=0x000085c3 proc=76e3aba0-76e3ae4b handler=0x00000000 lsda=0x00000000
Finally, with this patch applied, we get the desired proc info also with
the exidx unwinder:
$ UNW_ARM_UNWIND_METHOD=4 ./test-coredump-unwind core `cat backing_files` 2>/dev/null
ip=0x000086d8 proc=000086d4-000086db handler=0x00000000 lsda=0x00000000
ip=0x000086ef proc=000086dc-000086f3 handler=0x00000000 lsda=0x00000000
ip=0x000086e7 proc=000086dc-000086f3 handler=0x00000000 lsda=0x00000000
ip=0x00008597 proc=00008584-0000859b handler=0x00000000 lsda=0x00000000
ip=0x76e3ac3b proc=76e3aba0-76e3ae4b handler=0x00000000 lsda=0x00000000
ip=0x000085c3 proc=0000859c-00008613 handler=0x00000000 lsda=0x00000000
Implement the Linux version of _UCD_access_reg() for ARM. We can
sidestep the register number remapping, as the libunwind register
numbers match one-to-one to the ELF core file register numbers.
Just pass potentially NULL pointers to free() in the error path in
load_debug_frame(). Saved 40 bytes of code in libunwind.so on ARM -O2
thumb build at the expense of slightly slower execution.
Stop pretending that unw_get_proc_info() works on PPC, and instead give
an error back to the caller. As far as I can tell, none of the libunwind
tests clear out the `unw_proc_info_t' before passing it to
unw_get_proc_info(), so they would end up working on garbage data.
ppc32/Gstep.c:116: warning: comparison between pointer and integer
ppc32/Gstep.c:116: warning: comparison with string literal results in unspecified behavior
ppc32/Gstep.c:116: warning: initialization makes integer from pointer without a cast
ppc32/Gstep.c:116: warning: passing argument 2 of 'fprintf' makes pointer from integer without a cast
/usr/powerpc-linux-gnu/include/stdio.h:333: note: expected 'const char *__restrict__' but argument is of type 'int'
Fix bitrot in HPPA common_init(). This has only been compile tested.
hppa/init.h: In function 'common_init':
hppa/init.h:33: error: 'struct cursor' has no member named 'ip_loc'
hppa/init.h:33: warning: implicit declaration of function 'HPPA_REG_LOC'
hppa/init.h:34: error: 'struct cursor' has no member named 'sp_loc'
hppa/init.h:36: warning: implicit declaration of function 'hppa_get'
hppa/init.h:36: error: 'struct cursor' has no member named 'ip_loc'
hppa/init.h:36: error: 'struct cursor' has no member named 'ip'
hppa/init.h:40: error: 'struct cursor' has no member named 'sp'
When cross-compiling libunwind with optimizations (-O1 or higher),
gcc-4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) optimizes away the memory
writes prior to the inline asm() statement in arm_local_resume() in the
non-signal-frame path, causing the `regs' array to be only allocated on
the stack, but not populated. This means that we are restoring garbage
to the registers.
As suggested in the GCC docs, add a fixed size input memory constraint
for the array content. This is enough to get the desired code to be
generated.
Adding __builtin_unreachable() to the point that we should never reach
was also in itself enough to inhibit the optimization. It also reduces
the function size by a few instructions.
Check the endianness earlier in unw_create_addr_space() on all
architectures to avoid leaking the dynamically allocated address space
struct.
This was already fixed for ARM in commit cf6a998796 ("Fix memory leak
in ARM unw_create_addr_space()"). Move the endianness check also on ARM
to avoid malloc() & free() in the error case.
