Ivan Serdyuk via llvm-dev
2020-Aug-15 21:14 UTC
[llvm-dev] 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>
JonY via llvm-dev
2020-Aug-16 03:16 UTC
[llvm-dev] Supporting libunwind on Windows 10 (32bit; 64bit) for MSVC and Clang
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>
Ian Lance Taylor via llvm-dev
2020-Aug-16 03:26 UTC
[llvm-dev] Supporting libunwind on Windows 10 (32bit; 64bit) for MSVC and Clang
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
Ivan Serdyuk via llvm-dev
2020-Aug-16 10:15 UTC
[llvm-dev] Supporting libunwind on Windows 10 (32bit; 64bit) for MSVC and Clang
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>
Martin Storsjö via llvm-dev
2020-Aug-16 20:42 UTC
[llvm-dev] Supporting libunwind on Windows 10 (32bit; 64bit) for MSVC and Clang
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
Ivan Serdyuk via llvm-dev
2020-Aug-16 23:17 UTC
[llvm-dev] Supporting libunwind on Windows 10 (32bit; 64bit) for MSVC and Clang
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>