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 -- [email protected]
To unsubscribe send an email to [email protected]
