cdavis5x added a comment. In https://reviews.llvm.org/D50564#1207493, @kristina wrote:
> 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 and if possible use things like `void*` in place of > `PVOID` or anything that's `stdint.h/inttypes.h` friendly? It's an excellent > patch regardless but loosening the Windows SDK dependencies a bit would make > it a lot better. > > 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. > Having it interop with libunwind smoothly without rewriting much of existing > code in this patch would be nice, or even worse resorting to a million > preprocessor guards to cover all the cases. Very well, then. I'll see what I can do. 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
