[llvm-dev] Supporting libunwind on Windows 10 (32bit; 64bit) for MSVC and Clang

[JonY via llvm-dev]

On 8/15/20 9:14 PM, Ivan Serdyuk wrote:
> On Sat, Aug 15, 2020 at 8:39 PM Martin Storsjö <martin at martin.st> wrote:
> 
>> Hi,
>>
>>
>> On Sat, 15 Aug 2020, Ivan Serdyuk wrote:
>>
>>>       Just as Shoaib said, libunwind only is useful in environments
>>>       that use
>>>       the Itanium C++ ABI - there's really no use for it in an MSVC
>>>       context
>>>       (either using MSVC or clang-cl to compile it).
>>>
>>>       The particular linker error comes from the fact that there's
>>>       functions
>>>       implemented in assembly, that expect the function name to be
>>>       mangled the
>>>       itanium way, while the object files built by the compiler expect
>>>       the
>>>       symbols to use the MSVC C++ name mangling, so there's an
>>>       undefined
>>>       reference.
>>>
>>>
>>> I see, thanks.
>>>
>>> Which options exist for MSVC, in sense an alternative to libunwind and
>>> libbacktrace ?
>>
>> Well for libunwind, there's really no use for it in an MSVC setting. All
>> the unwinding functionality is already built into the operating system,
>> available via the Rtl*Unwind* functions.
>>
> 
> Martin,
> you mean these functions
> https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlunwind
> https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlunwind2
> https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlunwindex
> https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlvirtualunwind
> ?
> 
>>
>> For libbacktrace, I guess the _Unwind_Backtrace function in libunwind
>> might work and be useful, even if the rest of libunwind doesn't make sense
>> in such a context.
> 
> 
> Ian,
> please share your vision/propose some plan.
> 
> 
>> I haven't tested this function on windows though, and
>> it'd require you to fix the linker error one way or another.
>>
> 
> I see.
> 
>>
>> Another alternative, requiring much less code, would be to just extract
>> the SEH version of _Unwind_Backtrace function from libgcc [1]. I think
>> that function is fairly independent from the rest of libgcc and from the
>> rest of the surrounding file, and only calls Windows system APIs.
>>
> 
> Well, adding committers to the discussion.
> Richard, Tristan, Bernd, Jon - please verify/elaborate.
> 
> Thanks in advance.
> Ivan
> 
>>
>> // Martin
>>
>> [1] https://github.com/gcc-mirror/gcc/blob/master/libgcc/unwind-seh.c#L434
>>
>>
>>
> 

+ Kai Tietz. I have not touched on libgcc unwinders, I believe Kai would
be a better help.

SEH was only implemented for x86_64 Windows in GCC, Kai described the
32bit implementation was very different. The 32bit SEH was under Borland
patent at the time, but it has since expired.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200816/5482c313/attachment.sig>