Hi Jan
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.
This has been implemented for Linux ELF binaries:
https://fedoraproject.org/wiki/Features/MiniDebugInfo
Yep, that was my inspiration for attempting to get something similar to
work for PE binaries.
But the symbols take less space there as they are compressed. You can check
how it looks like for Linux ELF binaries by:
rm -f /tmp/bash-debugdata{,.xz};objcopy --dump-section .gnu_debugdata=/tmp/bash-debugdata.xz /bin/bash /dev/null;xz -dv /tmp/bash-debugdata.xz;readelf -Wa /tmp/bash-debugdata|less
GDB should be able to extract .gnu_debugdata even from PE32 binaries but
I guess nobody has ever tested that.
I tired injecting the xz compressed symbols into the PE binary
analogously to how find-debuginfo.sh does it, but then windows told me
that the binary was invalid.
You are right that after the MiniDebugInfo feature has been approved for
Fedora (*) it should be ported from find-debuginfo.sh even into
mingw-find-debuginfo.sh. Therefore also in the compressed way, not just as
plain symbols you suggest.
If anyone with some knowledge in the area could help with that, I'd be
greatful!
Thanks
Sandro
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
