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

[David Majnemer via llvm-dev]

On Sun, Jul 3, 2016 at 5:49 PM, Michael Lewis <don.apoch at gmail.com> wrote:

>
> On Sun, Jul 3, 2016 at 2:17 PM, Hayden Livingston <halivingston at gmail.com>
> wrote:
>
>> 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.
>>
>
>
> I'm not really interested in the JIT case as I said originally, so I can't
> answer that question.
>
>
>
>>
>> On Sun, Jul 3, 2016 at 2:48 AM, David Majnemer via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> > I can confirm that LLVM emits correct data when used in an AoT
>> configuration
>> > for x64, exception handling would be totally broken without it.
>> >
>>
>
>
> Two points of clarification:
>
>  - Are you talking about Win64 or just x64 in general (i.e. *nix/MacOS)?
>

I don't think many on the Unix side of things would refer to x86_64 as
x64.  Win64 is ambiguous because there have been other, non x64,
implementations of Windows (IA64, ARM64).  I am referring to the x64
implementation of Win64 :)


> Again given the presence of bugs going back to 2015 (including one linked
> in this thread)
>

The issue linked to, PR24233, has nothing to do with the static compiler
workflow.


> and other scant data from the list, I really can't tell what the expected
> state of this functionality is on Win64.
>

>  - Are you referring to data generated by LLVM that is embedded in COFF
> object files and then placed in the binary image by the linker?
>

LLVM's MC layer will give you an object file with code and associated
pdata/xdata.


> This data is at a minimum relocated by link.exe on Windows as near as I
> can tell. I do not want a dependency on link.exe. I can handle doing my own
> relocations prior to emitting the final image, but I want to know if
> there's a turnkey implementation of this already or if I have to roll my
> own here.
>

The code in RuntimeDyldCOFFX86_64 is responsible for making a pre-linked
object file loadable.


>
> Thanks,
>
>
>
>  - Mike
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160703/22ecb3cd/attachment.html>