llvm dev - Jun 2012 - [LLVMdev] RFC: How can AddressSanitizer, ThreadSanitizer, and similar runtime libraries leverage shared library code?

On Thu, Jun 21, 2012 at 2:29 AM, Dmitry Vyukov <dvyukov at google.com>
wrote:
> On Thu, Jun 21, 2012 at 1:23 PM, Kostya Serebryany <kcc at
google.com> wrote:
>
>> On Thu, Jun 21, 2012 at 12:52 PM, Chandler Carruth <chandlerc at
google.com>wrote:
>>
>>> On Thu, Jun 21, 2012 at 1:42 AM, Kostya Serebryany <kcc 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120621/5cca097e/attachment.html>

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>

On Thu, Jun 21, 2012 at 1:34 PM, Dmitry Vyukov <dvyukov 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.
>
*STL*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120621/ce09f1be/attachment.html>

On Thu, Jun 21, 2012 at 1:34 PM, Dmitry Vyukov <dvyukov at google.com>
wrote:
> 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.
>
Agree here. I hope to modify/extend this code soon anyway.

-- 
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120621/914e9502/attachment.html>