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

Michael Lewis via llvm-dev llvm-dev at lists.llvm.org
Sat Jul 2 17:22:50 PDT 2016


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?



Thanks,



 - Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160702/2226f12c/attachment.html>


More information about the llvm-dev mailing list