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

[Ivan Serdyuk via llvm-dev]

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/1d7fcb5a/attachment.html>