[llvm-dev] [MCJIT] messy call stack debug on x64 code in VisualStudio

[Reid Kleckner via llvm-dev]

Yes, I think https://bugs.llvm.org/show_bug.cgi?id=24233 needs to be
implemented to fix this.

The Windows x64 unwinder doesn't generally look at frame pointers. We would
need to register unwind info to make this work. What you see is fairly
typical of attempting to unwind the stack when unwind info is missing.

PDBs shouldn't generally enter into the picture.

On Sat, Feb 29, 2020 at 8:14 AM Vivien Millet via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
>
> I'm using IR and MCJIT to compile a script language. I debug it with on
> the fly generated .pdb files. During debugging, almost each time I step
> into a function, I loose information about calling function inside the
> visual studio callstack view or I have a bunch of pure addresses in the
> callstack in between the current function and the calling function, for
> example :
>
> MyJit.dll!MyCurrentFunction()
> [0x1234567887654321]
> [0x8765432112345678]
> MyJit.dll!MyCallingFunction()
> ...
>
> It looks like visual studio get lost while walking up stack.
> Does anyone know where it could come from ?
>
> I have disabled all optimisations (among them is the omit-frame-pointer).
>
> I have seen this bug here : https://bugs.llvm.org/show_bug.cgi?id=24233 which
> is quite similar but it is quite old now, and since the proposed patch has
> been posted, the code in RuntimeDyldCOFFX86_64.h has changed and it is
> difficult for me to know if it has really been fixed since or not.
>
> Could it be related to the way IR CreateAlloca are used to build local
> variables ? Could it be related to missing informations inside the PDB ? (I
> don't know if there is stack related information inside PDB files to ensure
> good stack walking).
>
> Thanks.
>
> Vivien
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200229/cd770a8b/attachment.html>