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

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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120621/ece7d7b2/attachment.html>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120621/76f037b9/attachment.html>

On Thu, Jun 21, 2012 at 1:29 PM, 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,
>
Not just currently.
I really hope that we won't need anything else.

> it's separable from everything else, and can be made to not use STL.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120621/c0135988/attachment.html>

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 Aug 16, 2012, at 8:51 AM, Alexey Samsonov <samsonov at google.com>
wrote:
> I have a very raw prototype of such a binary, that uses LLVM's
libObject, libSupport, libDebugInfo, and is integrated into ASan, which
fork+execs it
> when it needs to symbolize a stack trace. It successfully symbolizes ASan
report for model Chromium crash. If Chromium is build with -gline-tables-only
(500Mb),
> it runs in less than a second (most time is spent on loading the binary in
memory), (unsurprisingly) uses about 520Mb of memory and provides stack trace
> with file/line/column and full function names.
> 
> Do you think it is the way to go for us now?
> 
Since no one else responded that I could see... I think this sounds great :)

-eric