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

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200815/448809e9/attachment.html>

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>

Ivan Serdyuk <local.tourist.kiev at gmail.com> writes:
>> 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.
Currently libbacktrace relies on _Unwind_Backtrace, which as you know
calls a callback function for each stack frame.  The current callback
functions call either_Unwind_GetIPInfo or _Unwind_GetIP, but that is a
detail.  If there is some alternative function that can be called on
Windows, I'm happy to have libbacktrace call that when _Unwind_Backtrace
is not available.  It's look like we might be able to use
RtlVirtualUnwind in a loop to do the job.

Of course, most of libbacktrace is parsing DWARF, so to be really
effective on Windows we would need to add some code to parse the Windows
debug format.

Ian

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>

On Sat, 15 Aug 2020, 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-rtlunwind
> 2
> https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlunwind
> ex
> https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlvirtua
> lunwind
> ?
Yes, those are the functions used for unwinding on windows.
>       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.
Just FWIW, I made a RFC patch that fixes building libunwind in MSVC mode 
(still requiring clang-cl though), at https://reviews.llvm.org/D86041 - 
mostly just to show what it takes - not convinced that it necessarily is 
something that should be done.

It does seem like _Unwind_Backtrace in libunwind doesn't work properly on 
x86_64 windows at the moment though, but on aarch64 it seems to do what 
one would expect.

// Martin

Martin,
good to hear from you.
Thanks for the effort - I will test on 32bit and 64bit Windows 10.
I will report ASAP.

Ivan

On Sun, Aug 16, 2020 at 8:42 PM Martin Storsjö <martin at martin.st>
wrote:
> On Sat, 15 Aug 2020, 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-rtlunwind
> > 2
> >
> https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlunwind
> > ex
> >
> https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlvirtua
> > lunwind
> > ?
>
> Yes, those are the functions used for unwinding on windows.
>
> >       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.
>
> Just FWIW, I made a RFC patch that fixes building libunwind in MSVC mode
> (still requiring clang-cl though), at https://reviews.llvm.org/D86041 -
> mostly just to show what it takes - not convinced that it necessarily is
> something that should be done.
>
> It does seem like _Unwind_Backtrace in libunwind doesn't work properly
on
> x86_64 windows at the moment though, but on aarch64 it seems to do what
> one would expect.
>
> // Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200816/9d31490c/attachment.html>