[PATCH] [compiler-rt] Symbolizer refactoring: Implement GetListOfModules on Windows

Timur Iskhodzhanov timurrrr at google.com
Mon Mar 23 08:15:04 PDT 2015


Hi Kuba,

Have you seen the "Sanitizer coverage: PC vs modules are not handled efficiently?" email thread on llvm-commits I've started recently?

Basically, I'm up to refactor this very code and I think the current interface and implementation are suboptimal.
How blocked is your progress by this change?  If you can wait a week or two, I can improve the code that uses these functions first and try to simplify the interface.
Since I have to do that anyways, I'm not sure it's efficient for us to do the same thing twice in parallel :)


================
Comment at: lib/sanitizer_common/sanitizer_symbolizer.cc:164
@@ +163,3 @@
+  if (modules_ == 0 || !modules_fresh_) {
+    modules_ = (LoadedModule*)(symbolizer_allocator_.Allocate(
+        kMaxNumberOfModuleContexts * sizeof(LoadedModule)));
----------------
This line leaks a lot of memory every time a module lookup fails [e.g. a new shared object is dynamically loaded].
I understand you've just moved this code around, but I think we should come up with a better solution if we've decided to refactor this code.

================
Comment at: lib/sanitizer_common/sanitizer_win.cc:226
@@ -261,3 +225,3 @@
 
-  qsort(modules, num_modules, sizeof(ModuleInfo), CompareModulesBase);
+  qsort(modules.data(), num_modules, sizeof(LoadedModule), CompareModulesBase);
 
----------------
This line looks dangerous to me now.
LoadedModule is not guaranteed to be `qsort`-friendly.
[ I think "trivially copyable" is what matters here http://www.cplusplus.com/reference/type_traits/is_trivially_copyable/ ]

It already owns a `const char *full_name_;`, and one day somebody might decide `~LoadedModule` dtor should free up some memory, or hold some non-POD member.

http://reviews.llvm.org/D8513

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list