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

Pete Cooper
Mon, 10 Nov 2014 21:30:28 -0000

> 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.

Pete
> -Chris
>
>> On Nov 7, 2014, at 1:22 PM, Chris Bieneman <beanz at apple.com
<mailto:beanz at apple.com>> wrote:
>>
>> To further this point, it was recently brought to my attention that the
CMake libLLVM.so on Linux is empty because the GNU linker on linux doesn’t treat
symbols mentioned in an export list as being used, so the linker dead strips it
all.
>>
>> -Chris
>>
>>> On Nov 7, 2014, at 12:28 PM, Jim Grosbach <grosbach at apple.com
<mailto:grosbach at apple.com>> wrote:
>>>
>>>>
>>>> On Nov 7, 2014, at 11:05 AM, Chandler Carruth <chandlerc at
google.com <mailto:chandlerc at google.com>> wrote:
>>>>
>>>>
>>>> On Fri, Nov 7, 2014 at 12:20 PM, Owen Anderson <resistor at
mac.com <mailto:resistor at mac.com>> wrote:
>>>>> On Nov 7, 2014, at 8:57 AM, Daniel Dunbar <daniel at
zuster.org <mailto:daniel at zuster.org>> wrote:
>>>>>
>>>>> 2. I agree with Chandler in that I don't see a good
need to try hard to factor out code from the Support library that can just be
conditional disabled or would be unused by normal .a link semantics. For
example, whether or not the regex or YAML code belongs in Support doesn't
seem worth worrying too much about, because they are very isolated, don't
introduce extra dependencies, and won't be linked by projects that don't
use them.
>>>>
>>>> This assumes that the client is statically linking against
Support.  Chris has been pretty explicit about his goals of building and using
LLVM as a monolithic dynamic library, in which case things like regex or YAML
support will *not* be automatically removed.
>>>>
>>>> I see...
>>>>
>>>> Maybe what we really need is (lacking a complete export list
for the monolithic dynamic library) to use visibility so that these kinds of
things can be dropped from the final dynamic library if they aren't used
within it? I suspect would could mark essentially all of the support library, as
unless it is used in the interface of some other library, we probably don't
want to export it... (Having just started thinking about this, I've no idea
whether folks using the LLVM dynamic library are independently using bits of the
ADT for example….)
>>>
>>> To the best of my understanding, many linkers don’t have
sufficiently granular dead code stripping to rely on it for this.
>>>
>>>> _______________________________________________
>>>> 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/20141110/e27f234a/attachment.html>