llvm dev - Jan 2018 - Call-stack and exception handling for Windows x64 JIT

Hi, I use LLVM MCJIT extensively and one of the sore spots is debugging. We
lose stack information if we crash during execution of one of our JIT
functions. I spent some time to understand Windows x64 stack/exception
handling and was able to hardcode support for a single JIT function and was
able to maintain the call stack correctly. However it requires knowledge of
the prolog of the function to code an UNWIND table used by the OS for stack
unwinding, so I'm not sure it's something I can enable generically as a
user of LLVM.

Has there been any progress to enable this support natively in LLVM? If
not, I'd be willing to spend some time to enable this functionality, with
help from experts in this area of LLVM.

Thanks,
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180102/3180b17d/attachment.html>

This is https://bugs.llvm.org/show_bug.cgi?id=24233. I don't think
there's
been any movement on it for a while. I don't *think* it should be hard, but
I've never really pushed on it.

On Tue, Jan 2, 2018 at 3:57 PM, Jason via llvm-dev <llvm-dev at
lists.llvm.org>
wrote:
> Hi, I use LLVM MCJIT extensively and one of the sore spots is debugging.
> We lose stack information if we crash during execution of one of our JIT
> functions. I spent some time to understand Windows x64 stack/exception
> handling and was able to hardcode support for a single JIT function and was
> able to maintain the call stack correctly. However it requires knowledge of
> the prolog of the function to code an UNWIND table used by the OS for stack
> unwinding, so I'm not sure it's something I can enable generically
as a
> user of LLVM.
>
> Has there been any progress to enable this support natively in LLVM? If
> not, I'd be willing to spend some time to enable this functionality,
with
> help from experts in this area of LLVM.
>
> Thanks,
> Jason
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://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/20180102/dfb623d5/attachment.html>

Thanks for the bug info. Using the information and patches there, I was
able to implement a solution that works for us. I can update the bug with
details of the fix. It is quite a happy sight to finally see a complete
call stack with our jitted functions in Visual Studio. We even have nested
jitted function calls, and they are displaying perfectly.
Thanks again,
Jason

On Tue, Jan 2, 2018 at 5:39 PM, Reid Kleckner <rnk at google.com> wrote:
> This is https://bugs.llvm.org/show_bug.cgi?id=24233. I don't think
> there's been any movement on it for a while. I don't *think* it
should be
> hard, but I've never really pushed on it.
>
> On Tue, Jan 2, 2018 at 3:57 PM, Jason via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi, I use LLVM MCJIT extensively and one of the sore spots is
debugging.
>> We lose stack information if we crash during execution of one of our
JIT
>> functions. I spent some time to understand Windows x64 stack/exception
>> handling and was able to hardcode support for a single JIT function and
was
>> able to maintain the call stack correctly. However it requires
knowledge of
>> the prolog of the function to code an UNWIND table used by the OS for
stack
>> unwinding, so I'm not sure it's something I can enable
generically as a
>> user of LLVM.
>>
>> Has there been any progress to enable this support natively in LLVM? If
>> not, I'd be willing to spend some time to enable this
functionality, with
>> help from experts in this area of LLVM.
>>
>> Thanks,
>> Jason
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://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/20180103/da89ab3e/attachment.html>