[llvm-dev] RFC: Comprehensive Static Instrumentation
Craig, Ben via llvm-dev
llvm-dev at lists.llvm.org
Fri Jun 17 06:29:42 PDT 2016
On 6/16/2016 2:48 PM, Mehdi Amini via llvm-dev wrote:
>> On Jun 16, 2016, at 9:01 AM, TB Schardl via llvm-dev
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> The CSI framework inserts instrumentation hooks at salient locations
>> throughout the compiled code of a program-under-test, such as
>> function entry and exit points, basic-block entry and exit points,
>> before and after each memory operation, etc. Tool writers can
>> instrument a program-under-test simply by first writing a library
>> that defines the semantics of relevant hooks
>> and then statically linking their compiled library with the
>> At first glance, this brute-force method of inserting hooks at every
>> salient location in the program-under-test seems to be replete with
>> overheads. CSI overcomes these overheads through the use of
>> link-time-optimization (LTO), which is now readily available in most
>> major compilers, including GCC and LLVM. Using LTO, instrumentation
>> hooks that are not used by a particular tool can be elided, allowing
>> the overheads of these hooks to be avoided when the
> I don't understand this flow: the front-end emits all the possible
> instrumentation but the useless calls to the runtime will be removed
> during the link?
> It means that the final binary is specialized for a given tool right?
> What is the advantage of generating this useless instrumentation in
> the first place then? I'm missing a piece here...
Suppose I want to build a production build, and one build for each of
ASAN, MSAN, UBSAN, and TSAN.
With the current approach, I need to compile my source five different
times, and link five different times.
With the CSI approach (assuming it was the backing technology behind the
sanitizers), I need to compile twice (once for production, once for
instrumentation), then LTO-link five times. I can reuse my .o files
across the sanitizer types.
It's possible that the math doesn't really work out in practice if the
cost of the LTO-link dwarfs the compile times.
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev