Linking against libunwind helps on (at least) armel, but it seems to break on (at least) arm64.
The test suite reports the following when linked against libunwind on arm64: test-backtrace.c:14: Assert failed: strstr(str_c(bt), "test_backtrace") != NULL backtrace_append ..................................................... : FAILED test-backtrace.c:38: Assert failed: strstr(bt, "test_backtrace") != NULL backtrace_get ........................................................ : FAILED These are the failing lines: https://salsa.debian.org/debian/dovecot/-/blob/master/src/lib/test-backtrace.c#L14 https://salsa.debian.org/debian/dovecot/-/blob/master/src/lib/test-backtrace.c#L38 In both cases, the issue is that the given symbol name (test_backtrace) is not found in the string representing the stack trace. On armel, where the test passes, the stack trace appears complete and reasonably useful: #0 test_backtrace[0x0059efb8] -> #1 test_run_named_funcs[0x005d04b8] -> #2 test_run_named_with_fatals[0x005d12cc] -> #3 __libc_start_main[0xf78e4c44] -> #4 _start[0x0059d3bc] On arm64, it is: ./test-lib(+0x3f097) [0xaaaae0c5b097] -> ./test-lib(+0x3f1e7) [0xaaaae0c5b1e7] -> ./test-lib(+0x11f63) [0xaaaae0c2df63] -> ./test-lib(+0x3bacb) [0xaaaae0c57acb] -> ./test-lib(+0x3c77f) [0xaaaae0c5877f] -> /lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0xe3) [0xffff8ac962eb] -> ./test-lib(+0x106ab) [0xaaaae0c2c6ab] Note the lack of symbols. I have not investigated whether the problem is with dovecot's usage of libunwind or with libunwind itself. Also notable is the fact that the second conditional preprocessor block looks for the string "main" in the stack trace instead of test_backtrace, so it would pass here, even though the trace itself is of dubious value: https://salsa.debian.org/debian/dovecot/-/blob/master/src/lib/test-backtrace.c#L21
