Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Instrumentor] Add counter IDs #16

Open
wants to merge 37 commits into
base: instrumentor_dev_rewrite
Choose a base branch
from

Conversation

EthanLuisMcDonough
Copy link

This pull request introduces the add_call_counters base configuration option. When enabled, this option will add an ID parameter to the end of each instrumentor function. Each instrumentation opportunity will have its own unique ID associated with it.

jdoerfert and others added 30 commits December 6, 2024 14:51
Both internally and externally we instrument code all the time. Usually,
those are hand written traversals that look for some specific
instructions or program points and then provide information to a
runtime. Since the real difference is in the runtime, and the
instrumentation is basically always the same, people can use this
Instrumentor pass and configure it to their needs.

Initial implementation only instruments alloca instructions but shows
the setup, and configurability via a JSON file.
Following the alloca example, this adds store instruction
instrumentation support. The following properties are captured:
```
void __instrumentor_store_pre(void* PointerOperand,
			      int32_t PointerOperandAddressSpace,
			      int64_t ValueOperand,
			      int64_t ValueOperandSize,
			      int32_t ValueOperandTypeId,
			      int64_t Alignment,
			      int32_t AtomicityOrdering,
			      int8_t SyncScopeId,
			      int8_t IsVolatile);

void __instrumentor_store_pre_ind(void* PointerOperand,
			          int32_t PointerOperandAddressSpace,
			          void* ValueOperandStorage,
			          int64_t ValueOperandSize,
			          int32_t ValueOperandTypeId,
			          int64_t Alignment,
			          int32_t AtomicityOrdering,
			          int8_t SyncScopeId,
			          int8_t IsVolatile);
```
Following the store example, this adds load instruction
instrumentation support. The following properties are captured:
```
void __instrumentor_pre_load(void* PointerOperand,
			     int32_t PointerOperandAddressSpace,
			     int64_t ValueSize,
			     int32_t ValueTypeId,
			     int64_t Alignment,
			     int32_t AtomicityOrdering,
			     int8_t SyncScopeId,
			     int8_t IsVolatile);

int64_t __instrumentor_post_load(void* PointerOperand,
				 int32_t PointerOperandAddressSpace,
				 int64_t Value,
				 int64_t ValueSize,
				 int32_t ValueTypeId,
				 int64_t Alignment,
				 int32_t AtomicityOrdering,
				 int8_t SyncScopeId,
				 int8_t IsVolatile);

void __instrumentor_post_load_ind(void* PointerOperand,
				  int32_t PointerOperandAddressSpace,
				  void* ValueStorage,
				  int64_t ValueSize,
				  int32_t ValueTypeId,
				  int64_t Alignment,
				  int32_t AtomicityOrdering,
				  int8_t SyncScopeId,
				  int8_t IsVolatile);
```
This adds allocation call instrumentation support by exposing more of
the memory builtin information, notably, non constant information.

The following properties are captured:
```
  void __instrumentor_post_allocation_call(void* MemoryPointer,
					   int64_t MemorySize,
					   int32_t Alignment,
					   void /*char*/ * Family,
					   int8_t InitialValue);

  void* __instrumentor_post_allocation_call(void* MemoryPointer,
					    int64_t MemorySize,
					    int32_t Alignment,
					    void /*char*/ * Family,
					    int8_t InitialValue);
```
Passing the arguments -Xclang -finstrumentor enables the instrumentor
pass when compiling with Clang.
Features and optimizations:
  - Instrumentation of call arguments (pointers)
  - Instrumentation of base pointers
  - Instrumentation of globals
  - Skip loads and stores that are known to be safe at compile time
  - Passing base pointer info to load and store instrumentation calls
The arguments of the main function instrumentation are both
pointers. We call the instrumentation function passing the
pointers to the argc and argv arguments, so the instrumentation
implementation can modify them.
A instrumentor database file contains the names of the functions and global
variables that have been instrumented for a particular LLVM module. The
database file is named as "<module-name>.instrdb".

The -mllvm -instrumentor-read-database-dir=DIR allows loading the database
files of other instrumented modules that are stored in the directory DIR. The
-mllvm -instrumentor-write-database-dir=DIR allows writing the instrumented
functions and globals from the current module in a database file in the
directory DIR. If these flags are not specified, no database is read or
written.
The call instrumentation was not working properly for globals and accesses
that were marked as compile-time safe (e.g., constant offset on a alloca).
This commit fixes that and removes the need for annotations.

The option OnlyReplacedPointerValues in the call instrumentation is an
optimzation to avoid passing non-pointer arguments and pointer arguments
that were not replaced by another runtime call. This is very useful for
the use case of the address sanitizer.
The reuse of temporary allocas for runtime calls did not consider when
a call can use more than one alloca with the same total size. In that
case, both were trying to use the same allocas, producing invalid IR.

Now, we allow more than one alloca for each size. Each RTArgumentPack
holds the temporary allocas that are used for a particular runtime call.
Once the object is destroyed, these allocas are returned for reuse.
The OperandValueSize parameter is the number of bytes being stored
instead of the number of bits.
@ivanradanov ivanradanov force-pushed the instrumentor_dev_rewrite branch from b92a11a to dfa9b6a Compare February 13, 2025 07:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants