[PATCH] D21753: Comprehensive Static Instrumentation (2/2): Clang flag

[Derek Bruening via cfe-commits]

bruening added inline comments.

================
Comment at: docs/CSI.rst:30
@@ +29,3 @@
+To create a CSI tool, add ``#include <csi.h>`` at the top of the tool source
+and implement function bodies for the hooks relevant to the tool.
+
----------------
Are there any constraints on what libraries the tool library is allowed to use?  Generally there are, for tool code that runs in the same process as the application.  The tool library will be operating at arbitrary points during application execution.  This means that it should avoid using the same resources as the instrumented application, because the application's routines are not all re-entrant and they use global state, and to minimize perturbation of the application's behavior (such as heap layout patterns) from how it behaves with no tool present.  A tool using standard libraries becomes more likely to cause issues when libc routines are being intercepted by the tool (see related comment below) or libc itself is instrumented. The existing LLVM instrumentation runtime libraries, for the sanitizer tools, avoid calling libc routines and are not able to use the STL: they use their own custom implementations of all data structures and algorithms that they need, but this is a small set.  Dynamic tool platforms like Pin and DynamoRIO go to great lengths to isolate tool libraries by loading separate copies of libc.  Has any thought been put into isolating the tool library and its imports from the application?  I realize that some of these may seem more long-term topics, but if the idea is to create a framework for use with a wide range of tools it is good to consider all issues up front.


================
Comment at: docs/CSI.rst:230
@@ +229,3 @@
+
+CSI provides the following hooks for memory operations:
+
----------------
For observing loads and stores, typically compiler-based tools intercept libc's memcpy, memset, etc. (or in some cases libc is built and instrumented along with the application), to avoid missing many memory references.  The existing LLVM sanitizer tools all intercept a large number of libc routines to ensure they see more than just events happening in application code proper.  Has there been any thought about this for CSI?



Repository:
  rL LLVM

https://reviews.llvm.org/D21753