https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot > Uni-Bielefeld.DE> --- >> --- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> --- > >> It's possible that all the lambda frames are inlined, or skip+2 in >> stacktrace.cc causes us to skip real frames that we should keep, or maybe >> libbacktrace just doesn't work on this target. [...] > The stacktrace failures only happen on 32-bit x86; 64-bit x86 is fine. > > I'm now trying a debug build and plan to compare i386 and amd64 side by > side to find differences. While that didn't produce anything useful, I noticed that both libbacktrace and its testcases are built with -funwind-tables. Checking what gcc does for that option, here's what I found: * 64-bit x86 defaults to -fasynchronous-unwind-tables, thus implicitly -funwind-tables, too. For that reason, the stacktrace tests PASS on both Linux/x86_64 and Solaris/amd64. * 32-bit x86 defaults to -fasynchronous-unwind-tables *if* -fomit-frame-pointer is enabled. This is the case on Linux/i686, thus the PASSes, while Solaris/i386 defaults to -fno-omit-frame-pointer, thus the FAILs observed. * Solaris never enables -funwind-tables by default, thus the FAILs on both Solaris/SPARC and Linux/SPARC. When I manually rebuild libstdc++-v3/src/libbacktrace with -g3 -O0 -funwind-tables and a testcase, too, it PASSes. The question is how to proceed, though: while one could enable -funwind-tables unconditionally in src/libbacktrace/Makefile.am (it's done this way in other runtimes libs) and add -funwind-tables to the affected testcases using dg-additional-options, I wonder if that produces a satisfying user experience in the end. Maybe it's better to just default to -funwind-tables in g++ instead?
