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

[Ivan Serdyuk via llvm-dev]

https://reviews.llvm.org/D50564 - this seems to be related, but for the
targeted architecture.
But this is somewhat an aside reference, just to get some general
understanding.

Ivan


On Sun, Aug 16, 2020 at 10:15 AM Ivan Serdyuk <local.tourist.kiev at gmail.com>
wrote:

> Ian, Jon - thanks for your suggestions.
> Kai, please share your vision/opinion.
>
> Ivan
>
> On Sun, Aug 16, 2020 at 3:16 AM JonY <10walls at gmail.com> wrote:
>
>> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200816/69c438a9/attachment.html>