Need help with understanding truncated and corrupted backtraces

[Eli Zaretskii]

> Cc: gdb-patches@sourceware.org
> From: Simon Marchi <simon.marchi@polymtl.ca>
> Date: Mon, 29 Mar 2021 11:32:14 -0400
> 
> Ok, so given this backtrace:
> 
>     #0  Fskip_chars_backward (string=XIL(0x8000000006a71ad0), lim=XIL(0)) at syntax.c:1610
>     #1  0x09957f08 in ?? ()
>     #2  0x01260805 in Ffuncall (nargs=1, args=0x828880) at eval.c:3009
>     #3  0x099485bb in ?? ()
>     #4  0x00000000 in ?? ()
> 
> What I can see is that the following unwinders are used for each frame:
> 
>     #0 dwarf2
>     #1 i386 prologue
>     #2 dwarf2
>     #3 i386 prologue
>     #4 i386 prologue
> 
> So we can assume that going from frame 2 to 3 went well.  The code
> address in frame 3 makes sense, it is close to the address in frame 1,
> and I assume it's the jit-ed code.  It looks like going from frame 3 to
> frame 4 went wrong (the code address 0x00000000 is a sign of that).  The
> backtrace is stopped because when GDB encounters a frame with PC == 0,
> it stops:
> 
>     [frame] get_prev_frame: enter
>       [frame] frame_debug_got_null_frame: this_frame=4 -> zero PC
>     [frame] get_prev_frame: exit
> 
>     https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/frame.c;h=dc9fdd41646fbb52463ec8bbc73d670011ed6448;hb=HEAD#l2589
> 
> So, the JIT code produces code and a stack layout that GDB's prologue
> analyzer doesn't understand.  As mentioned previously, you have two
> options: looking into having dwarf info produced for the jit-ed code, or
> tweaking GDB's prologue analyzer to make it understand your code and
> stack.

FTR: this problem was caused by GDB's being unaware of some shared
libraries that were loaded by the inferior.  Emacs with
native-compilation feature compiles Lisp packages into shared
libraries using libgccjit, and then loads them at run time when they
are first needed.  The problem is that windows-nat.c uses an
unreliable technique to glean the DLL name from the information
provided by the debug event that announces the loading of the DLL.
Then the symbols from that DLL were not read, and in fact GDB was
completely unaware that the DLL was at all loaded.  For some reason,
this problem only happened for some DLLs, but not for others.

The patch I presented in

  https://sourceware.org/pipermail/gdb-patches/2021-April/177513.html

fixes the problem with recording the DLLs loaded at run time, and that
completely eliminated the problems with backtraces.

Thanks.