llvm dev - Oct 2014 - [LLVMdev] [RFC] New ToolsSupport library for stuff that only tools need

There are some pieces of functionality in LLVM today, that make sense for tools
like llc, opt, clang, but they aren't relevant for embedded uses like LLVM
in the JavaScript JIT. One example of this type of functionality is the signal
handlers.

I'd like to propose migrating content that is specifically designed for
tools into a new ToolsSupport library. My initial candidates for the new library
would be; anything guarded by ENABLE_CRASH_OVERRIDES, and any functionality
specific to tools (i.e. ToolOutputFile and eventually command line parsing— once
it can be factored out).

The primary goal of this is to make it easy for uses of LLVM that aren't
command line tools to not include functionality that isn't required for that
use case.

Thoughts?

-Chris

The question I have is -- does the actual source code need to move? I'm
wondering what aspects require a new library as opposed to different
sequence of things happening when initializing LLVM as a library vs. as a
tool.

(We've definitely had trouble with the signal handlers ourselves, but I
thought we had solved it by using different code paths to set everything
else up...)

On Mon, Oct 20, 2014 at 12:46 PM, Chris Bieneman <beanz at apple.com>
wrote:
> There are some pieces of functionality in LLVM today, that make sense for
> tools like llc, opt, clang, but they aren't relevant for embedded uses
like
> LLVM in the JavaScript JIT. One example of this type of functionality is
> the signal handlers.
>
> I'd like to propose migrating content that is specifically designed for
> tools into a new ToolsSupport library. My initial candidates for the new
> library would be; anything guarded by ENABLE_CRASH_OVERRIDES, and any
> functionality specific to tools (i.e. ToolOutputFile and eventually command
> line parsing— once it can be factored out).
>
> The primary goal of this is to make it easy for uses of LLVM that
aren't
> command line tools to not include functionality that isn't required for
> that use case.
>
> Thoughts?
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141020/703bc5bd/attachment.html>

There is no real technical requirement for this. Currently we work around the
signal handlers by building with ENABLE_CRASH_OVERRIDES=NO, and carrying along
the command line parsing code and ToolOutputFile isn’t really a big drain.

This seemed to me like the cleanest way to accomplish a goal of mine. The goal I
have is to be able to build an LLVM dylib and llc/opt/etc from the same CMake
invocation where the dylib does not have crash overrides and signal handler
hooks, but the tools do.

There are other ways to accomplish this, but I felt that separating
libLLVMSupport into two libraries seemed the cleanest. An alternate approach
that could work for me would be to have the implementation of the hooks only be
compiled into the tools.

-Chris
> On Oct 20, 2014, at 12:57 PM, Chandler Carruth <chandlerc at
google.com> wrote:
> 
> The question I have is -- does the actual source code need to move? I'm
wondering what aspects require a new library as opposed to different sequence of
things happening when initializing LLVM as a library vs. as a tool.
> 
> (We've definitely had trouble with the signal handlers ourselves, but I
thought we had solved it by using different code paths to set everything else
up...)
> 
> On Mon, Oct 20, 2014 at 12:46 PM, Chris Bieneman <beanz at apple.com
<mailto:beanz at apple.com>> wrote:
> There are some pieces of functionality in LLVM today, that make sense for
tools like llc, opt, clang, but they aren't relevant for embedded uses like
LLVM in the JavaScript JIT. One example of this type of functionality is the
signal handlers.
> 
> I'd like to propose migrating content that is specifically designed for
tools into a new ToolsSupport library. My initial candidates for the new library
would be; anything guarded by ENABLE_CRASH_OVERRIDES, and any functionality
specific to tools (i.e. ToolOutputFile and eventually command line parsing— once
it can be factored out).
> 
> The primary goal of this is to make it easy for uses of LLVM that
aren't command line tools to not include functionality that isn't
required for that use case.
> 
> Thoughts?
> 
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141020/fd826818/attachment.html>