[llvm-commits] [ASan] remove <new> header (issue 5966077)

Kostya Serebryany kcc at google.com
Thu Apr 5 09:48:35 PDT 2012


On Thu, Apr 5, 2012 at 9:38 AM, <samsonov at google.com> wrote:

> On 2012/04/05 16:25:08, kcc1 wrote:
>
>> Oh, I mean that asan_new_delete.cc should be a part of asan rtl.
>> Isn't that enough?
>>
>
> No, if ASan RTL doesn't depend on anything in asan_new_delete.cc.
>

We know how to fix it.
Juts make an empty InitNewAndDelete() and call it from another file.


> asan_new_delete.o will be archived into libasan .a but will not be
> statically linked into the exe file which contains a call to "new"
> (if we're unlucky, e.g. if libstdc++ is linked earlier).
>
>
>
>  On Thu, Apr 5, 2012 at 8:46 AM, <mailto:samsonov at google.com> wrote:
>>
>
>  > On 2012/04/04 14:57:48, kcc1 wrote:
>> >
>> >> I'd prefer to move our custom new/delete into asan_new_delete.cc,
>>
> and
>
>> >>
>> > in
>> >
>> >> that file it would probably be ok to include <new>.
>> >>
>> >
>> > Yep, that's reasonable, but we have to make sure that resulting
>> > asan_new_delete.o will be loaded from libasan .a file
>> > (otherwise our "new" implementation is just not linked into exe, and
>> > dynamic linker chooses libstdc++ implementation).
>> >
>> > We can
>> > 1) add a fake dependency between asan_rtl and asan_new_delete (in
>>
> this
>
>> > CL, a bit hacky)
>> > 2) hack lib/Driver/Tools.cpp and make sure that flag -lstdc++ is
>>
> passed
>
>> > to ld after .a with ASan RT (it is currently passed before). (looks
>>
> more
>
>> > hacky)
>> > 3) use -Wl,--whole-archive (omg).
>> >
>> >
>> >  --kcc
>> >>
>> >
>> >  On Wed, Apr 4, 2012 at 7:53 AM, <mailto:samsonov at google.com> wrote:
>> >>
>> >
>> >  > Reviewers: kcc1, timurrrr_at_google_com,
>> >> >
>> >> > Message:
>> >> > #include <new> brings a number of system libraries (e.g.
>>
> <string.h>
>
>> >>
>> > on
>> >
>> >> > Windows), which is probably unwanted. We (hopefully) can replace
>> >> > std::nothrow_t and std::bad_alloc by custom stubs, so that our
>> >>
>> > overload
>> >
>> >> > of new would still work in a user program.
>> >> >
>> >> >
>> >> >
>> >> > Please review this at
>> >>
>> >
>> > http://codereview.appspot.com/******5966077/%253Chttp://**<http://codereview.appspot.com/****5966077/%253Chttp://**>
>> >
>>
>
> codereview.appspot.com/****5966077/<http://codereview.appspot.com/**5966077/>
> <http://codereview.**appspot.com/**5966077/%3Chttp:**
> //codereview.appspot.com/**5966077/<http://codereview.appspot.com/**5966077/%3Chttp://codereview.appspot.com/5966077/>
> >
>
>> > >
>> >
>> >  >
>> >> > Affected files:
>> >> >  M     asan_interceptors.cc
>> >> >
>> >> >
>> >> > Index: asan_interceptors.cc
>> >> >
>> >>
>> > ==============================******==========================**==**
>>
>> > ==**=======
>> >
>> >  > --- asan_interceptors.cc        (revision 154006)
>> >> > +++ asan_interceptors.cc        (working copy)
>> >> > @@ -22,8 +22,6 @@
>> >> >  #include "asan_thread_registry.h"
>> >> >  #include "interception/interception.h"
>> >> >
>> >> > -#include <new>
>> >> > -
>> >> >  // Use macro to describe if specific function should be
>> >> >  // intercepted on a given platform.
>> >> >  #if !defined(_WIN32)
>> >> > @@ -331,6 +329,10 @@
>> >> >  void *operator new(size_t size) { OPERATOR_NEW_BODY; }
>> >> >  void *operator new[](size_t size) { OPERATOR_NEW_BODY; }
>> >> >  #else
>> >> > +namespace std {
>> >> > +class bad_alloc {};
>> >> > +class nothrow_t;
>> >> > +}  // namespace std
>> >> >  void *operator new(size_t size) throw(std::bad_alloc) {
>> >> > OPERATOR_NEW_BODY; }
>> >> >  void *operator new[](size_t size) throw(std::bad_alloc) {
>> >> > OPERATOR_NEW_BODY; }
>> >> >  void *operator new(size_t size, std::nothrow_t const&) throw()
>> >> >
>> >> >
>> >> >
>> >>
>> >
>> >
>> >
>> >
>>
>
> http://codereview.appspot.com/****5966077/%3Chttp://**
> codereview.appspot.com/**5966077/<http://codereview.appspot.com/**5966077/%3Chttp://codereview.appspot.com/5966077/>
> >
>
>> >
>>
>
>
>
> http://codereview.appspot.com/**5966077/<http://codereview.appspot.com/5966077/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120405/ab06edd8/attachment.html>


More information about the llvm-commits mailing list