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

+dvyukov On Wed, Jun 20, 2012 at 7:12 AM, Chandler Carruth <chandlerc at google.com>wrote: > Hello folks (and sorry if I've forgotten to CC anyone with particular > interest to this discussion...): > > I've been thinking a lot about how best to build advanced runtime > libraries like ASan, and scale them up. Note that this does *not* try to > address any licensing

On Tue, Jun 19, 2012 at 9:07 PM, Kostya Serebryany <kcc at google.com> wrote: > +dvyukov > > On Wed, Jun 20, 2012 at 7:12 AM, Chandler Carruth <chandlerc at google.com>wrote: > >> Hello folks (and sorry if I've forgotten to CC anyone with particular >> interest to this discussion...): >> >> I've been thinking a lot about how best to build

On Wed, Jun 20, 2012 at 9:39 AM, Chandler Carruth <chandlerc at google.com>wrote: > On Tue, Jun 19, 2012 at 9:07 PM, Kostya Serebryany <kcc at google.com> wrote: > >> +dvyukov >> >> On Wed, Jun 20, 2012 at 7:12 AM, Chandler Carruth <chandlerc at google.com>wrote: >> >>> Hello folks (and sorry if I've forgotten to CC anyone with

On Tue, Jun 19, 2012 at 10:46 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Wed, Jun 20, 2012 at 9:39 AM, Chandler Carruth <chandlerc at google.com>wrote: > >> On Tue, Jun 19, 2012 at 9:07 PM, Kostya Serebryany <kcc at google.com>wrote: >> >>> +dvyukov >>> >>> On Wed, Jun 20, 2012 at 7:12 AM, Chandler Carruth

On Tue, Jun 19, 2012 at 10:59 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Tue, Jun 19, 2012 at 10:46 PM, Kostya Serebryany <kcc at google.com>wrote: > >> >> >> On Wed, Jun 20, 2012 at 9:39 AM, Chandler Carruth <chandlerc at google.com>wrote: >> >>> On Tue, Jun 19, 2012 at 9:07 PM, Kostya Serebryany <kcc at

On Thu, Jun 21, 2012 at 1:44 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> >>>>>>>> }

Hi, Yes, stlport was a pain to deploy and maintain + it calls normal operator new/delete (there is no way to put them into a separate namespace). Note that in some codebases we build asan/tsan runtimes from source. How the build process will look with that object file mangling? How easy it is to integrate it into a custom build process? Soon I will start integrating tsan into Go language. For

Reviving the discussion. The cool cmake-build of compiler-rt is not completely functional, but allows sanitizer runtimes to reuse LLVM code with almost no dirty hacks. Suppose I want to run call functions from LLVM libs (currently: LLVMDebugInfo, LLVMSupport) from sanitizer runtime. 1) I can simply include LLVM headers in sanitizer runtime, and it compiles and builds static asan runtime

On Thu, Jun 21, 2012 at 12:21 AM, Dmitry Vyukov <dvyukov at google.com> wrote: > Hi, > > Yes, stlport was a pain to deploy and maintain + it calls normal operator > new/delete (there is no way to put them into a separate namespace). > Ok, but putting the raw symbols into a "namespace" with the linker shouldn't be subject to these limitations. Note that in some

(resurrecting the thread, as much is discussed here already) Formulating Kostya's suggestion: What do you think of compiling LLVM sources into ASan/TSan runtime by just taking the library sources, providing custom compiler (target) flags *and* a flag "-Dllvm=__sanitizer_llvm"? Yeah, it's hacky and applicable to LLVM libs, but OTOH we don't plan to use smth else for now (in

On Thu, Jun 21, 2012 at 11:52 AM, Chandler Carruth <chandlerc at google.com>wrote: > > Hi, >> >> Yes, stlport was a pain to deploy and maintain + it calls normal operator >> new/delete (there is no way to put them into a separate namespace). >> > > Ok, but putting the raw symbols into a "namespace" with the linker > shouldn't be subject to

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

On Thu, Jun 21, 2012 at 2:39 AM, Alexey Samsonov <samsonov at google.com>wrote: > > > 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

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

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

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

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,

On Thu, Jun 21, 2012 at 1:04 AM, Dmitry Vyukov <dvyukov at google.com> wrote: > On Thu, Jun 21, 2012 at 11:52 AM, Chandler Carruth <chandlerc at google.com>wrote: >> >> Hi, >>> >>> Yes, stlport was a pain to deploy and maintain + it calls normal >>> operator new/delete (there is no way to put them into a separate namespace). >>>

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? (This approach, as well as Chandler's original approach will have to deal with malloc,

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