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

Chris Bieneman beanz at apple.com
Tue Nov 11 13:38:34 PST 2014


Here are updated patches for adding libToolsSupport.

I still haven’t done the Windows-side of the code, but I did modify the patches based on some earlier feedback.

Does this seem like a good approach?

-Chris

> On Nov 10, 2014, at 2:34 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
> On 10 November 2014 16:30, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote:
>> 
>> On Nov 10, 2014, at 1:01 PM, Chris Bieneman <beanz at apple.com> wrote:
>> 
>> I’ve been playing around with trying to accomplish my goal without a new
>> library and I think that while it isn’t impossible, it is nasty and not
>> ideal.
>> 
>> To recap, the goal I’m trying to accomplish is being able to build (from a
>> single configure) LLVM libraries that exclude crash handler support
>> (specifically the Darwin-specific abort and raise overrides), and LLVM tools
>> which include that functionality.
>> 
>> The simple naive solution to this would be to make those hooks implemented
>> in the headers, and conditionally compile it based on whether you’re
>> building for a tool or a library. Unfortunately this doesn’t really work in
>> this case. Header implemented functions need to be weak so that the linker
>> can properly resolve the duplicates. These symbols need to be strong so that
>> they override the versions present in the C library. That means that the
>> only way to do this in a header gets unwieldy because it would need to be a
>> header that is included once and only once in a tool, otherwise you’ll fail
>> linking.
>> 
>> This just comes back to the ideal solution for this (to me) being separating
>> out this functionality into a new library.
>> 
>> Thoughts anyone?
>> 
>> SGTM.  I’d prefer to avoid building bits I don’t need than relying on linker
>> stripping anyway, so a separate library is the only way to achieve that too.
> 
> +1, lib/Support is in the critical path of a lot of builds.
> 
> Cheers,
> Rafael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141111/731dfef4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libLLVMToolsSupport.diff
Type: application/octet-stream
Size: 41606 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141111/731dfef4/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141111/731dfef4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libLLVMToolsSupport-clang.diff
Type: application/octet-stream
Size: 5160 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141111/731dfef4/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141111/731dfef4/attachment-0002.html>


More information about the llvm-dev mailing list