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

I was thinking of moving the files into a Tools subdirectory of Support, and
having a new library generated from that. Does that mesh with what you’d like to
see?

I’ve gotten wrapped into a nasty internal bug hunt, so I probably won’t have
patches until next week. I will also probably need to ask Eric for help with the
autoconf side of things because my familiarity with autoconf ends at “run
configure”.

-Chris
> On Oct 31, 2014, at 1:46 PM, Reid Kleckner <rnk at google.com> wrote:
> 
> I'm in favor of splitting the code out into a new directory and using
separate libraries if we're going to do this.
> 
> Build systems should be really dumb, IMO.
> 
> On Thu, Oct 30, 2014 at 6:46 PM, Eric Christopher <echristo at gmail.com
<mailto:echristo at gmail.com>> wrote:
> +1 to this.
> 
> I'd slightly prefer a separate library (though moving the code vs not
moving the code I'm relatively apathetic about), but just because I hate
conditional compilation.
> 
> -eric
> 
> On Thu Oct 30 2014 at 5:55:59 PM Juergen Ributzka <juergen at apple.com
<mailto:juergen at apple.com>> wrote:
> I am mostly impartial to the two proposed solutions (separate library or
conditional compilation of the hooks into the tools). If we make it a library I
think we should make it a convenience library that is intended to be used only
with the tools and not an external supported library at all.
> 
> -Juergen
> 
>> On Oct 20, 2014, at 1:02 PM, Chris Bieneman <beanz at apple.com
<mailto:beanz at apple.com>> wrote:
>> 
>> 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 <mailto: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>
>>> 
>> 
>> _______________________________________________
>> 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>
> 
> _______________________________________________
> 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>
> 
> _______________________________________________
> 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/20141031/d934748d/attachment.html>

So, I decided to try and start small. My idea here was create a ToolsSupport
library, and move one small, but important function into the new library to
shake out all the places that would need updating. The function I chose to start
with was llvm::sys::PrintStackTraceOnErrorSignal.

Turns out this wasn’t so small. These patches aren’t done yet, but since they’re
pretty big I thought I’d send them out for preliminary feedback about whether or
not this is the right approach. The patches contain the following changes:

* Patches to LLVM & Clang CMake build systems to add a new
libLLVMToolsSupport
* New SignalHandlers.h/.cpp/.inc files for PrintStackTraceOnErrorSignal
* Updated all llvm tools to pull in the new library and use the new header

Still missing:

* Windows side of the SignalHandlers patches
* Autoconf/Make side of the build system patches
* Patches for other LLVM projects
* General cleanup

Feedback is greatly appreciated. I’d really like to make sure I’m not lost in
the weeds on this one.

Thanks,
-Chris



> On Oct 31, 2014, at 2:07 PM, Chris Bieneman <beanz at apple.com>
wrote:
> 
> I was thinking of moving the files into a Tools subdirectory of Support,
and having a new library generated from that. Does that mesh with what you’d
like to see?
> 
> I’ve gotten wrapped into a nasty internal bug hunt, so I probably won’t
have patches until next week. I will also probably need to ask Eric for help
with the autoconf side of things because my familiarity with autoconf ends at
“run configure”.
> 
> -Chris
> 
>> On Oct 31, 2014, at 1:46 PM, Reid Kleckner <rnk at google.com
<mailto:rnk at google.com>> wrote:
>> 
>> I'm in favor of splitting the code out into a new directory and
using separate libraries if we're going to do this.
>> 
>> Build systems should be really dumb, IMO.
>> 
>> On Thu, Oct 30, 2014 at 6:46 PM, Eric Christopher <echristo at
gmail.com <mailto:echristo at gmail.com>> wrote:
>> +1 to this.
>> 
>> I'd slightly prefer a separate library (though moving the code vs
not moving the code I'm relatively apathetic about), but just because I hate
conditional compilation.
>> 
>> -eric
>> 
>> On Thu Oct 30 2014 at 5:55:59 PM Juergen Ributzka <juergen at
apple.com <mailto:juergen at apple.com>> wrote:
>> I am mostly impartial to the two proposed solutions (separate library
or conditional compilation of the hooks into the tools). If we make it a library
I think we should make it a convenience library that is intended to be used only
with the tools and not an external supported library at all.
>> 
>> -Juergen
>> 
>>> On Oct 20, 2014, at 1:02 PM, Chris Bieneman <beanz at apple.com
<mailto:beanz at apple.com>> wrote:
>>> 
>>> 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 <mailto: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>
>>>> 
>>> 
>>> _______________________________________________
>>> 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>
>> 
>> _______________________________________________
>> 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>
>> 
>> _______________________________________________
>> 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>
>> 
>> 
> 
> _______________________________________________
> 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/20141106/1fca9e35/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libLLVMToolsSupport.diff
Type: application/octet-stream
Size: 38704 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141106/1fca9e35/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141106/1fca9e35/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libLLVMToolsSupport-clang.diff
Type: application/octet-stream
Size: 5167 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141106/1fca9e35/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141106/1fca9e35/attachment-0002.html>

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

Just my 2 cents.
> On Nov 6, 2014, at 2:12 PM, Chris Bieneman <beanz at apple.com>
wrote:
> 
> So, I decided to try and start small. My idea here was create a
ToolsSupport library, and move one small, but important function into the new
library to shake out all the places that would need updating. The function I
chose to start with was llvm::sys::PrintStackTraceOnErrorSignal.
> 
> Turns out this wasn’t so small. These patches aren’t done yet, but since
they’re pretty big I thought I’d send them out for preliminary feedback about
whether or not this is the right approach. The patches contain the following
changes:
> 
> * Patches to LLVM & Clang CMake build systems to add a new
libLLVMToolsSupport
> * New SignalHandlers.h/.cpp/.inc files for PrintStackTraceOnErrorSignal
> * Updated all llvm tools to pull in the new library and use the new header
> 
> Still missing:
> 
> * Windows side of the SignalHandlers patches
> * Autoconf/Make side of the build system patches
> * Patches for other LLVM projects
> * General cleanup
> 
> Feedback is greatly appreciated. I’d really like to make sure I’m not lost
in the weeds on this one.
> 
> Thanks,
> -Chris
> 
> <libLLVMToolsSupport.diff>
> <libLLVMToolsSupport-clang.diff>
> 
> 
> 
>> On Oct 31, 2014, at 2:07 PM, Chris Bieneman <beanz at apple.com
<mailto:beanz at apple.com>> wrote:
>> 
>> I was thinking of moving the files into a Tools subdirectory of
Support, and having a new library generated from that. Does that mesh with what
you’d like to see?
>> 
>> I’ve gotten wrapped into a nasty internal bug hunt, so I probably won’t
have patches until next week. I will also probably need to ask Eric for help
with the autoconf side of things because my familiarity with autoconf ends at
“run configure”.
>> 
>> -Chris
>> 
>>> On Oct 31, 2014, at 1:46 PM, Reid Kleckner <rnk at google.com
<mailto:rnk at google.com>> wrote:
>>> 
>>> I'm in favor of splitting the code out into a new directory and
using separate libraries if we're going to do this.
>>> 
>>> Build systems should be really dumb, IMO.
>>> 
>>> On Thu, Oct 30, 2014 at 6:46 PM, Eric Christopher <echristo at
gmail.com <mailto:echristo at gmail.com>> wrote:
>>> +1 to this.
>>> 
>>> I'd slightly prefer a separate library (though moving the code
vs not moving the code I'm relatively apathetic about), but just because I
hate conditional compilation.
>>> 
>>> -eric
>>> 
>>> On Thu Oct 30 2014 at 5:55:59 PM Juergen Ributzka <juergen at
apple.com <mailto:juergen at apple.com>> wrote:
>>> I am mostly impartial to the two proposed solutions (separate
library or conditional compilation of the hooks into the tools). If we make it a
library I think we should make it a convenience library that is intended to be
used only with the tools and not an external supported library at all.
>>> 
>>> -Juergen
>>> 
>>>> On Oct 20, 2014, at 1:02 PM, Chris Bieneman <beanz at
apple.com <mailto:beanz at apple.com>> wrote:
>>>> 
>>>> 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 <mailto: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>
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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>
>>> 
>>> _______________________________________________
>>> 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>
>>> 
>>> _______________________________________________
>>> 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>
>>> 
>>> 
>> 
>> _______________________________________________
>> 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/20141106/84a29968/attachment.html>