llvm dev - Jul 2016 - Status of stack walking in LLVM on Win64?

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>

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>

For JITs it would appear that there is a patch needed for some kind of
relocations.

https://llvm.org/bugs/show_bug.cgi?id=24233

Is the patch really needed? What does it do? I'm not an expert here so
asking.

On Sun, Jul 3, 2016 at 2:48 AM, David Majnemer via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>
> 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
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>