>> 2) Can we add a check to REAL() to produce a nice diagnostic message
>> in this case?
>
> There are a few such checks.

I don't think that REAL() currently checks anything:

~/llvm/trunk/projects/compiler-rt/lib$ grep NULL interception/* -l
interception/interception_win.cc

We seem to rely on callers to make sure that these variables are
properly initialized.

>> 3) We once discussed making __asan_init a constructor to solve this
>> problem (discussion and patch available here:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937).
>
>
> __asan_init is a constructor, but there could be other constructors that run
> before it.

Are you sure? I don't see any ctors in compiler-rt trunk:
~/llvm/trunk/projects/compiler-rt/lib/asan$ grep constructor *  | grep
-v TestCases
asan_thread.cc:      // On Android, libc constructor is called _after_
asan_init, and cleans up
asan_thread.h:  // NOTE: There is no AsanThread constructor. It is allocated

>> Some proposal from me:
>> * could you add a note about spurious "failed to intercept" warnings?
>> (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58680 for reference)
>
> Hm? What about that? How would you phrase it?

Added to Cons section in wiki.

>> BTW should we acronimize as ASAN or ASan?
>
> Emm. I equally like all of {asan,ASAN,ASan} and I don't care much.

I don't care much but I vaguely remember that wiki once explicitly
insisted on "ASan".

-Y

-- 
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to