Crashes related to enabling precise unwind tables have been observed
in the implementation of the arm* unwinder upon receipt of SIGCANCEL,
triggered by a call to pthread_cancel(). Typically, the latmus program
might randomly crash or enter a runaway loop at exit on cancelling the
timer responder thread for no obvious reason, including anything
related to stack sanity (size or corruption).
This switch was originally turned on to help backtrace() in collecting
more accurate information when called from a SIGDEBUG
handler. Unfortunately, support for stack unwinding is tricky in
essence, and may be broken in specific toolchain releases, causing
segmentation violation on exit, e.g.:
With libevl built using
gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf:
warming up on CPU0 (not isolated)...
RTT| 00:00:01 (user, 1000 us period, priority 90, CPU0-noisol)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 6.333| 6.874| 13.000| 0| 0| 6.333| 13.000
RTD| 6.333| 6.904| 19.666| 0| 0| 6.333| 19.666
^C
---|-----------|-----------|-----------|--------|------|-------------------------
RTS| 6.333| 6.889| 19.666| 0| 0| 00:00:02/00:00:02
Segmentation fault (core dumped)
(gdb) bt
regclass=regclass@entry=_UVRSC_CORE,
discriminator=discriminator@entry=16624,
representation=representation@entry=_UVRSD_UINT32)
at /home/tcwg-buildslave/workspace/tcwg-make-release_1/snapshots/gcc.git~linaro-7.5-2019.12/libgcc/config/arm/unwind-arm.c:240
uws=uws@entry=0xb6e35e64)
at /home/tcwg-buildslave/workspace/tcwg-make-release_1/snapshots/gcc.git~linaro-7.5-2019.12/libgcc/config/arm/pr-support.c:179
ucbp=0xb6e372a8, context=0xb6e36080, id=0)
at /home/tcwg-buildslave/workspace/tcwg-make-release_1/snapshots/gcc.git~linaro-7.5-2019.12/libgcc/unwind-arm-common.inc:842
entry_vrs=<optimized out>, resuming=0)
at /home/tcwg-buildslave/workspace/tcwg-make-release_1/snapshots/gcc.git~linaro-7.5-2019.12/libgcc/unwind-arm-common.inc:349
at /home/tcwg-buildslave/workspace/tcwg-make-release_1/snapshots/gcc.git~linaro-7.5-2019.12/libgcc/config/arm/libunwind.S:359
---Type <return> to continue, or q <return> to quit---
ctx=<optimized out>) at nptl-init.c:216
from /lib/libc.so.6
Which in this particular case pointed at:
(gdb) x/20i $pc
=> 0xb6f4ca2c <_Unwind_VRS_Pop+244>: ldr r1, [r4, #0]
0xb6f4ca2e <_Unwind_VRS_Pop+246>: adds r4, #4
0xb6f4ca30 <_Unwind_VRS_Pop+248>: str.w r1, [r0, #-4]
0xb6f4ca34 <_Unwind_VRS_Pop+252>: cmp r3, #16
0xb6f4ca36 <_Unwind_VRS_Pop+254>:
(gdb) info reg
r0 0xb6e36098 3068354712
r1 0x10 16
r2 0x40f0 16624
r3 0x5 5
r4 0xf009e 983198
r5 0xb6e36080 3068354688
r6 0x1 1
r7 0x40f0 16624
r8 0x0 0
r9 0xb6e35e24 3068354084
r10 0x0 0
r11 0x1 1
r12 0xb6f5e0ac 3069567148
sp 0xb6e35cf0 0xb6e35cf0
lr 0xb6f4cf23 -1225470173
pc 0xb6f4ca2c 0xb6f4ca2c <_Unwind_VRS_Pop+244>
cpsr 0x40d1c30 67968048
Something definitely bad happened in the unwinder. Disable this option
by default, which works around the toolchain issue for the most common
use case.
Script helpers to the evl command are installed in $prefix/libexec. By
convention, source scripts are suffixed by ".evl" to identify them
unambiguously. They are copied to $libexec/evl-<script>.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
Philippe Gerum