llvm-tutor is a collection of self-contained reference LLVM passes

Overview

llvm-tutor

Build Status Build Status Build Status

Example LLVM passes - based on LLVM 11

llvm-tutor is a collection of self-contained reference LLVM passes. It's a tutorial that targets novice and aspiring LLVM developers. Key features:

  • Out-of-tree - builds against a binary LLVM installation (no need to build LLVM from sources)
  • Complete - includes CMake build scripts, LIT tests, CI set-up and documentation
  • Modern - based on the latest version of LLVM (and updated with every release)

Overview

LLVM implements a very rich, powerful and popular API. However, like many complex technologies, it can be quite daunting and overwhelming to learn and master. The goal of this LLVM tutorial is to showcase that LLVM can in fact be easy and fun to work with. This is demonstrated through a range self-contained, testable LLVM passes, which are implemented using idiomatic LLVM.

This document explains how to set-up your environment, build and run the examples, and go about debugging. It contains a high-level overview of the implemented examples and contains some background information on writing LLVM passes. The source files, apart from the code itself, contain comments that will guide you through the implementation. All examples are complemented with LIT tests and reference input files.

Visit clang-tutor if you are internested in similar tutorial for Clang.

Table of Contents

HelloWorld: Your First Pass

The HelloWorld pass from HelloWorld.cpp is a self-contained reference example. The corresponding CMakeLists.txt implements the minimum set-up for an out-of-source pass.

For every function defined in the input module, HelloWord prints its name and the number of arguments that it takes. You can build it like this:

export LLVM_DIR=<installation/dir/of/llvm/11>
mkdir build
cd build
cmake -DLT_LLVM_INSTALL_DIR=$LLVM_DIR <source/dir/llvm/tutor>/HelloWorld/
make

Before you can test it, you need to prepare an input file:

# Generate an LLVM test file
$LLVM_DIR/bin/clang -S -emit-llvm <source/dir/llvm/tutor/>inputs/input_for_hello.c -o input_for_hello.ll

Finally, run HelloWorld with opt (use libHelloWorld.so on Linux and libHelloWorld.dylib on Mac OS):

# Run the pass
$LLVM_DIR/bin/opt -load-pass-plugin ./libHelloWorld.{so|dylib} -passes=hello-world -disable-output input_for_hello.ll
# Expected output
(llvm-tutor) Hello from: foo
(llvm-tutor)   number of arguments: 1
(llvm-tutor) Hello from: bar
(llvm-tutor)   number of arguments: 2
(llvm-tutor) Hello from: fez
(llvm-tutor)   number of arguments: 3
(llvm-tutor) Hello from: main
(llvm-tutor)   number of arguments: 2

The HelloWorld pass doesn't modify the input module. The -disable-output flag is used to prevent opt from printing the output bitcode file.

Development Environment

Platform Support And Requirements

This project has been tested on Ubuntu 18.04 and Mac OS X 10.14.4. In order to build llvm-tutor you will need:

  • LLVM 11
  • C++ compiler that supports C++14
  • CMake 3.13.4 or higher

Note that the default version of CMake in Ubuntu 18.04 is 3.10.2, so you may need to update it manually.

In order to run the passes, you will need:

  • clang-11 (to generate input LLVM files)
  • opt (to run the passes)

There are additional requirements for tests (these will be satisfied by installing LLVM 11):

  • lit (aka llvm-lit, LLVM tool for executing the tests)
  • FileCheck (LIT requirement, it's used to check whether tests generate the expected output)

Installing LLVM 11 on Mac OS X

On Darwin you can install LLVM 11 with Homebrew:

brew install [email protected]

If you already have an older version of LLVM installed, you can upgrade it to LLVM 11 like this:

brew upgrade llvm

Once the installation (or upgrade) is complete, all the required header files, libraries and tools will be located in /usr/local/opt/llvm/.

Installing LLVM 11 on Ubuntu

On Ubuntu Bionic, you can install modern LLVM from the official repository:

wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key | sudo apt-key add -
sudo apt-add-repository "deb http://apt.llvm.org/bionic/ llvm-toolchain-bionic-11 main"
sudo apt-get update
sudo apt-get install -y llvm-11 llvm-11-dev clang-11 llvm-11-tools

This will install all the required header files, libraries and tools in /usr/lib/llvm-11/.

Building LLVM 11 From Sources

Building from sources can be slow and tricky to debug. It is not necessary, but might be your preferred way of obtaining LLVM 11. The following steps will work on Linux and Mac OS X:

git clone https://github.com/llvm/llvm-project.git
cd llvm-project
git checkout tags/llvmorg-11.0.1
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=host -DLLVM_ENABLE_PROJECTS=clang <llvm-project/root/dir>/llvm/
cmake --build .

For more details read the official documentation.

Building & Testing

Building

You can build llvm-tutor (and all the provided pass plugins) as follows:

cd <build/dir>
cmake -DLT_LLVM_INSTALL_DIR=<installation/dir/of/llvm/11> <source/dir/llvm/tutor>
make

The LT_LLVM_INSTALL_DIR variable should be set to the root of either the installation or build directory of LLVM 11. It is used to locate the corresponding LLVMConfig.cmake script that is used to set the include and library paths.

Testing

In order to run llvm-tutor tests, you need to install llvm-lit (aka lit). It's not bundled with LLVM 11 packages, but you can install it with pip:

# Install lit - note that this installs lit globally
pip install lit

Running the tests is as simple as:

$ lit <build_dir>/test

Voilà! You should see all tests passing.

LLVM Plugins as shared objecs

In llvm-tutor every LLVM pass is implemented in a separate shared object (you can learn more about shared objects here). These shared objects are essentially dynamically loadable plugins for opt. All plugins are built in the directory.

Note that the extension of dynamically loaded shared objects differs between Linux and Mac OS. For example, for the HelloWorld pass you will get:

  • libHelloWorld.so on Linux
  • libHelloWorld.dylib on MacOS.

For the sake of consistency, in this README.md file all examples use the *.so extension. When working on Mac OS, use *.dylib instead.

Overview of The Passes

The available passes are categorised as either Analysis, Transformation or CFG. The difference between Analysis and Transformation passes is rather self-explanatory (here is a more technical breakdown). A CFG pass is simply a Transformation pass that modifies the Control Flow Graph. This is frequently a bit more complex and requires some extra bookkeeping, hence a dedicated category.

In the following table the passes are grouped thematically and ordered by the level of complexity.

Name Description Category
HelloWorld visits all functions and prints their names Analysis
OpcodeCounter prints a summary of LLVM IR opcodes in the input module Analysis
InjectFuncCall instruments the input module by inserting calls to printf Transformation
StaticCallCounter counts direct function calls at compile-time (static analysis) Analysis
DynamicCallCounter counts direct function calls at run-time (dynamic analysis) Transformation
MBASub obfuscate integer sub instructions Transformation
MBAAdd obfuscate 8-bit integer add instructions Transformation
FindFCmpEq finds floating-point equality comparisons Analysis
ConvertFCmpEq converts direct floating-point equality comparisons to difference comparisons Transformation
RIV finds reachable integer values for each basic block Analysis
DuplicateBB duplicates basic blocks, requires RIV analysis results CFG
MergeBB merges duplicated basic blocks CFG

Once you've built this project, you can experiment with every pass separately. All passes, except for HelloWorld, are described in more details below.

LLVM passes work with LLVM IR files. You can generate one like this:

export LLVM_DIR=<installation/dir/of/llvm/11>
# Textual form
$LLVM_DIR/bin/clang  -emit-llvm input.c -S -o out.ll
# Binary/bit-code form
$LLVM_DIR/bin/clang  -emit-llvm input.c -o out.bc

It doesn't matter whether you choose the binary, *.bc (default), or textual (.ll, requires the -S flag) form, but obviously the latter is more human-readable. Similar logic applies to opt (by default it generates *.bc files, use -S to generate an *.ll file instead).

As noted earlier, all examples in this file use the *.so extension for pass plugins. When working on Mac OS, use *.dylib instead.

OpcodeCounter

OpcodeCounter is an Analysis pass that prints a summary of the LLVM IR opcodes encountered in every function in the input module. This pass can be run automatically with one of the pre-defined optimisation pipelines. However, let's use our tried and tested method first.

Run the pass

We will use input_for_cc.c to test OpcodeCounter. Since OpcodeCounter is an Analysis pass, we want opt to print its results. There are two ways of achieving this. First, you need to choose which pass manager you want to use (see here for more details). Next:

  • Legacy Pass Manager: use the -analyze command line option. This option is used to instruct opt to print the results of the analysis pass that has just been run.
  • New Pass Manager: Simply use the printing pass that corresponds to OpcodeCounter. This pass is called print. No extra arguments are needed, but it's a good idea to add -disable-output (it is not required when using -analyze).
" -disable-output input_for_cc.bc ">
export LLVM_DIR=<installation/dir/of/llvm/11>
# Generate an LLVM file to analyze
$LLVM_DIR/bin/clang  -emit-llvm -c <source_dir>/inputs/input_for_cc.c -o input_for_cc.bc
# Run the pass through opt - Legacy PM
$LLVM_DIR/bin/opt -load <build_dir>/lib/libOpcodeCounter.so -legacy-opcode-counter -analyze input_for_cc.bc
# Run the pass through opt - New PM
$LLVM_DIR/bin/opt -load-pass-plugin <build_dir>/lib/libOpcodeCounter.so --passes="print" -disable-output input_for_cc.bc

For main, OpcodeCounter prints the following summary (note that when running the pass, a summary for other functions defined in input_for_cc.bc is also printed):

=================================================
LLVM-TUTOR: OpcodeCounter results for `main`
=================================================
OPCODE               #N TIMES USED
-------------------------------------------------
load                 2
br                   4
icmp                 1
add                  1
ret                  1
alloca               2
store                4
call                 4
-------------------------------------------------

Auto-registration with optimisation pipelines

You can run OpcodeCounter by simply specifying an optimisation level (e.g. -O{1|2|3|s}). This is achieved through auto-registration with the existing optimisation pass pipelines. Note that you still have to specify the plugin file to be loaded:

$LLVM_DIR/bin/opt -load <build_dir>/lib/libOpcodeCounter.so -O1 input_for_cc.bc

In this example I used the Legacy Pass Manager (the plugin file was specified with -load rather than -load-pass-plugin). The auto-registration also works with the New Pass Manager:

$LLVM_DIR/bin/opt -load-pass-plugin <build_dir>/lib/libOpcodeCounter.so --passes='default' input_for_cc.bc

This is implemented in OpcodeCounter.cpp, on line 82 for the New PM, and on line 122 for the Legacy PM. This section contains more information about the pass managers in LLVM.

InjectFuncCall

This pass is a HelloWorld example for code instrumentation. For every function defined in the input module, InjectFuncCall will add (inject) the following call to printf:

printf("(llvm-tutor) Hello from: %s\n(llvm-tutor)   number of arguments: %d\n", FuncName, FuncNumArgs)

This call is added at the beginning of each function (i.e. before any other instruction). FuncName is the name of the function and FuncNumArgs is the number of arguments that the function takes.

Run the pass

We will use input_for_hello.c to test InjectFuncCall:

export LLVM_DIR=<installation/dir/of/llvm/11>
# Generate an LLVM file to analyze
$LLVM_DIR/bin/clang  -emit-llvm -c <source_dir>/inputs/input_for_hello.c -o input_for_hello.bc
# Run the pass through opt
$LLVM_DIR/bin/opt -load <build_dir>/lib/libInjectFuncCall.so -legacy-inject-func-call input_for_hello.bc -o instrumented.bin

This generates instrumented.bin, which is the instrumented version of input_for_hello.bc. In order to verify that InjectFuncCall worked as expected, you can either check the output file (and verify that it contains extra calls to printf) or run it:

$LLVM_DIR/bin/lli instrumented.bin
(llvm-tutor) Hello from: main
(llvm-tutor)   number of arguments: 2
(llvm-tutor) Hello from: foo
(llvm-tutor)   number of arguments: 1
(llvm-tutor) Hello from: bar
(llvm-tutor)   number of arguments: 2
(llvm-tutor) Hello from: foo
(llvm-tutor)   number of arguments: 1
(llvm-tutor) Hello from: fez
(llvm-tutor)   number of arguments: 3
(llvm-tutor) Hello from: bar
(llvm-tutor)   number of arguments: 2
(llvm-tutor) Hello from: foo
(llvm-tutor)   number of arguments: 1

InjectFuncCall vs HelloWorld

You might have noticed that InjectFuncCall is somewhat similar to HelloWorld. In both cases the pass visits all functions, prints their names and the number of arguments. The difference between the two passes becomes quite apparent when you compare the output generated for the same input file, e.g. input_for_hello.c. The number of times Hello from is printed is either:

  • once per every function call in the case of InjectFuncCall, or
  • once per function definition in the case of HelloWorld.

This makes perfect sense and hints how different the two passes are. Whether to print Hello from is determined at either:

  • run-time for InjectFuncCall, or
  • compile-time for HelloWorld.

Also, note that in the case of InjectFuncCall we had to first run the pass with opt and then execute the instrumented IR module in order to see the output. For HelloWorld it was sufficient to run run the pass with opt.

StaticCallCounter

The StaticCallCounter pass counts the number of static function calls in the input LLVM module. Static refers to the fact that these function calls are compile-time calls (i.e. visible during the compilation). This is in contrast to dynamic function calls, i.e. function calls encountered at run-time (when the compiled module is run). The distinction becomes apparent when analysing functions calls within loops, e.g.:

  for (i = 0; i < 10; i++)
    foo();

Although at run-time foo will be executed 10 times, StaticCallCounter will report only 1 function call.

This pass will only consider direct functions calls. Functions calls via function pointers are not taken into account.

Run the pass through opt

We will use input_for_cc.c to test StaticCallCounter:

export LLVM_DIR=<installation/dir/of/llvm/11>
# Generate an LLVM file to analyze
$LLVM_DIR/bin/clang  -emit-llvm -c <source_dir>/inputs/input_for_cc.c -o input_for_cc.bc
# Run the pass through opt - Legacy PM
$LLVM_DIR/bin/opt -load <build_dir>/lib/libStaticCallCounter.so -legacy-static-cc -analyze input_for_cc.bc

You should see the following output:

=================================================
LLVM-TUTOR: static analysis results
=================================================
NAME                 #N DIRECT CALLS
-------------------------------------------------
foo                  3
bar                  2
fez                  1
-------------------------------------------------

Note the extra command line option above: -analyze. It's required to inform opt to print the results of the analysis to stdout. We discussed this option in more detail here.

Run the pass through static

You can run StaticCallCounter through a standalone tool called static. static is an LLVM based tool implemented in StaticMain.cpp. It is a command line wrapper that allows you to run StaticCallCounter without the need for opt:

<build_dir>/bin/static input_for_cc.bc

It is an example of a relatively basic static analysis tool. Its implementation demonstrates how basic pass management in LLVM works (i.e. it handles that for itself instead of relying on opt).

DynamicCallCounter

The DynamicCallCounter pass counts the number of run-time (i.e. encountered during the execution) function calls. It does so by inserting call-counting instructions that are executed every time a function is called. Only calls to functions that are defined in the input module are counted. This pass builds on top of ideas presented in InjectFuncCall. You may want to experiment with that example first.

Run the pass

We will use input_for_cc.c to test DynamicCallCounter:

export LLVM_DIR=<installation/dir/of/llvm/11>
# Generate an LLVM file to analyze
$LLVM_DIR/bin/clang  -emit-llvm -c <source_dir>/inputs/input_for_cc.c -o input_for_cc.bc
# Instrument the input file
$LLVM_DIR/bin/opt -load <build_dir>/lib/libDynamicCallCounter.so -legacy-dynamic-cc input_for_cc.bc -o instrumented_bin

This generates instrumented.bin, which is the instrumented version of input_for_cc.bc. In order to verify that DynamicCallCounter worked as expected, you can either check the output file (and verify that it contains new call-counting instructions) or run it:

# Run the instrumented binary
$LLVM_DIR/bin/lli ./instrumented_bin

You will see the following output:

=================================================
LLVM-TUTOR: dynamic analysis results
=================================================
NAME                 #N DIRECT CALLS
-------------------------------------------------
foo                  13
bar                  2
fez                  1
main                 1

DynamicCallCounter vs StaticCallCounter

The number of function calls reported by DynamicCallCounter and StaticCallCounter are different, but both results are correct. They correspond to run-time and compile-time function calls respectively. Note also that for StaticCallCounter it was sufficient to run the pass through opt to have the summary printed. For DynamicCallCounter we had to run the instrumented binary to see the output. This is similar to what we observed when comparing HelloWorld and InjectFuncCall.

Mixed Boolean Arithmetic Transformations

These passes implement mixed boolean arithmetic transformations. Similar transformation are often used in code obfuscation (you may also know them from Hacker's Delight) and are a great illustration of what and how LLVM passes can be used for.

Similar transformation are possible at the source-code level. The relevant Clang plugins are available in clang-tutor.

MBASub

The MBASub pass implements this rather basic expression:

a - b == (a + ~b) + 1

Basically, it replaces all instances of integer sub according to the above formula. The corresponding LIT tests verify that both the formula and that the implementation are correct.

Run the pass

We will use input_for_mba_sub.c to test MBASub:

export LLVM_DIR=<installation/dir/of/llvm/11>
$LLVM_DIR/bin/clang -emit-llvm -S <source_dir>/inputs/input_for_mba_sub.c -o input_for_sub.ll
$LLVM_DIR/bin/opt -load <build_dir>/lib/libMBASub.so -legacy-mba-sub -S input_for_sub.ll -o out.ll

MBAAdd

The MBAAdd pass implements a slightly more involved formula that is only valid for 8 bit integers:

a + b == (((a ^ b) + 2 * (a & b)) * 39 + 23) * 151 + 111

Similarly to MBASub, it replaces all instances of integer add according to the above identity, but only for 8-bit integers. The LIT tests verify that both the formula and the implementation are correct.

Run the pass

We will use input_for_add.c to test MBAAdd:

export LLVM_DIR=<installation/dir/of/llvm/11>
$LLVM_DIR/bin/clang -O1 -emit-llvm -S <source_dir>/inputs/input_for_mba.c -o input_for_mba.ll
$LLVM_DIR/bin/opt -load <build_dir>/lib/libMBAAdd.so -legacy-mba-add -S input_for_mba.ll -o out.ll

You can also specify the level of obfuscation on a scale of 0.0 to 1.0, with 0 corresponding to no obfuscation and 1 meaning that all add instructions are to be replaced with (((a ^ b) + 2 * (a & b)) * 39 + 23) * 151 + 111, e.g.:

$LLVM_DIR/bin/opt -load <build_dir>/lib/libMBAAdd.so -legacy-mba-add -mba-ratio=0.3 <source_dir>/inputs/input_for_mba.c -o out.ll

RIV

RIV is an analysis pass that for each basic block BB in the input function computes the set reachable integer values, i.e. the integer values that are visible (i.e. can be used) in BB. Since the pass operates on the LLVM IR representation of the input file, it takes into account all values that have integer type in the LLVM IR sense. In particular, since at the LLVM IR level booleans are represented as 1-bit wide integers (i.e. i1), you will notice that booleans are also included in the result.

This pass demonstrates how to request results from other analysis passes in LLVM. In particular, it relies on the Dominator Tree analysis pass from LLVM, which is is used to obtain the dominance tree for the basic blocks in the input function.

Run the pass

We will use input_for_riv.c to test RIV:

export LLVM_DIR=<installation/dir/of/llvm/11>
# Generate an LLVM file to analyze
$LLVM_DIR/bin/clang -emit-llvm -S -O1 <source_dir>/inputs/input_for_riv.c -o input_for_riv.ll
# Run the pass through opt - Legacy PM
$LLVM_DIR/bin/opt -load <build_dir>/lib/libRIV.so -legacy-riv -analyze input_for_riv.ll

You will see the following output:

=================================================
LLVM-TUTOR: RIV analysis results
=================================================
BB id      Reachable Ineger Values
-------------------------------------------------
BB %entry
             i32 %a
             i32 %b
             i32 %c
BB %if.then
               %add = add nsw i32 %a, 123
               %cmp = icmp sgt i32 %a, 0
             i32 %a
             i32 %b
             i32 %c
BB %if.end8
               %add = add nsw i32 %a, 123
               %cmp = icmp sgt i32 %a, 0
             i32 %a
             i32 %b
             i32 %c
BB %if.then2
               %mul = mul nsw i32 %b, %a
               %div = sdiv i32 %b, %c
               %cmp1 = icmp eq i32 %mul, %div
               %add = add nsw i32 %a, 123
               %cmp = icmp sgt i32 %a, 0
             i32 %a
             i32 %b
             i32 %c
BB %if.else
               %mul = mul nsw i32 %b, %a
               %div = sdiv i32 %b, %c
               %cmp1 = icmp eq i32 %mul, %div
               %add = add nsw i32 %a, 123
               %cmp = icmp sgt i32 %a, 0
             i32 %a
             i32 %b
             i32 %c

Note the extra command line option above: -analyze. It's required to inform opt to print the results of the analysis to stdout. We discussed this option in more detail here.

DuplicateBB

This pass will duplicate all basic blocks in a module, with the exception of basic blocks for which there are no reachable integer values (identified through the RIV pass). An example of such a basic block is the entry block in a function that:

  • takes no arguments and
  • is embedded in a module that defines no global values.

Basic blocks are duplicated by first inserting an if-then-else construct and then cloning all the instructions from the original basic block (with the exception of PHI nodes) into two new basic blocks (clones of the original basic block). The if-then-else construct is introduced as a non-trivial mechanism that decides which of the cloned basic blocks to branch to. This condition is equivalent to:

if (var == 0)
  goto clone 1
else
  goto clone 2

in which:

  • var is a randomly picked variable from the RIV set for the current basic block
  • clone 1 and clone 2 are labels for the cloned basic blocks.

The complete transformation looks like this:

BEFORE:                     AFTER:
-------                     ------
                              [ if-then-else ]
             DuplicateBB           /  \
[ BB ]      ------------>   [clone 1] [clone 2]
                                   \  /
                                 [ tail ]

LEGEND:
-------
[BB]           - the original basic block
[if-then-else] - a new basic block that contains the if-then-else statement (inserted by DuplicateBB)
[clone 1|2]    - two new basic blocks that are clones of BB (inserted by DuplicateBB)
[tail]         - the new basic block that merges [clone 1] and [clone 2] (inserted by DuplicateBB)

As depicted above, DuplicateBB replaces qualifying basic blocks with 4 new basic blocks. This is implemented through LLVM's SplitBlockAndInsertIfThenElse. DuplicateBB does all the necessary preparation and clean-up. In other words, it's an elaborate wrapper for LLVM's SplitBlockAndInsertIfThenElse.

Run the pass

This pass depends on the RIV pass, which also needs be loaded in order for DuplicateBB to work. Lets use input_for_duplicate_bb.c as our sample input. First, generate the LLVM file:

export LLVM_DIR=<installation/dir/of/llvm/11>
$LLVM_DIR/bin/clang -emit-llvm -S -O1 <source_dir>/inputs/input_for_duplicate_bb.c -o input_for_duplicate_bb.ll

Function foo in input_for_duplicate_bb.ll should look like this (all metadata has been stripped):

define i32 @foo(i32) {
  ret i32 1
}

Note that there's only one basic block (the entry block) and that foo takes one argument (this means that the result from RIV will be a non-empty set). We will now apply DuplicateBB to foo:

$LLVM_DIR/bin/opt -load <build_dir>/lib/libRIV.so -load <build_dir>/lib/libDuplicateBB.so -legacy-duplicate-bb -S input_for_duplicate_bb.ll -o duplicate.ll

After the instrumentation foo will look like this (all metadata has been stripped):

define i32 @foo(i32) {
lt-if-then-else-0:
  %2 = icmp eq i32 %0, 0
  br i1 %2, label %lt-if-then-0, label %lt-else-0

clone-1-0:
  br label %lt-tail-0

clone-2-0:
  br label %lt-tail-0

lt-tail-0:
  ret i32 1
}

There are four basic blocks instead of one. All new basic blocks end with a numeric id of the original basic block (0 in this case). lt-if-then-else-0 contains the new if-then-else condition. clone-1-0 and clone-2-0 are clones of the original basic block in foo. lt-tail-0 is the extra basic block that's required to merge clone-1-0 and clone-2-0.

MergeBB

MergeBB will merge qualifying basic blocks that are identical. To some extent, this pass reverts the transformations introduced by DuplicateBB. This is illustrated below:

BEFORE:                     AFTER DuplicateBB:                 AFTER MergeBB:
-------                     ------------------                 --------------
                              [ if-then-else ]                 [ if-then-else* ]
             DuplicateBB           /  \               MergeBB         |
[ BB ]      ------------>   [clone 1] [clone 2]      -------->    [ clone ]
                                   \  /                               |
                                 [ tail ]                         [ tail* ]

LEGEND:
-------
[BB]           - the original basic block
[if-then-else] - a new basic block that contains the if-then-else statement (**DuplicateBB**)
[clone 1|2]    - two new basic blocks that are clones of BB (**DuplicateBB**)
[tail]         - the new basic block that merges [clone 1] and [clone 2] (**DuplicateBB**)
[clone]        - [clone 1] and [clone 2] after merging, this block should be very similar to [BB] (**MergeBB**)
[label*]       - [label] after being updated by **MergeBB**

Recall that DuplicateBB replaces all qualifying basic block with four new basic blocks, two of which are clones of the original block. MergeBB will merge those two clones back together, but it will not remove the remaining two blocks added by DuplicateBB (it will update them though).

Run the pass

Lets use the following IR implementation of foo as input. Note that basic blocks 3 and 5 are identical and can safely be merged:

define i32 @foo(i32) {
  %2 = icmp eq i32 %0, 19
  br i1 %2, label %3, label %5

; 
  %4 = add i32 %0,  13
  br label %7

; 
  %6 = add i32 %0,  13
  br label %7

; 
  %8 = phi i32 [ %4, %3 ], [ %6, %5 ]
  ret i32 %8
}

We will now apply MergeBB to foo:

$LLVM_DIR/bin/opt -load <build_dir>/lib/libMergeBB.so -legacy-merge-bb -S foo.ll -o merge.ll

After the instrumentation foo will look like this (all metadata has been stripped):

define i32 @foo(i32) {
  %2 = icmp eq i32 %0, 19
  br i1 %2, label %3, label %3

3:
  %4 = add i32 %0, 13
  br label %5

5:
  ret i32 %4
}

As you can see, basic blocks 3 and 5 from the input module have been merged into one basic block.

Run MergeBB on the output from DuplicateBB

It is really interesting to see the effect of MergeBB on the output from DuplicateBB. Lets start with the same input as we used for DuplicateBB:

export LLVM_DIR=<installation/dir/of/llvm/11>
$LLVM_DIR/bin/clang -emit-llvm -S -O1 <source_dir>/inputs/input_for_duplicate_bb.c -o input_for_duplicate_bb.ll

Now we will apply DuplicateBB and MergeBB (in this order) to foo. Recall that DuplicateBB requires RIV, which means that in total we have to load three plugins:

$LLVM_DIR/bin/opt -load-pass-plugin <build_dir>/lib/libRIV.so -load-pass-plugin <build_dir>/lib/libMergeBB.so -load-pass-plugin <build-dir>/lib/libDuplicateBB.so -passes=duplicate-bb,merge-bb -S input_for_duplicate_bb.ll -o merge_after_duplicate.ll

And here's the output:

define i32 @foo(i32) {
lt-if-then-else-0:
  %1 = icmp eq i32 %0, 0
  br i1 %1, label %lt-clone-2-0, label %lt-clone-2-0

lt-clone-2-0:
  br label %lt-tail-0

lt-tail-0:
  ret i32 1
}

Compare this with the output generated by DuplicateBB. Only one of the clones, lt-clone-2-0, has been preserved, and lt-if-then-else-0 has been updated accordingly. Regardless of the value of of the if condition (more precisely, variable %1), the control flow jumps to lt-clone-2-0.

FindFCmpEq

The FindFCmpEq pass finds all floating-point comparison operations that directly check for equality between two values. This is important because these sorts of comparisons can sometimes be indicators of logical issues due to rounding errors inherent in floating-point arithmetic.

FindFCmpEq is implemented as two passes: an analysis pass (FindFCmpEq) and a printing pass (FindFCmpEqPrinter). The legacy implementation (FindFCmpEqWrapper) makes use of both of these passes.

Run the pass

We will use input_for_fcmp_eq.ll to test FindFCmpEq:

" input_for_fcmp_eq.ll ">
export LLVM_DIR=<installation/dir/of/llvm/11>
# Generate the input file
$LLVM_DIR/bin/clang -emit-llvm -S -c <source_dir>/inputs/input_for_fcmp_eq.c -o input_for_fcmp_eq.ll
# Run the pass
$LLVM_DIR/bin/opt --load-pass-plugin <build_dir>/lib/libFindFCmpEq.so --passes="print" input_for_fcmp_eq.ll

For the legacy implementation, the opt command would be changed to the following:

$LLVM_DIR/bin/opt -load <build_dir>/lib/libFindFCmpEq.so -find-fcmp-eq -analyze input_for_fcmp_eq.ll

In either case, you should see the following output which lists the direct floating-point equality comparison instructions found:

Floating-point equality comparisons in "sqrt_impl":
  %cmp = fcmp oeq double %0, %1
Floating-point equality comparisons in "compare_fp_values":
  %cmp = fcmp oeq double %0, %1

ConvertFCmpEq

The ConvertFCmpEq pass is a transformation that uses the analysis results of FindFCmpEq to convert direct floating-point equality comparison instructions into logically equivalent ones that use a pre-calculated rounding threshold.

Run the pass

As with FindFCmpEq, we will use input_for_fcmp_eq.ll to test ConvertFCmpEq:

export LLVM_DIR=<installation/dir/of/llvm/11>
$LLVM_DIR/bin/clang -emit-llvm -S -Xclang -disable-O0-optnone \
  -c <source_dir>/inputs/input_for_fcmp_eq.c -o input_for_fcmp_eq.ll
$LLVM_DIR/bin/opt --load-pass-plugin <build_dir>/lib/libFindFCmpEq.so \
  --load-pass-plugin <build_dir>/lib/libConvertFCmpEq.so \
  --passes=convert-fcmp-eq -S input_for_fcmp_eq.ll -o fcmp_eq_after_conversion.ll

For the legacy implementation, the opt command would be changed to the following:

$LLVM_DIR/bin/opt -load <build_dir>/lib/libFindFCmpEq.so \
  <build_dir>/lib/libConvertFCmpEq.so -convert-fcmp-eq \
  -S input_for_fcmp_eq.ll -o fcmp_eq_after_conversion.ll

Notice that both libFindFCmpEq.so and libConvertFCmpEq.so must be loaded -- and the load order matters. Since ConvertFCmpEq requires FindFCmpEq, its library must be loaded before ConvertFCmpEq. If both passes were built as part of the same library, this would not be required.

After transformation, both fcmp oeq instructions will have been converted to difference based fcmp olt instructions using the IEEE 754 double-precision machine epsilon constant as the round-off threshold:

  %cmp = fcmp oeq double %0, %1

... has now become

  %3 = fsub double %0, %1
  %4 = bitcast double %3 to i64
  %5 = and i64 %4, 9223372036854775807
  %6 = bitcast i64 %5 to double
  %cmp = fcmp olt double %6, 0x3CB0000000000000

The values are subtracted from each other and the absolute value of their difference is calculated. If this absolute difference is less than the value of the machine epsilon, the original two floating-point values are considered to be equal.

Debugging

Before running a debugger, you may want to analyze the output from LLVM_DEBUG and STATISTIC macros. For example, for MBAAdd:

export LLVM_DIR=<installation/dir/of/llvm/11>
$LLVM_DIR/bin/clang -emit-llvm -S -O1 <source_dir>/inputs/input_for_mba.c -o input_for_mba.ll
$LLVM_DIR/bin/opt -S -load-pass-plugin <build_dir>/lib/libMBAAdd.so -passes=mba-add input_for_mba.ll -debug-only=mba-add -stats -o out.ll

Note the -debug-only=mba-add and -stats flags in the command line - that's what enables the following output:

  %12 = add i8 %1, %0 ->   <badref> = add i8 111, %11
  %20 = add i8 %12, %2 ->   <badref> = add i8 111, %19
  %28 = add i8 %20, %3 ->   <badref> = add i8 111, %27
===-------------------------------------------------------------------------===
                          ... Statistics Collected ...
===-------------------------------------------------------------------------===

3 mba-add - The # of substituted instructions

As you can see, you get a nice summary from MBAAdd. In many cases this will be sufficient to understand what might be going wrong. Note that for these macros to work you need a debug build of LLVM (i.e. opt) and llvm-tutor (i.e. use -DCMAKE_BUILD_TYPE=Debug instead of -DCMAKE_BUILD_TYPE=Release).

For tricker issues just use a debugger. Below I demonstrate how to debug MBAAdd. More specifically, how to set up a breakpoint on entry to MBAAdd::run. Hopefully that will be sufficient for you to start.

Mac OS X

The default debugger on OS X is LLDB. You will normally use it like this:

export LLVM_DIR=<installation/dir/of/llvm/11>
$LLVM_DIR/bin/clang -emit-llvm -S -O1 <source_dir>/inputs/input_for_mba.c -o input_for_mba.ll
lldb -- $LLVM_DIR/bin/opt -S -load-pass-plugin <build_dir>/lib/libMBAAdd.dylib -passes=mba-add input_for_mba.ll -o out.ll
(lldb) breakpoint set --name MBAAdd::run
(lldb) process launch

or, equivalently, by using LLDBs aliases:

export LLVM_DIR=<installation/dir/of/llvm/11>
$LLVM_DIR/bin/clang -emit-llvm -S -O1 <source_dir>/inputs/input_for_mba.c -o input_for_mba.ll
lldb -- $LLVM_DIR/bin/opt -S -load-pass-plugin <build_dir>/lib/libMBAAdd.dylib -passes=mba-add input_for_mba.ll -o out.ll
(lldb) b MBAAdd::run
(lldb) r

At this point, LLDB should break at the entry to MBAAdd::run.

Ubuntu

On most Linux systems, GDB is the most popular debugger. A typical session will look like this:

export LLVM_DIR=<installation/dir/of/llvm/11>
$LLVM_DIR/bin/clang -emit-llvm -S -O1 <source_dir>/inputs/input_for_mba.c -o input_for_mba.ll
gdb --args $LLVM_DIR/bin/opt -S -load-pass-plugin <build_dir>/lib/libMBAAdd.so -passes=mba-add input_for_mba.ll -o out.ll
(gdb) b MBAAdd.cpp:MBAAdd::run
(gdb) r

At this point, GDB should break at the entry to MBAAdd::run.

About Pass Managers in LLVM

LLVM is a quite complex project (to put it mildly) and passes lay at its center - this is true for any multi-pass compiler. In order to manage the passes, a compiler needs a pass manager. LLVM currently enjoys not one, but two pass managers. This is important because depending on which pass manager you decide to use, the implementation of your pass (and in particular how you register it) will look slightly differently.

Overview of Pass Managers in LLVM

As I mentioned earlier, there are two pass managers in LLVM:

  • Legacy Pass Manager which currently is the default pass manager
    • It is implemented in the legacy namespace
    • It is very well documented (more specifically, writing and registering a pass withing the Legacy PM is very well documented)
  • New Pass Manager aka Pass Manager (that's how it's referred to in the code base)
    • I understand that it is soon to become the default pass manager in LLVM
    • The source code is very throughly commented, but there is no official documentation. Min-Yih Hsu kindly wrote this great blog series that you can refer to instead.

If you are not sure which pass manager to use, it is probably best to make sure that your passes are compatible with both. Fortunately, once you have an implementation that works with one of them, it's relatively straightforward to extend it so that it works with the other one as well.

New vs Legacy PM When Running Opt

MBAAdd implements interface for both pass managers. This is how you will use it with the legacy pass manager:

$LLVM_DIR/bin/opt -S -load <build_dir>/lib/libMBAAdd.so -legacy-mba-add input_for_mba.ll -o out.ll

And this is how you run it with the new pass manager:

$LLVM_DIR/bin/opt -S -load-pass-plugin <build_dir>/lib/libMBAAdd.so -passes=mba-add input_for_mba.ll -o out.ll

There are two differences:

  • the way you load your plugin: -load vs -load-pass-plugin
  • the way you specify which pass/plugin to run: -legacy-mba-add vs -passes=mba-add

These differences stem from the fact that in the case of Legacy Pass Manager you register a new command line option for opt, whereas New Pass Manager simply requires you to define a pass pipeline (with -passes=).

Analysis vs Transformation Pass

The implementation of a pass depends on whether it is an Analysis or a Transformation pass. The difference in the API that you will use is often subtle and further differs between the pass managers.

For example, for the New Pass Manager:

This is one of the key characteristics of the New Pass Managers - it makes the split into Analysis and Transformation passes very explicit. An Analysis pass requires a bit more bookkeeping and hence a bit more code. For example, you need to add an instance of AnalysisKey so that it can be identified by the New Pass Manager.

In the case of the Legacy Pass Manager, an Analysis pass is required to implement the print method. But otherwise, the API splits passes based on the unit of IR they operate on, e.g. ModulePass vs FunctionPass. This is one of the main differences between the pass managers in LLVM.

Note that for small standalone examples, the difference between Analysis and Transformation passes becomes less relevant. HelloWorld is a good example. It does not transform the input module, so in practice it is an Analysis pass. However, in order to keep the implementation as simple as possible, I used the API for Transformation passes.

Within llvm-tutor the following passes can be used as reference Analysis and Transformation examples:

Other examples also adhere to LLVM's convention, but contain other complexities. Only in the case of HelloWorld simplicity was favoured over strictness.

Printing passes for the new pass manager

You might have noticed that some passes implement the print member method. This method is used by the Legacy Pass Manager to print the results of the corresponding Analysis pass. You can run it by passing the -analyze command line option when using opt. Interestingly, nothing of this sort is available in the New Pass Manager. Instead, you just implement a printing pass.

A printing pass for an Analysis pass is basically a Transformation pass that:

  • requests the results of the analysis from the original pass
  • prints these results.

In other words, it's just a wrapper pass. There's a convention to register such passes under the print command line option.

Dynamic vs Static Plugins

By default, all examples in llvm-tutor are built as dynamic plugins. However, LLVM provides infrastructure for both dynamic and static plugins ( documentation). Static plugins are simply libraries linked into your executable (e.g. opt) statically. This way, unlike dynamic plugins, they don't require to be loaded at runtime with either -load or -load-pass-plugin options.

Static plugins are normally developed in-tree, i.e. within llvm-project/llvm, and all examples in llvm-tutor can be adapted to work this way. You can use static_registation.sh to see it can be done for MBASub. This script will:

  • copy the required source and test files into llvm-project/llvm
  • adapt in-tree CMake scripts so that the in-tree version of MBASub is actually built
  • remove -load and -load-pass-plugin from the in-tree tests for MBASub

Note that this script will modify llvm-project/llvm, but leave llvm-tutor intact. After running the script you will have to re-build opt. Two additional CMake flags have to be set: LLVM_BUILD_EXAMPLES and LLVM_MBASUB_LINK_INTO_TOOLS:

# LLVM_TUTOR_DIR: directory in which you cloned llvm-tutor
cd $LLVM_TUTOR_DIR
# LLVM_PROJECT_DIR: directory in which you cloned llvm-project
bash utils/static_registration.sh --llvm_project_dir $LLVM_PROJECT_DIR
# LLVM_BUILD_DIR: directory in which you previously built opt
cd $LLVM_BUILD_DIR
cmake -DLLVM_BUILD_EXAMPLES=On -DLLVM_MBASUB_LINK_INTO_TOOLS=On .
cmake --build . --target opt

Once opt is re-built, MBASub will be statically linked into opt. Now you can run it like this:

$LLVM_BUILD_DIR/bin/opt --passes=mba-sub -S $LLVM_TUTOR_DIR/test/MBA_sub.ll

Note that this time we didn't have to use -load-pass-plugin (or -load) to load MBASub. If you want to dive deeper into the required steps for static registration, you can scan static_registation.sh or run:

cd $LLVM_PROJECT_DIR
git diff
git status

This will print all the changes within llvm-project/llvm introduced by the script.

Optimisation Passes Inside LLVM

Apart from writing your own transformations an analyses, you may want to familiarize yourself with the passes available within LLVM. It is a great resource for learning how LLVM works and what makes it so powerful and successful. It is also a great resource for discovering how compilers work in general. Indeed, many of the passes implement general concepts known from the theory of compiler development.

The list of the available passes in LLVM can be a bit daunting. Below is a list of the selected few that are a good starting point. Each entry contains a link to the implementation in LLVM, a short description and a link to test files available within llvm-tutor. These test files contain a collection of annotated test cases for the corresponding pass. The goal of these tests is to demonstrate the functionality of the tested pass through relatively simple examples.

Name Description Test files in llvm-tutor
dce Dead Code Elimination dce.ll
memcpyopt Optimise calls to memcpy (e.g. replace them with memset) memcpyopt.ll
reassociate Reassociate (e.g. 4 + (x + 5) -> x + (4 + 5)). This enables further optimisations, e.g. LICM. reassociate.ll
always-inline Always inlines functions decorated with alwaysinline always-inline.ll
loop-deletion Delete unused loops loop-deletion.ll
licm Loop-Invariant Code Motion (a.k.a. LICM) licm.ll
slp Superword-level parallelism vectorisation slp_x86.ll, slp_aarch64.ll

This list focuses on LLVM's transform passes that are relatively easy to demonstrate through small, standalone examples. You can ran an individual test like this:

lit <source/dir/llvm/tutor>/test/llvm/always-inline.ll

To run an individual pass, extract one RUN line from the test file and run it:

$LLVM_DIR/bin/opt -inline-threshold=0 -always-inline -S <source/dir/llvm/tutor>/test/llvm/always-inline.ll

References

Below is a list of LLVM resources available outside the official online documentation that I have found very helpful. Where possible, the items are sorted by date.

  • LLVM IR
    • ”LLVM IR Tutorial-Phis,GEPs and other things, ohmy!”, V.Bridgers, F. Piovezan, EuroLLVM, (slides, video)
    • "Mapping High Level Constructs to LLVM IR", M. Rodler (link)
  • Examples in LLVM
  • LLVM Pass Development
    • "Writing an LLVM Optimization", Jonathan Smith video
    • "Getting Started With LLVM: Basics ", J. Paquette, F. Hahn, LLVM Dev Meeting 2019 video
    • "Writing an LLVM Pass: 101", A. Warzyński, LLVM Dev Meeting 2019 video
    • "Writing LLVM Pass in 2018", Min-Yih Hsu blog
    • "Building, Testing and Debugging a Simple out-of-tree LLVM Pass" Serge Guelton, Adrien Guinet, LLVM Dev Meeting 2015 (slides, video)
  • Legacy vs New Pass Manager
    • "New PM: taming a custom pipeline of Falcon JIT", F. Sergeev, EuroLLVM 2018 (slides, video)
    • "The LLVM Pass Manager Part 2", Ch. Carruth, LLVM Dev Meeting 2014 (slides, video)
    • ”Passes in LLVM, Part 1”, Ch. Carruth, EuroLLVM 2014 (slides, video)
  • LLVM Based Tools Development
    • "Introduction to LLVM", M. Shah, Fosdem 2018, link
    • "Building an LLVM-based tool. Lessons learned", A. Denisov, blog, video

Credits

This is first and foremost a community effort. This project wouldn't be possible without the amazing LLVM online documentation, the plethora of great comments in the source code, and the llvm-dev mailing list. Thank you!

It goes without saying that there's plenty of great presentations on YouTube, blog posts and GitHub projects that cover similar subjects. I've learnt a great deal from them - thank you all for sharing! There's one presentation/tutorial that has been particularly important in my journey as an aspiring LLVM developer and that helped to democratise out-of-source pass development:

  • "Building, Testing and Debugging a Simple out-of-tree LLVM Pass" Serge Guelton, Adrien Guinet (slides, video)

Adrien and Serge came up with some great, illustrative and self-contained examples that are great for learning and tutoring LLVM pass development. You'll notice that there are similar transformation and analysis passes available in this project. The implementations available here reflect what I (aka banach-space) found most challenging while studying them.

I also want to thank Min-Yih Hsu for his blog series "Writing LLVM Pass in 2018". It was invaluable in understanding how the new pass manager works and how to use it. Last, but not least I am very grateful to Nick Sunmer (e.g. llvm-demo) and Mike Shah (see Mike's Fosdem 2018 talk) for sharing their knowledge online. I have learnt a great deal from it, thank you! I always look-up to those of us brave and bright enough to work in academia - thank you for driving the education and research forward!

License

The MIT License (MIT)

Copyright (c) 2019 Andrzej Warzyński

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Issues
  • dynamic-cc instrumented prints nothing

    dynamic-cc instrumented prints nothing

    I'm using llvm 13.0.1 After being instrumented by dynamic-cc, running the program in lli prints nothing. But when I run the same program in lli 15.0.0, it prints as expected.

    Anybody experienced same issue?

    opened by YuuuuuuuuY 8
  • Add a function argument usage analysis pass

    Add a function argument usage analysis pass

    The idea is borrowed from the task 'Writing your own Analysis Pass', course 'CSCI565 Compilers Design' (see http://www.isi.edu/~pedro/Teaching/CSCI565-Spring15/Projects/Project1-LLVM/Project1-LLVM.pdf).

    The pass analyses function usages in an LLVM IR module and checks that the types of the parameters agree in type with those of the call instruction.

    The format of printing the errors the pass founds is as follows: Function 'X' call on line 'Y': argument type mismatch. Expected 'int' but argument is of type 'char'. (information about the line can be printed only if the debug locations are fount in the bitcode).

    The pass can be run with the new pass manager:

    $ opt -load-pass-plugin lib/libFunctionArgumentUsage.so -passes="fnargusage-user" -disable-output input_for_fnargusage.ll

    as well as with the legacy one:

    $ opt -load lib/libFunctionArgumentUsage.so --legacy-fnargusage -analyze -stats input_for_fnargusage.ll

    The pass is designed in a way that let to the pass display debug information about the analysis process. To enable debug output, the pass should be run with the '--debug-only=ArgUsage' parameter:

    $ opt -load lib/libFunctionArgumentUsage.so -legacy-fnargusage -debug-pass=Structure --debug-only=ArgUsage -analyze input_for_fnargusage.ll

    Signed-off-by: Pavel Samolysov [email protected]

    opened by samolisov 8
  • Failed to load passes from 'libHelloWorld.so'. Request ignored.

    Failed to load passes from 'libHelloWorld.so'. Request ignored.

    Hello Andrzej,

    I built HelloWorld pass on macOS, and it worked fine, but I had a problem on Linux.

    The command I used:

    git clone https://github.com/llvm/llvm-project.git
    cd llvm-project
    git checkout release/10.x
    mkdir build
    cd build
    
    cmake -DLLVM_ENABLE_PROJECTS="clang" -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86 ../llvm
    cmake --build .
    
    export LLVM_DIR=$(pwd)
    
    git clone https://github.com/banach-space/llvm-tutor
    cd llvm-tutor
    export TUTOR_DIR=$(pwd)
    cd HelloWorld/
    mkdir build
    cd build
    
    cmake -DLT_LLVM_INSTALL_DIR=$LLVM_DIR ../
    make
    
    $LLVM_DIR/bin/clang -S -emit-llvm $TUTOR_DIR/inputs/input_for_hello.c -o input_for_hello.ll
    
    $LLVM_DIR/bin/opt -load-pass-plugin libHelloWorld.so -passes=hello-world -disable-output input_for_hello.ll
    

    The error from opt:

    Failed to load passes from 'libHelloWorld.so'. Request ignored.
    /home/amir/llvm-project/build/bin/opt: unknown pass name 'hello-world'
    

    Thanks, Amir

    opened by ghost 7
  • DynamicCounterCall.cpp fails if indrect call is used (function pointer)

    DynamicCounterCall.cpp fails if indrect call is used (function pointer)

    Hi @banach-space, this is my question, I think it is not really a bug.

    I would like to know why GlobalValue::CommonLinkage is used insead of GlobalValue::ExternalLinkage when creating a global variable. It seems work well if I use GlobalValue::ExternalLinkage.

    I made some changes to the input_for_cc.c and here is my code. It has an indirect function call.

    void foo() { }
    void bar() {foo(); }
    void fez() {bar(); }
    
    int main() {
      foo();
      bar();
      fez();
    
      void (*p) () = &foo; 
      p(); 
    
      int ii = 0;
      for (ii = 0; ii < 10; ii++)
        foo();
    
      return 0;
    }
    

    I found that the pass DynamicCounterCall.cpp would fail in this scenario. And here is the report generated by LLVM

    Assertion failed: (!isZeroFill() && "Adding edge to zero-fill block?"), function addEdge, file JITLink.h, line 301.
    PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
    Stack dump:
    0.	Program arguments: lli instrument_bin
    Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
    0  lli                      0x000000010a1151dd llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 61
    1  lli                      0x000000010a11571b PrintStackTraceSignalHandler(void*) + 27
    2  lli                      0x000000010a11357f llvm::sys::RunSignalHandlers() + 127
    3  lli                      0x000000010a11729f SignalHandler(int) + 223
    4  libsystem_platform.dylib 0x00007ff81be79e2d _sigtramp + 29
    5  libsystem_platform.dylib 0x00007fc0c605f830 _sigtramp + 18446743836045498912
    6  libsystem_c.dylib        0x00007ff81bdb0d10 abort + 123
    7  libsystem_c.dylib        0x00007ff81bdb00be err + 0
    8  lli                      0x0000000109804325 llvm::jitlink::Block::addEdge(unsigned char, unsigned int, llvm::jitlink::Symbol&, long long) + 117
    9  lli                      0x00000001092c89da llvm::jitlink::EHFrameEdgeFixer::processFDE(llvm::jitlink::EHFrameEdgeFixer::ParseContext&, llvm::jitlink::Block&, unsigned long, unsigned long, unsigned long, unsigned int, llvm::DenseMap<unsigned int, llvm::jitlink::EHFrameEdgeFixer::EdgeTarget, llvm::DenseMapInfo<unsigned int, void>, llvm::detail::DenseMapPair<unsigned int, llvm::jitlink::EHFrameEdgeFixer::EdgeTarget> >&) + 3882
    10 lli                      0x00000001092c6876 llvm::jitlink::EHFrameEdgeFixer::processBlock(llvm::jitlink::EHFrameEdgeFixer::ParseContext&, llvm::jitlink::Block&) + 2550
    11 lli                      0x00000001092c5953 llvm::jitlink::EHFrameEdgeFixer::operator()(llvm::jitlink::LinkGraph&) + 1171
    12 lli                      0x00000001093ad365 decltype(std::__1::forward<llvm::jitlink::EHFrameEdgeFixer&>(fp)(std::__1::forward<llvm::jitlink::LinkGraph&>(fp0))) std::__1::__invoke<llvm::jitlink::EHFrameEdgeFixer&, llvm::jitlink::LinkGraph&>(llvm::jitlink::EHFrameEdgeFixer&, llvm::jitlink::LinkGraph&) + 69
    13 lli                      0x00000001093ad2f5 llvm::Error std::__1::__invoke_void_return_wrapper<llvm::Error, false>::__call<llvm::jitlink::EHFrameEdgeFixer&, llvm::jitlink::LinkGraph&>(llvm::jitlink::EHFrameEdgeFixer&, llvm::jitlink::LinkGraph&) + 69
    14 lli                      0x00000001093ad2a5 std::__1::__function::__alloc_func<llvm::jitlink::EHFrameEdgeFixer, std::__1::allocator<llvm::jitlink::EHFrameEdgeFixer>, llvm::Error (llvm::jitlink::LinkGraph&)>::operator()(llvm::jitlink::LinkGraph&) + 69
    15 lli                      0x00000001093ac084 std::__1::__function::__func<llvm::jitlink::EHFrameEdgeFixer, std::__1::allocator<llvm::jitlink::EHFrameEdgeFixer>, llvm::Error (llvm::jitlink::LinkGraph&)>::operator()(llvm::jitlink::LinkGraph&) + 68
    16 lli                      0x00000001092fc93d std::__1::__function::__value_func<llvm::Error (llvm::jitlink::LinkGraph&)>::operator()(llvm::jitlink::LinkGraph&) const + 93
    17 lli                      0x00000001092f7510 std::__1::function<llvm::Error (llvm::jitlink::LinkGraph&)>::operator()(llvm::jitlink::LinkGraph&) const + 64
    18 lli                      0x00000001092f4f49 llvm::jitlink::JITLinkerBase::runPasses(std::__1::vector<std::__1::function<llvm::Error (llvm::jitlink::LinkGraph&)>, std::__1::allocator<std::__1::function<llvm::Error (llvm::jitlink::LinkGraph&)> > >&) + 153
    19 lli                      0x00000001092f4b45 llvm::jitlink::JITLinkerBase::linkPhase1(std::__1::unique_ptr<llvm::jitlink::JITLinkerBase, std::__1::default_delete<llvm::jitlink::JITLinkerBase> >) + 165
    20 lli                      0x0000000109337842 void llvm::jitlink::JITLinker<llvm::jitlink::MachOJITLinker_x86_64>::link<std::__1::unique_ptr<llvm::jitlink::JITLinkContext, std::__1::default_delete<llvm::jitlink::JITLinkContext> >, std::__1::unique_ptr<llvm::jitlink::LinkGraph, std::__1::default_delete<llvm::jitlink::LinkGraph> >, llvm::jitlink::PassConfiguration>(std::__1::unique_ptr<llvm::jitlink::JITLinkContext, std::__1::default_delete<llvm::jitlink::JITLinkContext> >&&, std::__1::unique_ptr<llvm::jitlink::LinkGraph, std::__1::default_delete<llvm::jitlink::LinkGraph> >&&, llvm::jitlink::PassConfiguration&&) + 130
    21 lli                      0x00000001093374f8 llvm::jitlink::link_MachO_x86_64(std::__1::unique_ptr<llvm::jitlink::LinkGraph, std::__1::default_delete<llvm::jitlink::LinkGraph> >, std::__1::unique_ptr<llvm::jitlink::JITLinkContext, std::__1::default_delete<llvm::jitlink::JITLinkContext> >) + 968
    22 lli                      0x000000010931c10e llvm::jitlink::link_MachO(std::__1::unique_ptr<llvm::jitlink::LinkGraph, std::__1::default_delete<llvm::jitlink::LinkGraph> >, std::__1::unique_ptr<llvm::jitlink::JITLinkContext, std::__1::default_delete<llvm::jitlink::JITLinkContext> >) + 206
    23 lli                      0x00000001092e3ff0 llvm::jitlink::link(std::__1::unique_ptr<llvm::jitlink::LinkGraph, std::__1::default_delete<llvm::jitlink::LinkGraph> >, std::__1::unique_ptr<llvm::jitlink::JITLinkContext, std::__1::default_delete<llvm::jitlink::JITLinkContext> >) + 128
    24 lli                      0x000000010991794f llvm::orc::ObjectLinkingLayer::emit(std::__1::unique_ptr<llvm::orc::MaterializationResponsibility, std::__1::default_delete<llvm::orc::MaterializationResponsibility> >, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >) + 463
    25 lli                      0x000000010994fed4 llvm::orc::ObjectTransformLayer::emit(std::__1::unique_ptr<llvm::orc::MaterializationResponsibility, std::__1::default_delete<llvm::orc::MaterializationResponsibility> >, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >) + 484
    26 lli                      0x00000001098447d7 llvm::orc::IRCompileLayer::emit(std::__1::unique_ptr<llvm::orc::MaterializationResponsibility, std::__1::default_delete<llvm::orc::MaterializationResponsibility> >, llvm::orc::ThreadSafeModule) + 503
    27 lli                      0x0000000109847120 llvm::orc::IRTransformLayer::emit(std::__1::unique_ptr<llvm::orc::MaterializationResponsibility, std::__1::default_delete<llvm::orc::MaterializationResponsibility> >, llvm::orc::ThreadSafeModule) + 352
    28 lli                      0x0000000109847120 llvm::orc::IRTransformLayer::emit(std::__1::unique_ptr<llvm::orc::MaterializationResponsibility, std::__1::default_delete<llvm::orc::MaterializationResponsibility> >, llvm::orc::ThreadSafeModule) + 352
    29 lli                      0x000000010986b6e7 llvm::orc::BasicIRLayerMaterializationUnit::materialize(std::__1::unique_ptr<llvm::orc::MaterializationResponsibility, std::__1::default_delete<llvm::orc::MaterializationResponsibility> >) + 471
    30 lli                      0x0000000109719c88 llvm::orc::MaterializationTask::run() + 72
    31 lli                      0x0000000109719ee2 llvm::orc::ExecutionSession::runOnCurrentThread(std::__1::unique_ptr<llvm::orc::Task, std::__1::default_delete<llvm::orc::Task> >) + 18
    32 lli                      0x0000000109757be2 void llvm::detail::UniqueFunctionBase<void, std::__1::unique_ptr<llvm::orc::Task, std::__1::default_delete<llvm::orc::Task> > >::CallImpl<void (*)(std::__1::unique_ptr<llvm::orc::Task, std::__1::default_delete<llvm::orc::Task> >)>(void*, std::__1::unique_ptr<llvm::orc::Task, std::__1::default_delete<llvm::orc::Task> >&) + 66
    33 lli                      0x00000001097222a7 llvm::unique_function<void (std::__1::unique_ptr<llvm::orc::Task, std::__1::default_delete<llvm::orc::Task> >)>::operator()(std::__1::unique_ptr<llvm::orc::Task, std::__1::default_delete<llvm::orc::Task> >) + 55
    34 lli                      0x0000000109709ee5 llvm::orc::ExecutionSession::dispatchTask(std::__1::unique_ptr<llvm::orc::Task, std::__1::default_delete<llvm::orc::Task> >) + 245
    35 lli                      0x000000010971b576 llvm::orc::ExecutionSession::dispatchOutstandingMUs() + 566
    36 lli                      0x000000010971ea9c llvm::orc::ExecutionSession::OL_completeLookup(std::__1::unique_ptr<llvm::orc::InProgressLookupState, std::__1::default_delete<llvm::orc::InProgressLookupState> >, std::__1::shared_ptr<llvm::orc::AsynchronousSymbolQuery>, std::__1::function<void (llvm::DenseMap<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> >, llvm::DenseMapInfo<llvm::orc::JITDylib*, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> > > > const&)>) + 956
    37 lli                      0x0000000109779e74 llvm::orc::InProgressFullLookupState::complete(std::__1::unique_ptr<llvm::orc::InProgressLookupState, std::__1::default_delete<llvm::orc::InProgressLookupState> >) + 228
    38 lli                      0x000000010971090d llvm::orc::ExecutionSession::OL_applyQueryPhase1(std::__1::unique_ptr<llvm::orc::InProgressLookupState, std::__1::default_delete<llvm::orc::InProgressLookupState> >, llvm::Error) + 3901
    39 lli                      0x000000010970da5d llvm::orc::ExecutionSession::lookup(llvm::orc::LookupKind, std::__1::vector<std::__1::pair<llvm::orc::JITDylib*, llvm::orc::JITDylibLookupFlags>, std::__1::allocator<std::__1::pair<llvm::orc::JITDylib*, llvm::orc::JITDylibLookupFlags> > > const&, llvm::orc::SymbolLookupSet, llvm::orc::SymbolState, llvm::unique_function<void (llvm::Expected<llvm::DenseMap<llvm::orc::SymbolStringPtr, llvm::JITEvaluatedSymbol, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void>, llvm::detail::DenseMapPair<llvm::orc::SymbolStringPtr, llvm::JITEvaluatedSymbol> > >)>, std::__1::function<void (llvm::DenseMap<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> >, llvm::DenseMapInfo<llvm::orc::JITDylib*, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> > > > const&)>) + 381
    40 lli                      0x0000000109718fb8 llvm::orc::Platform::lookupInitSymbols(llvm::orc::ExecutionSession&, llvm::DenseMap<llvm::orc::JITDylib*, llvm::orc::SymbolLookupSet, llvm::DenseMapInfo<llvm::orc::JITDylib*, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib*, llvm::orc::SymbolLookupSet> > const&) + 952
    41 lli                      0x00000001098a2821 (anonymous namespace)::GenericLLVMIRPlatformSupport::issueInitLookups(llvm::orc::JITDylib&) + 305
    42 lli                      0x00000001098a1eae (anonymous namespace)::GenericLLVMIRPlatformSupport::getInitializers(llvm::orc::JITDylib&) + 78
    43 lli                      0x0000000109895bc7 (anonymous namespace)::GenericLLVMIRPlatformSupport::initialize(llvm::orc::JITDylib&) + 151
    44 lli                      0x00000001082fd965 llvm::orc::LLJIT::initialize(llvm::orc::JITDylib&) + 277
    45 lli                      0x00000001082f849f runOrcJIT(char const*) + 5359
    46 lli                      0x00000001082f4d96 main + 438
    47 dyld                     0x0000000118b5a4fe start + 462
    [1]    44361 abort      lli instrument_bin
    

    If I replace the GlobalValue::CommonLinkage with GlobalValue::ExternalLinkage, then DynamicCounterCall works well. Here is the result returned by the program.

    =================================================
    LLVM-TUTOR: dynamic analysis results
    =================================================
    NAME                 #N DIRECT CALLS
    -------------------------------------------------
    foo                  14
    bar                  2
    fez                  1
    main                 1
    
    opened by randoruf 6
  • cmake: specify 'SYSTEM' setting to disable warnings

    cmake: specify 'SYSTEM' setting to disable warnings

    https://cmake.org/cmake/help/latest/command/include_directories.html:

    If the SYSTEM option is given, the compiler will be told the directories are meant as system include directories on some platforms. Signalling this setting might achieve effects such as the compiler skipping warnings, or these fixed-install system files not being considered in dependency calculations - see compiler docs.

    opened by orestisfl 6
  • opt segmentation fault in macOS Catalina

    opt segmentation fault in macOS Catalina

    I use the macOS Catalina (10.15.2)

    After running:

    $LLVM_DIR/bin/opt -load-pass-plugin libHelloWorld.dylib -passes=hello-world -disable-output input_for_hello.ll 
    

    I got this:

    (llvm-tutor) Hello from: foo
    (llvm-tutor)   number of arguments: 1
    (llvm-tutor) Hello from: bar
    (llvm-tutor)   number of arguments: 2
    (llvm-tutor) Hello from: fez
    (llvm-tutor)   number of arguments: 3
    (llvm-tutor) Hello from: main
    (llvm-tutor)   number of arguments: 2
    Stack dump:
    0.	Program arguments: /usr/local/opt/llvm/bin/opt -load-pass-plugin libHelloWorld.dylib -passes=hello-world -disable-output input_for_hello.ll 
    0  opt                      0x000000010d2629c6 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
    1  opt                      0x000000010d262db8 SignalHandler(int) + 180
    2  libsystem_platform.dylib 0x00007fff63a9b42d _sigtramp + 29
    3  libsystem_platform.dylib 000000000000000000 _sigtramp + 18446603338844097520
    4  opt                      0x000000010cf31d05 llvm::object_deleter<llvm::SmallVector<std::__1::pair<llvm::PassManagerBuilder::ExtensionPointTy, std::__1::function<void (llvm::PassManagerBuilder const&, llvm::legacy::PassManagerBase&)> >, 8u> >::call(void*) + 19
    5  opt                      0x000000010d223805 llvm::llvm_shutdown() + 53
    6  opt                      0x000000010d20bb41 llvm::InitLLVM::~InitLLVM() + 15
    7  opt                      0x000000010c0afc5a main + 10025
    8  libdyld.dylib            0x00007fff638a27fd start + 1
    Segmentation fault: 11
    

    Do you know why I get the segfault?

    BTW, thanks a lot for this great tutorial!

    opened by unknown-unknown-unknown 6
  • Make HelloWorld pass required

    Make HelloWorld pass required

    HelloWorld pass was not printing anything for me. This PR makes the pass required, as I see many other example passes are required. Not really sure why HelloWorld pass is skipped, but I do know this change forces the pass to be run.

    archlinux [~/src/llvm-tutor]$ llvm-config --version
    13.0.1
    archlinux [~/src/llvm-tutor]$ uname -a
    Linux archlinux 5.16.12-arch1-1 #1 SMP PREEMPT Wed, 02 Mar 2022 12:22:51 +0000 x86_64 GNU/Linux
    
    opened by caojoshua 5
  • Add note about OptNone

    Add note about OptNone

    The registration with the new pass manager requires that OptNone is not present for functions. Make sure that clang-compiled BC files don't have OptNone.

    This explains the issues of https://github.com/banach-space/llvm-tutor/issues/33 and https://github.com/banach-space/llvm-tutor/issues/34

    opened by gannimo 5
  • how to generate LLVM IR files for a whole project?

    how to generate LLVM IR files for a whole project?

    Hello Thank you for your useful repository. I have a question about generating .ll files, you used this command:

    $LLVM_DIR/bin/clang -S -emit-llvm ../inputs/input_for_hello.c -o input_for_hello.ll
    

    The question is how to generate this for all source files of a project, also each file has some included header files. for example how to generate LLVM IR for all of the source files in Libgd? I have tried this way but the result was almost empty:

    $LLVM_DIR/clang -emit-llvm -S -O0 src/gd_tiff.c -o src/gd_tiff.ll
    

    Thank you very much.

    opened by meweez 4
  • Unable to load passes from libHelloWorld.so

    Unable to load passes from libHelloWorld.so

    Hi

    I have tried the recommended command line from #12 but I am still not able to load the .so file. The command line I used was

    $LLVM_DIR/bin/opt -load-pass-plugin ./libHelloWorld.so -passes=hello-world -disable-output input_for_helloworld.ll
    

    I am running on Ubuntu 2004 LTS in VirtualBox.

    $LLVM_DIR/bin/opt --version LLVM version 12.0.0-test Optimized build Default target: x86_64-unknown-linux-gnu Host CPU: haswell

    opened by localacct 4
  • opt: Unknown command line argument '-debug-only=mba-add'.

    opt: Unknown command line argument '-debug-only=mba-add'.

    I'm using macOS, and I install LLVM with brew.

    $ llvm-config --version
    10.0.0
    

    In debugging:

    Without -debug-only=mba-add -stats:

    opt -load-pass-plugin build/lib/libMBAAdd.dylib -passes=mba-add input_for_mba.ll -S -o input_for_mba.transformed.ll
    

    It generates input_for_mba.transformed.ll with no error/warning.

    However, with -debug-only=mba-add -stats:

    opt -load-pass-plugin build/lib/libMBAAdd.dylib -passes=mba-add -debug-only=mba-add -stats input_for_mba.ll -S -o input_for_mba.transformed.ll 
    

    Output:

    opt: Unknown command line argument '-debug-only=mba-add'.  Try: 'opt --help'
    opt: Did you mean '--debug-pass=mba-add'?
    

    When I used --debug-pass=mba-add:

    opt -load-pass-plugin build/lib/libMBAAdd.dylib -passes=mba-add input_for_mba.ll --debug-pass=mba-add -stats -S -o input_for_mba.transformed.ll 
    

    Output:

    opt: for the --debug-pass option: Cannot find option named 'mba-add'!
    
    opened by ghost 4
  • New examples

    New examples

    Hi! Thank you for creating such a useful resource to learn about LLVM!

    I have some questions about LLVM out-of-source development that you can probably answer

    1. Can I change a pipeline of optimizations passes from my own pass / plugin? If yes, can you please share some some docs about it or perhaps make an example?
    2. Can I forbid default LLVM passes to run on specific functions? If yes, how?

    Thank you in advance!

    opened by unterumarmung 3
  • How to add a plugin when compiling an entire codebase

    How to add a plugin when compiling an entire codebase

    Related

    • https://github.com/banach-space/llvm-tutor/issues/28
    • https://stackoverflow.com/questions/23130821/llvm-run-own-pass-automatically-with-clang?rq=1

    I am trying to instrument all function calls in an existing codebase.

    I don't want to have to modify existing makefile scripts too extensively.


    The solution is to use the legacy pass manager.

    clang++ -flegacy-pass-manager -Xclang -load -Xclang ./libmypass.so input.cpp
    

    It seems that the new pass manager doesn't allow this yet.

    You must take care to choose the correct extension point. See here are the extension points. See [here] (https://github.com/rdadolf/clangtool/blob/353b80061ce30c3062bbe4752dbaa2a1c84cc9c8/clangtool.cpp#L42-L49) for an explanation of which ones to use.


    This information should be added to the readme.md.

    opened by vjpr 1
  • llvm 14 support

    llvm 14 support

    Only one change necessary.

    Change: https://reviews.llvm.org/D107025

    https://github.com/banach-space/llvm-tutor/blob/main/lib/OpcodeCounter.cpp#L124

    - llvm::PassBuilder::OptimizationLevel
    + llvm::OptimizationLevel
    
    opened by vjpr 3
  • MBAAdd Example with new PM

    MBAAdd Example with new PM

    The MBAAdd pass has a custom command line option specified (-mba-ratio), which you show how to use with the legacy pass manager, but you don't show an example of how this is done with the new pass manager. I haven't been able to figure out how to use custom command line options with the new pass manager. Can you provide an example of this?

    opened by apwest 1
  • Building HelloWorld pass on windows under visual studio 2019

    Building HelloWorld pass on windows under visual studio 2019

    Hello, i build LLVM on windows under Visual Studio 2019 with the config like this:

    cmake -S llvm\llvm -B build -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_EXPORT_SYMBOLS_FOR_PLUGINS=On -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_TARGETS_TO_BUILD=X86 -Thost=x64

    C:\passes\december\HelloWorld>llvm-config --version
    14.0.0git
    

    now i download this tutor and want to compile it, i do:

    C:\passes\december\HelloWorld>cmake -Bbuild -DLT_LLVM_INSTALL_DIR="C:\Program Files (x86)\LLVM"
    -- Building for: Visual Studio 16 2019
    -- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19043.
    -- The C compiler identification is MSVC 19.29.30137.0
    -- The CXX compiler identification is MSVC 19.29.30137.0
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped
    -- Detecting C compile features
    -- Detecting C compile features - done
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped
    -- Detecting CXX compile features
    -- Detecting CXX compile features - done
    -- Configuring done
    CMake Error in CMakeLists.txt:
      IMPORTED_IMPLIB not set for imported target "opt" configuration "Debug".
    
    
    CMake Error in CMakeLists.txt:
      IMPORTED_IMPLIB not set for imported target "opt" configuration "Release".
    
    
    CMake Error in CMakeLists.txt:
      IMPORTED_IMPLIB not set for imported target "opt" configuration
      "MinSizeRel".
    
    
    CMake Error in CMakeLists.txt:
      IMPORTED_IMPLIB not set for imported target "opt" configuration
      "RelWithDebInfo".
    
    
    -- Generating done
    CMake Generate step failed.  Build files cannot be regenerated correctly.
    

    As you can see it produces weird result, i looked solution in this repository and found one suggestion to change CMakeLists.txt:

    add_llvm_library( HelloWorld SHARED BUILDTREE_ONLY
      HelloWorld.cpp
    
      DEPENDS
      intrinsics_gen
      PLUGIN_TOOL
      opt
      )
    

    Changed MODULE to SHARED works it produced build files

    cd build
    cmake --build . --config Release --target ALL_BUILD
    

    this produced HelloWorld.dll.

    Now i want to use this and do: opt -load-pass-plugin="C:\passes\december\HelloWorld\build\Release\HelloWorld.dll" -passes="hello-world" -disable-output Source.bc And get output

    C:\passes\hello>opt -load-pass-plugin="C:\passes\december\HelloWorld\build\Release\HelloWorld.dll" -passes="hello-world" -disable-output Source.bc
    Failed to load passes from 'C:\passes\december\HelloWorld\build\Release\HelloWorld.dll'. Request ignored.
    Expected<T> must be checked before access or destruction.
    Unchecked Expected<T> contained error:
    Plugin entry point not found in 'C:\passes\december\HelloWorld\build\Release\HelloWorld.dll'. Is this a legacy plugin?PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
    Stack dump:
    0.      Program arguments: opt -load-pass-plugin=C:\\passes\\december\\HelloWorld\\build\\Release\\HelloWorld.dll -passes=hello-world -disable-output Source.bc
    #0 0x00007ff71ae82935 C:\Program Files (x86)\LLVM\bin\opt.exe 0x1442935 (C:\Program Files (x86)\LLVM\bin\opt.exe+0x1442935)
    #1 0x00007ff71ae82935
    #2 0x00007ff71ae82935 (C:\Program Files (x86)\LLVM\bin\opt.exe+0x1442935)
    #3 0x00007ff884fc1881 C:\Program Files (x86)\LLVM\bin\opt.exe 0x78b21 C:\Program Files (x86)\LLVM\bin\opt.exe 0x7dd5c
    #4 0x00007ff884fc1881 C:\Program Files (x86)\LLVM\bin\opt.exe 0x8a7f0 C:\Program Files (x86)\LLVM\bin\opt.exe 0x1e0a600
    #5 0x00007ff884fc1881 (C:\Windows\System32\ucrtbase.dll+0x71881)
    #6 0x00007ff884fc2851 (C:\Windows\System32\ucrtbase.dll+0x72851)
    0x00007FF71AE82935 (0x00007974991A16CF 0x0000000000000076 0x0000000000000016 0x00007FF71AE82930), HandleAbort() + 0x5 bytes(s)
    0x00007FF884FC1881 (0x000001C9DC584301 0x0000000000000000 0x0000000000000000 0x000000500C58CEC0), raise() + 0x1E1 bytes(s)
    0x00007FF884FC2851 (0x0000005000000003 0x0000005000000003 0x0000000000000000 0x000001C9DC5A2DB0), abort() + 0x31 bytes(s)
    0x00007FF719AB8B21 (0x000001C9DC5A2DB0 0x000000500C58CFF0 0x0000000000000000 0x000001C9DC5A2DB0), [email protected][email protected]@[email protected]@@[email protected]@[email protected]@@Z() + 0x111 bytes(s)
    0x00007FF719ABDD5C (0x0000000000000000 0x0000000000000000 0x000000500C58E920 0x0000000000000000), [email protected][email protected]@[email protected]@[email protected]@[email protected]@[email protected][email protected]@[email protected]@[email protected]@[email protected]@[email protected]@[email protected][email protected]@[email protected]@[email protected]@[email protected][email protected]@[email protected]@[email protected]@@[email protected]@@[email protected][email protected]@[email protected]@[email protected]@[email protected][email protected]@[email protected]@[email protected]@@[email protected]@@@[email protected]@@[email protected]@[email protected]@AEAV?$Analys() + 0x28FC bytes(s)
    0x00007FF719ACA7F0 (0x0000000000000000 0x0000000000000000 0x000001C9DC554DA0 0x0000000000000000), [email protected][email protected]@[email protected]@@[email protected]@[email protected]@@Z() + 0x4780 bytes(s)
    0x00007FF71B84A600 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), [email protected]@@[email protected]@@[email protected]@[email protected]@@Z() + 0x1360 bytes(s)
    0x00007FF887597034 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), BaseThreadInitThunk() + 0x14 bytes(s)
    0x00007FF887882651 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), RtlUserThreadStart() + 0x21 bytes(s)
    

    I checked HelloWord.dll and main entry point is DllEntryPoint i assume i need llvmGetPassPluginInfo as exported function?? How do you get this to work

    help wanted 
    opened by Culpr0 1
Owner
Andrzej Warzyński
Compiler engineer. Mathematician in previous life. @_banach_space
Andrzej Warzyński
Collection of various algorithms in mathematics, machine learning, computer science, physics, etc implemented in C for educational purposes.

The Algorithms - C # {#mainpage} Overview The repository is a collection of open-source implementation of a variety of algorithms implemented in C and

The Algorithms 14.1k Aug 7, 2022
Collection of algorithms and data structures in C++ and Java

Collection of algorithms and data structures in C++ and Java

Andrei Navumenka 1.7k Aug 8, 2022
repo to house various LLVM based SIHFT passes for RISCV 32/64 soft error resilience

compas-ft-riscv COMPAS: Compiler-assisted Software-implemented Hardware Fault Tolerance implemented in LLVM passes for the RISC-V backend Repo to hous

EDA@TUM 2 Jan 10, 2022
A small self-contained alternative to readline and libedit

Linenoise A minimal, zero-config, BSD licensed, readline replacement used in Redis, MongoDB, and Android. Single and multi line editing mode with the

Salvatore Sanfilippo 3k Aug 11, 2022
A small self-contained alternative to readline and libedit that supports UTF-8 and Windows and is BSD licensed.

Linenoise Next Generation A small, portable GNU readline replacement for Linux, Windows and MacOS which is capable of handling UTF-8 characters. Unlik

ArangoDB 335 Jun 28, 2022
A small self-contained alternative to readline and libedit

Linenoise A minimal, zero-config, BSD licensed, readline replacement used in Redis, MongoDB, and Android. Single and multi line editing mode with the

Salvatore Sanfilippo 3k Aug 8, 2022
The Robotics Library (RL) is a self-contained C++ library for rigid body kinematics and dynamics, motion planning, and control.

Robotics Library The Robotics Library (RL) is a self-contained C++ library for rigid body kinematics and dynamics, motion planning, and control. It co

Robotics Library 593 Aug 7, 2022
A self-contained minimal library for interacting with Linux hot-plug events

libue Zero dependency minimal library for interacting with Linux hot-plug events. Installation Just drop the header file into your C project. Usage #i

QP Hou 21 Jul 3, 2022
Self-contained exploit for CVE-2021-4034 - Pkexec Local Privilege Escalation

PwnKit Self-contained exploit for CVE-2021-4034 - Pkexec Local Privilege Escalation Usage Should work out of the box on Linux distributions based on U

Oliver Lyak 584 Aug 9, 2022
A lightweight, self-contained library for gizmo editing commonly found in many game engines

This project is a lightweight, self-contained library for gizmo editing commonly found in many game engines. It includes mechanisms for manipulating 3d position, rotation, and scale. Implemented in C++11, the library does not perform rendering directly and instead provides a per-frame buffer of world-space triangles.

Dimitri Diakopoulos 371 Jul 26, 2022
Im3d is a small, self-contained library for immediate mode rendering of basic primitives

Im3d is a small, self-contained library for immediate mode rendering of basic primitives (points, lines, triangles), plus an immediate mode UI which provides 3d manipulation 'gizmos' and other tools. It is platform and graphics API agnostic and designed to be compatible with VR.

John Chapman 783 Aug 5, 2022
A simple typing tutor program

Open-Typer A simple typing tutor program, which aims for customizability (see Configuring), open source code and ease of use. Features Lessons consist

null 4 Jan 25, 2022
Separable Subsurface Scattering is a technique that allows to efficiently perform subsurface scattering calculations in screen space in just two passes.

Separable Subsurface Scattering Separable Subsurface Scattering is a technique that allows to efficiently perform subsurface scattering calculations i

Jorge Jimenez 525 Aug 8, 2022
Collection of C++ containers extracted from LLVM

lvc lvc is a set of C++ containers extracted form LLVM for an easier integration in external projects. To avoid any potential conflit, the llvm namesp

Benjamin Navarro 26 Apr 22, 2022
Dead simple C logging library contained in a single header (.h) file

Seethe Logging so simple, you only need to include a single header file. seethe supports 6 different log levels (DEBUG, INFO, NOTICE, WARNING, ERROR,

Jason Nguyen 27 May 9, 2022
ZT is a zig-contained library that automatically compiles+links ImGui, OpenGL, and GLFW into typed packages.

ZT is a zig-contained library that automatically compiles+links ImGui, OpenGL, and GLFW into typed packages. By zig contained I mean that ZT is intend

null 85 Aug 8, 2022
A personal collection of Windows CVE I have turned in to exploit source, as well as a collection of payloads I've written to be used in conjunction with these exploits.

This repository contains a personal collection of Windows CVE I have turned in to exploit source, as well as a collection of payloads I've written to

null 76 Aug 10, 2022
A self made free, open source internal cheat for Overwatch

Overwatch-Cheat A self made free, open source internal cheat for Overwatch How to use the Valorant Internal [+] - Download it, then compile the cheat

xEnething 5 Aug 3, 2022
A self made HWID Spoofer for Fortnite and Valorant. May also work in Warzone, Apex etc.

HWID-Spoofer A HWID-Spoofer made by me. Tested for Fortnite and Valorant. Really undetected in the moment How to use the Valorant Internal [+] - Downl

gupr0x4 12 Jun 6, 2022
yangwebrtc is a self-developed rtc architecture supporting Webrtc/Srt/Rtmp, including a variety of video and audio codecs and processing, etc.

YangWebrtc Overview yangwebrtc是一个自主研发的支持Webrtc/Srt/Rtmp的rtc架构,包含多种视音频编解码和处理等。 支持视频会议、高清录播直播、直播互动等多种视音频应用。 可用于远程教育、远程医疗、指挥调度、安防监控、影视录播、协同办公、直播互动等多种行业应用

null 301 Aug 5, 2022
The name is self explanatory.

Friday Night Funkin' - Psych Engine Engine originally used on Mind Games Mod, intended to be a fix for the vanilla version's many issues while keeping

maky 12 Feb 14, 2022
Self driving car with obstacle detection and avoidance

STM32F4-Self-Driving-Car-Mini-Project Self driving car with obstacle detection and avoidance Hardware STM32F401RE Dev Board HCSR04 ultrasonic sensor (

Olaoluwa Raji 2 Jan 6, 2022
Node running standalone on PC, with interface - self-containing all dependencies

GMD Node Windows Application It is the GMD Node App for Windows packaged in a simple "one-click" installer containing all necessary dependencies. We a

Geoma COOP 3 Jan 4, 2022
Hide a process,port,self under Linux using the ld_preload

vbackdoor 中文 Hide a process,port,self under Linux using the LD_PRELOAD rootkit. compile the library git clone https://github.com/veo/vbackdoor.git cd

veo 88 Aug 8, 2022
NeeDrop: Self-supervised Shape Representation from Sparse Point Clouds using Needle Dropping

NeeDrop: Self-supervised Shape Representation from Sparse Point Clouds using Needle Dropping by: Alexandre Boulch, Pierre-Alain Langlois, Gilles Puy a

valeo.ai 25 May 24, 2022
Driver leap - Self-sustainable fork of SteamVR driver for Leap Motion controller with updated vendor libraries

Driver Leap Self-sustainable fork of SteamVR driver for Leap Motion controller with updated vendor libraries Installation (for users) Install Ultralea

null 46 Jul 28, 2022
A collecton of generic reference counted data structures, tools to create compatible C style classes, and demo applications

The Offbrand library is a collection of reference counted generic data structures written in C for C. The library includes bash scripts to assist in t

Tyler Heck 82 Mar 4, 2022
CommonMark spec, with reference implementations in C and JavaScript

CommonMark CommonMark is a rationalized version of Markdown syntax, with a spec and BSD-licensed reference implementations in C and JavaScript. Try it

CommonMark 4.6k Aug 6, 2022
C++ standard library reference

Information This is source package for Cppreference C++ standard library reference documentation available at http://en.cppreference.com. If there is

Povilas Kanapickas 341 Jul 31, 2022