[llvm-dev] Status of stack walking in LLVM on Win64?

[David Majnemer via llvm-dev]

On Sat, Jul 2, 2016 at 5:22 PM, Michael Lewis via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi all,
>
> I'm developing a novel language that has historically used LLVM for code
> generation, behind a custom self-hosted front-end. The runtime for this
> language offers a garbage collector.
>
> In the past I've been on 32-bit Windows where precise garbage collection
> is relatively straightforward (as long as FPO is disabled). Walking the
> stack is a simple bit of pointer chasing and some fixups. I've had a
> working GC on Win32 for years and actually posted here in the past about my
> experience with .gcroot and other related miscellany involved in building a
> real GC with LLVM.
>
>
> Recently I've decided to begin moving the language to 64-bit native, and
> this has posed a few interesting challenges. The most pressing issue for me
> now is that stack walking is very different on Win64. It is not immediately
> clear to me if LLVM (3.8 or ToT) is in a position to enable reliable stack
> walks.
>
> Please note I'm using purely AoT compilation here with a custom
> linker/binary image emitter. I can sort of hack things up in JITted code
> using a manual process to populate data for RtlAddFunctionTable but I'm
> ultimately not interested in JIT code generation.
>
>
> I've managed to intercept data destined for the .pdata and .xdata COFF
> sections, but it seems to be garbage. All functions claim to begin at
> offset 0x0 and the UNWIND_INFO offsets are all 0-based instead of pointing
> into any relevant part of the image.
>
>
> Given a day or so I could provide a small example that generates this
> useless data, but before I go to that extent - am I just doing something
> dumb/forgetting a step/etc. when it comes to generating stack walk metadata
> on Win64? Does LLVM even emit correct data yet when doing AoT compilation?
>

I can confirm that LLVM emits correct data when used in an AoT
configuration for x64, exception handling would be totally broken without
it.


>
>
>
> Thanks,
>
>
>
>  - Mike
>
>
>
>
>
> _______________________________________________
> 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/20160703/e67b0e66/attachment.html>