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.
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