[LLVMdev] RFC: How can AddressSanitizer, ThreadSanitizer, and similar runtime libraries leverage shared library code?

Dmitry Vyukov dvyukov at google.com
Thu Jun 21 02:34:23 PDT 2012


On Thu, Jun 21, 2012 at 1:30 PM, Chandler Carruth <chandlerc at google.com>wrote:

> Can we alter the build system so that when building a run-time library it
>>>>> modifies all .cpp files like this:
>>>>>    namespace FOO {
>>>>>    <file body>
>>>>>    }
>>>>> This will give us essentially the same thing, but w/o system dependent
>>>>> object file hackery.
>>>>> Maybe we can add a Clang flag to add such a namespace for us?
>>>>>
>>>>
>>>> I think this is essentially what Dmitry was talking about w/ past
>>>> STLport experience. It has lots of limitations:
>>>>
>>>
>>> Patching object files still sounds much scarier and harder to port.
>>> I'd prefer to find a solution that involves only source files and maybe
>>> clang.
>>> Pondering...
>>>
>>>
>>>> - You can't use the normal system standard library
>>>>
>>> - You have to build the standard library from source
>>>> - You can't wrap certain parts of it (operator new, delete, a few other
>>>> things)
>>>> - You can't re-use any C libraries (zlib for example)
>>>>
>>>
>>
>> Perhaps you are solving a broader problem. But as for asan/tsan, we
>> currently need only symbolizer, it's separable from everything else, and
>> can be made to not use STL.
>>
>
> If you want to share LLVM code for the object and dwarf reading, I do not
> believe this to be true at all.
>

I've already removed code for the object reading for exactly that reason,
so now it's just dwarf parsing :) There are some CTL containers involved,
but I think they can be replaced.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120621/cf106cc6/attachment.html>


More information about the llvm-dev mailing list