kristina added a comment. In https://reviews.llvm.org/D50564#1206393, @mstorsjo wrote:
> In https://reviews.llvm.org/D50564#1206370, @cdavis5x wrote: > > > In https://reviews.llvm.org/D50564#1206302, @kristina wrote: > > > > > I'm all for this change except the core issue is that you're using > > > libunwind as a shim around the actual unwinding API provided by Windows. > > > It would be nice to have something that did not have to do that and was > > > capable of performing unwinding of SEH-style exceptions without needing > > > additional runtime support. > > > > > > It would be nice, but that would require extra work. We'd have to implement > > reading and interpreting unwind codes, and calling any handlers present at > > each frame (which all have a different calling convention from Itanium > > handlers), and handling chained unwind info... Or we could use the > > implementation that MS provided to us for free--and which gets loaded into > > every process anyway by virtue of being in NTDLL, and which is extremely > > well tested. Given all that, I'm wondering what implementing all that > > ourselves would gain us. I suppose we could eventually do all that, but for > > now, I think this is outside the scope of my change. > > > +1. I guess such a library would be very nice to have, but from the point of > view of implementing exception handling, using the underlying APIs probably > is the way to go. The other question, as posted before, is whether we want to > wrap the whole CONTEXT structs in the UnwindCursor class and expose it via > the unw_* set of APIs. It gives quite a significant amount of extra code here > compared to libgcc's unwind-seh.c which is <500 loc altogether, providing > only the _Unwind_* API, implementing it directly with the Windows Rtl* APIs > from ntdll. That would give only a partial libunwind, with only the higher > level API available, but that's the only part used for exception handling at > least. That still makes the underlying assumption that SEH is exclusive to Windows (and by that virtue PE/COFF) which doesn't necessarily hold true. There is also the issue of generic names like `_LIBUNWIND_SUPPORT_SEH_UNWIND` to guard includes of Windows specific headers which ties into my previous point. Would it be possible to somehow abstract away the Windows runtime function call and Windows specific header includes, even if it's via CMake options. I'm raising this issue as there are other implementations of SEH that share the same (or extremely similar, depending on SDK versions) structures, but would not have the Windows headers available when compiling libunwind, and while the runtime function call to the `Rtl*` API is easy to change later on, separating rest of it from Windows headers is slightly messier. Would it, at very least, be possible to decouple most of it from a dependency on Windows headers? Would be much appreciated, as I'm going through a backlog of patches I'd like to put up for review one of which includes SEH for x86_64 Linux (ELF) implemented using RT signals and additional compiler runtime glue code, currently residing within compiler-rt builtins (one of the issues I want to address before). It's quite a wonky ABI since I tried to keep as much compatible with 64-bit Windows SEH (`.xdata` variation) in terms of frame lowering etc, but run-time mechanisms differ vastly for obvious reasons. Repository: rUNW libunwind https://reviews.llvm.org/D50564 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
