No backtrace with Mingw64

[ambitslix]

No backtrace is generated when built with mingw64 under msys2(Windows 10) or MXE(Ubuntu). Several library tests fail. Only tested 64 bit static mingw GCC.

btest fails:

$ ./btest.exe
FAIL: backtrace_full noinline
FAIL: backtrace_full inline
FAIL: backtrace_simple noinline
FAIL: backtrace_simple inline
test1: [0]: missing file name or function name
test2: [0]: missing file name or function name
test3: [0]: missing file name or function name
test3: [0]: NULL syminfo name
test3: [1]: NULL syminfo name
test3: [2]: NULL syminfo name
test4: [0]: missing file name or function name

[matanui159]

_Unwind_GetIPInfo is returning 0 with ip_before_insn set to false (backtrace.c). Maybe an issue with MinGW?

[ambitslix]

Yes I confirm that but I have gcc 8.3.0 on msys2 and 5.5.0 with MXE and I think it's unlikely they would have the same problem.

[mati865]

Appears to be issue with libgcc.
Building in MSYS2:

• clang -rtlib=gcc:

$ ./btest.exe
FAIL: backtrace_full noinline
FAIL: backtrace_full inline
FAIL: backtrace_simple noinline
FAIL: backtrace_simple inline
test1: [0]: missing file name or function name
test2: [0]: missing file name or function name
test3: [0]: missing file name or function name
test3: [0]: NULL syminfo name
test3: [1]: NULL syminfo name
test3: [2]: NULL syminfo name
test4: [0]: missing file name or function name

• clang -rtlib=compiler-rt:

$ ./btest.exe

[krlmlr]

Confirmed, using GCC:

$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\rtools40\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/rtools40/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-8.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,fortran --disable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Built by Jeroen for the R-project' --with-bugurl=https://github.com/r-windows --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 8.3.0 (Built by Jeroen for the R-project)

[krlmlr]

This appears to be an omission in GCC when providing an SEH-based backtrace. The problem does not occur with SJLJ.

I'm using the rtools40 toolchain which is based on msys2 and provides both mingw32 and mingw64. With the built-in gcc version 8.3.0, I'm observing the behavior of failing btest.exe and edtest.exe on mingw64 (which uses SEH), but not on mingw32 (which uses SJLJ).

The following is needed to fix:

• apply gcc-mirror/gcc#48 to the gcc source
• build and install gcc
• do a clean rebuild of libbacktrace

The GCC patch does two things:

• ignores the first entry
• sets the cfa and ra members in a way similar to _GCC_specific_handler

We can get somewhat acceptable results (but not successful tests) by querying _Unwind_GetRegionStart() if _Unwind_GetIPInfo() returns 0 or -1. Happy to submit a patch.

What's the best way to move forward?

[ianlancetaylor]

Based on your description, this is a GCC bug. So it sounds like the next step is to file a bug report against GCC (at https://gcc.gnu.org/bugzilla). It should be possible to create a test case that doesn't involve libbacktrace.

[krlmlr]

Done: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96948.

[ianlancetaylor]

Thanks. Closing this issue as there is nothing to change in libbacktrace.