[LLVMdev] [RFC] New ToolsSupport library for stuff that only tools need

[Reid Kleckner]

On Thu, Nov 6, 2014 at 2:42 PM, Juergen Ributzka <juergen at apple.com> wrote:

> I would have preferred the library to be moved out of the “Support” folder
> and have its own top-level library and include folder.
>

+1, you will need to do this if you want to support the autoconf build
system.

----

Looking at the diff, I now remember why you want to do this. I seem to
recall you want to do this because the Mac-specific code in Support defines
raise(), __assert_rtn(), and abort(), and that's hostile to embedders like
WebKit. Makes sense, it's a gross hack, and I'd be in favor of fixing it if
possible. If it weren't for this hack, I would recommend that you just
avoid calling PrintStackTraceOnErrorSignal from WebKit.

Is there some way we can prevent this Mac-specific hack from affecting our
library organization? It's not clear to me that the distinction between
Support and ToolsSupport is really worth it.

Most LLVM tools are single threaded and don't need to redirect signals to
the current thread. I think it's only the crash recovery logic that needs
the signal to be delivered to the current thread. Maybe we should factor
out a CrashRecovery library, given that XCode via libclang is basically the
only client of this stuff? Does WebKit want to try to recover from JIT
assertion failures?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141106/97c28b86/attachment.html>