Kostya Serebryany
2012-Jun-21 09:23 UTC
[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>
Dmitry Vyukov
2012-Jun-21 09:29 UTC
[LLVMdev] RFC: How can AddressSanitizer, ThreadSanitizer, and similar runtime libraries leverage shared library code?
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>
Kostya Serebryany
2012-Jun-21 09:30 UTC
[LLVMdev] RFC: How can AddressSanitizer, ThreadSanitizer, and similar runtime libraries leverage shared library code?
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>
Chandler Carruth
2012-Jun-21 09:30 UTC
[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>
Eric Christopher
2012-Aug-29 17:48 UTC
[LLVMdev] RFC: How can AddressSanitizer, ThreadSanitizer, and similar runtime libraries leverage shared library code?
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
Possibly Parallel Threads
- [LLVMdev] RFC: How can AddressSanitizer, ThreadSanitizer, and similar runtime libraries leverage shared library code?
- [LLVMdev] RFC: How can AddressSanitizer, ThreadSanitizer, and similar runtime libraries leverage shared library code?
- [LLVMdev] RFC: How can AddressSanitizer, ThreadSanitizer, and similar runtime libraries leverage shared library code?
- [LLVMdev] RFC: How can AddressSanitizer, ThreadSanitizer, and similar runtime libraries leverage shared library code?
- [LLVMdev] RFC: How can AddressSanitizer, ThreadSanitizer, and similar runtime libraries leverage shared library code?