On Thu, 24 Aug 2017 14:31:11 +0200, Sandro Mani wrote: > On 24.08.2017 14:18, Jan Kratochvil wrote: > > On Thu, 24 Aug 2017 13:43:32 +0200, Sandro Mani wrote: > > > I'm investigating why gdb returns so unreliable backtraces for mingw > > > binaries without debuginfos, > > They are perfectly reliable. They just do not show the function names. > > But those can be looked up later from *-debuginfo.rpm. > I regularly have the issue that with larger programs, gdb aborts with > "Backtrace stopped: previous frame inner to this frame (corrupt stack?) " if > the crash happens somewhere deep down, say in some Qt library, and never > gets to printing the frames of the caller of the application code I'm > interested in. If debugsymbols are available, it prints the all the frames. > Hence "unreliable". I supose this might be a bug, but I have no idea how to > investigate. In your OP example: : #0 0x000000000040157d in ?? () : #1 0x00000000004015b5 in ?? () : #2 0x00000000004013f7 in ?? () : #3 0x000000000040152b in ?? () : #4 0x0000000076af652d in KERNEL32!BaseThreadInitThunk () : from C:\Windows\system32\kernel32.dll : #5 0x0000000076d2c521 in ntdll!RtlUserThreadStart () : from C:\Windows\SYSTEM32\ntdll.dll : #6 0x0000000000000000 in ?? () : Backtrace stopped: previous frame inner to this frame (corrupt stack?) : : With strip-debug, gdb reports: : : #0 0x000000000040157d in foo() () : #1 0x00000000004015b5 in main () You can see the backtrace is the same. I guess you will see that Backtrace stopped: previous frame inner to this frame (corrupt stack?) even with installed *-debuginfo.rpm after you enter: (gdb) set backtrace past-main on (gdb) set backtrace past-entry on The symbols (particularly the "main" symbol) just tell GDB to stop backtracing earlier. But the part that it already backtraced is the same. In some cases *-debuginfo.rpm can really improve the backtrace (even the numerical-only one, ignoring the address->functionname decoration). This is due to .debug_frame sections there when the main binary is missing corresponding .eh_frame. But I have no idea how this works in PE32 and then it is a packaging bug (missing -fasynchronous-unwind-tables) as the numerical-only backtraces should be the same with and without debuginfo. Last difference can be due to inlined functions being shown just with *-debuginfo.rpm but that is not much important (and reconstructable from the numerical-only backtrace). But these *-debuginfo.rpm differences will not happen with your planned bare functionname symbols (called ELF symbols or PE32 symbols in your case). Jan _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
