[PATCH] Optional support for dynamic Asan runtime

Alexey Samsonov samsonov at google.com
Mon Mar 31 07:01:44 PDT 2014



================
Comment at: cmake/Modules/AddCompilerRT.cmake:45
@@ +44,3 @@
+#                         DEFS <compile definitions>
+#                         OUTPUT_NAME <library name>)
+macro(add_compiler_rt_runtime name arch type)
----------------
Why is the default OUTPUT_NAME not suitable here?

================
Comment at: cmake/Modules/AddCompilerRT.cmake:41
@@ +40,3 @@
+# Helper for add_compiler_rt_{static,shared}_runtime.
+# add_compiler_rt_runtime(<name> <arch> <type>
+#                         SOURCES <source files>
----------------
FYI I've submitted this renaming as r205183, so you can rebase your patch to minimize the diff.

================
Comment at: lib/asan/asan_linux.cc:82
@@ +81,3 @@
+  const char *first_dso_name = 0;
+  dl_iterate_phdr(FindFirstDSOCallback, &first_dso_name);
+  if (first_dso_name && !internal_strstr(first_dso_name, "libclang_rt.asan") &&
----------------
Yury Gribov wrote:
> Yury Gribov wrote:
> > I could probably also use DumpListOfModules here. What's your opinion?
> Although the order of modules in address space does not necessarily match the order in which they were loaded by ld.so. Dl_iterate_phdr is probably more reliable...
Yeah.

================
Comment at: lib/asan/asan_linux.cc:93
@@ +92,3 @@
+
+void AsanCheckIncompatibleRT() {
+#if !SANITIZER_ANDROID
----------------
Yury Gribov wrote:
> I think we can do this:
> * for static rt:
> ** check if dynamic rt in /proc/maps (and die if it's there)
> ** set __asan_rt_version
> * for dynamic rt:
> ** check __asan_rt_version (and die if it's already initialized by static rt)
> 
> But all this looks too complicated compared to current approach (dlsym + preinit allocator).
I think this would be easier to digest than these preinit-allocator hooks. I'd try to avoid calling functions from system libraries before ASan is initialized, by all means possible. Could you please try if this approach works?

Does anyone else have other opinions about it?


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



More information about the llvm-commits mailing list