labath added a comment. In D119009#3302354 <https://reviews.llvm.org/D119009#3302354>, @JDevlieghere wrote:
> I believe it's generally considered bad practice to install signal handlers > in a library. This is why the initialization currently happens in the driver. > If you look at other tools in LLVM you'll notice they do the same thing. > > Can we address this issue by (1) making sure we don't crash in lldbassert > when calling `PrintStackTrace` without having initialized the signal handlers > and (2) providing the ability to install the signal handlers through the SB > API (if that doesn't already exist) if the user of libLLDB wants this > functionality? I think that's a very good approach to the problem. That said, I want to add that, as far as I can tell, the windows-specific initialization is not actually an issue here. Loading a dll does not have the same global impact as installing a signal handler (if the dll is well-behaved, anyway). So, I can imagine a setup (though I don't know how it would work in detail) where where we initialize the windows-specific parts of this from within lldb, but avoid the parts which installs handlers on other platforms. I guess it might be interesting to know how is this situation handled for other out-of-tree users of llvm libraries on windows (assuming we have any). Do they get this to work somehow, or is lldb the first one to want to print a backtrace in a non-fatal situation (the non-fatal lldbasserts are definitely... unique). (I am assuming people won't notice the difference between a crash because the app hit a real assertion failure, or because it failed to print the backtrace of that failure, if they don't know that they should expect to see that backtrace.) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D119009/new/ https://reviews.llvm.org/D119009 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
