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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200229/b6cdee7a/attachment.html>

+Lang Hames for JIT things
+Reid Kleckner <rnk at google.com> for Windows things

(in case they've got any thoughts on this issue - no guarantees though, I
didn't even know there was any option to use PDBs through MCJIT & I know
MCJIT is mostly unmaintained in favor of ORC JIT)

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/9bab93d2/attachment.html>

Thank you David for forwarding my question.
There is no official support for PDB with MCJIT, I developed one myself as
part of a project and with the help of Zachary Turner, I will soon make it
public on my github.
(If the community is interested for an official support of a JIT-PDB
feature, I can discuss with the persons in charge for helping with its
development).

Anyway, to give a little more information on my issue :
- adding "nounwind" attribute to jitted functions solved the problem
for
some functions but I still have issues on others (I still have to find
why.. and this is where I need help).
- it seems that the prolog register pushes "mess up" the stack walk
because
when breaking just at the beginning of the prolog or after epilog, I can
see the callling function correctly under the current one (RBP problem ?).
- when stepping inside a function, the mess in the callstack diplay
evolves, like if visual studio was trying to walk the stack based on
something not static (RSP ?)
- I don't understand how the walk could be complicated because frame
pointers are preserved in the assembly(RBP is pushed)... except if RBP is
used for something else but that would be weird.

Regards,
Vivien

Le sam. 29 févr. 2020 à 23:29, David Blaikie <dblaikie at gmail.com> a
écrit :
> +Lang Hames for JIT things
> +Reid Kleckner <rnk at google.com> for Windows things
>
> (in case they've got any thoughts on this issue - no guarantees though,
I
> didn't even know there was any option to use PDBs through MCJIT & I
know
> MCJIT is mostly unmaintained in favor of ORC JIT)
>
> 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/2e7633bf/attachment.html>

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>

I've always just hacked support for this in to the various JITs (for
JuliaLang, in our debuginfo.cpp file), by setting the
no-frame-pointer-optim flag in the IR, then creating and populating a dummy
unwind description object in the .text section, and registering that
dynamically. Some day I hope to actually just register the .pdata/.xdata
sections with the unwinder.

PDBs are a bit different though, since the above steps work well for gdb,
but generally I find that WinDbg is less willing or able to be given
JIT-frame information from LLVM. (I assume somehow it can be done, for
dotNET. I just don't know how.)

On Sat, Feb 29, 2020 at 11:07 PM Reid Kleckner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>>
> _______________________________________________
> 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/ab88b2c6/attachment.html>