[PATCH] Optional support for dynamic Asan runtime

Yury Gribov tetra2005 at gmail.com
Fri Mar 21 12:44:52 PDT 2014



================
Comment at: lib/sanitizer_common/sanitizer_internal_defs.h:151
@@ +150,3 @@
+# ifdef ASAN_DYNAMIC
+#  define THREADLOCAL __thread __attribute__((tls_model("initial-exec")))
+# else
----------------
Yury Gribov wrote:
> Alexey Samsonov wrote:
> > Yury Gribov wrote:
> > > Alexey Samsonov wrote:
> > > > Please don't do this. We should really specfiy this for each variable instead.
> > > This was Kostya's request and I think it makes sense. We require ASan runtime to be the first dynamic library to load so we may safely assume that initial-exec works.
> > This is still confusing. sanitizer_internal_defs.h is included not only in ASan source files, but also in sanitizer_common source files, and you don't compile the latter with -DASAN_DYNAMIC=1 (and in general you shouldn't add sanitizer-specific defines to sanitizer_common code).
> Ok,I see the point but I'd still prefer not to save performance. Do you think building runtime with -ftls-model=initial-exec would work?
s/prefer not to save performance/prefer to save performance/

================
Comment at: lib/asan/asan_rtl.cc:563
@@ +562,3 @@
+  AsanInitializer() {
+    AsanCheckIncompatibleRT();
+    if (!asan_inited) {
----------------
Yury Gribov wrote:
> Alexey Samsonov wrote:
> > Yury Gribov wrote:
> > > Alexey Samsonov wrote:
> > > > Can't you simply call __asan_init() here? It also calls AsanCheckIncompatibleRT, checks for asan_inited, and you may add a call to AsanCheckDynamicRTPrereqs under #if ASAN_DYNAMIC
> > > No, because then __asan_init may then get called twice:
> > > 1) once from .preinit_array
> > > 2) once from this ctor
> > > which will force ASan in activated state. Actually ability to start in deactivated state greatly complicates startup.
> > Then we should be able to somehow use AsanInitFromRtl().
> I think it makes sense to detect this error ASAP and not wait till AsanInitFromRtl() gets called. By this time rt inconsistencies may already cause mysterious jumps to NULL, etc.
Also keep in mind that I'd like to detect dlopen.


http://llvm-reviews.chandlerc.com/D3042



More information about the llvm-commits mailing list