llvm

LLVM Backend : Replacing indirect jmps for x86 backend

让人想犯罪 __ 提交于 2019-12-05 22:12:43
I want to replace indirect jmp *(eax) instructions in the code to mov *(eax),ebx; jmp *ebx for the x86 executables. Before implementing this, i would like to make LLVM compiler, log an output every time it detects a jmp *(eax) instruction by adding some print statements. Then i want to move on to replacing the indirect sequence. From what i have seen from google searches and articles, i can probably achieve this by modifying the x86asmprinter in the llvm backend. But i am not sure how to go about it. Any help or reading would be appreciated. Note: My actual requirement deals with indirect

compiling with clang and plugin

佐手、 提交于 2019-12-05 19:43:53
clang supports plugins, and often this concept is used to build tools like static analysis and such. To start playing with it I took this example which prints all function names present in the target cpp file(s). I compiled the plugin running the following: clang++ -v -std=c++11 PrintFunctionNames.cpp \ $(llvm-config --cxxflags --ldflags) \ -o plugin.so -shared -Wl,-undefined,dynamic_lookup and then run it "by the book": clang++ \ -c main.cpp \ -Xclang -load \ -Xclang $PWD/plugin.so \ -Xclang -plugin \ -Xclang print-fns it works just fine: it prints the function names in main.cpp and exit

LLVM 3.4 linker errors on VS 2012

强颜欢笑 提交于 2019-12-05 19:05:37
I have built the LLVM 3.4 from source using Cmake. I referred to documentation for Getting Started with the LLVM System using Microsoft Visual Studio for the installation. I now want to use the LLVM in my own project. I have added the LLVM libraries in VS 2012 using the Properties -> C/C++ -> General . When I try to build my compiler, I get the following linker errors when I Build my project: 1>main.obj : error LNK2019: unresolved external symbol LLVMInitializeX86TargetInfo referenced in function "bool __cdecl llvm::InitializeNativeTarget(void)" (?InitializeNativeTarget@llvm@@YA_NXZ) 1>main

LLVM JIT speed up choices?

我只是一个虾纸丫 提交于 2019-12-05 18:00:11
问题 It's kind of subjective, but I'm having troubles getting LLVM JIT up to speed. Jitting large bodies of code take 50 times as much time as just interpreting them even with lazy compilation turned on. So I was wondering how can I speeding jitting up, what kind of settings I can use? Any other recommendations? 回答1: I am sorry to say that LLVM just isn't very fast as a JIT compiler, it is better as a AOT/static compiler. I have run into the same speed issues in my llvm-lua project. What I did was

Stringizing operator in C/C++

巧了我就是萌 提交于 2019-12-05 17:44:10
问题 I am trying to use the stringizing operator #, but I get the error stray ‘#’ in program . Here is how I am using it. #define STR "SOME_STRING" #define BM 8 #define NUM_OF_THREADS 8 #define VER_STR (STR #BM #NUM_THREADS) I expect to get SOME_STRING88 for VER_STR but instead get an error. What mistake am I doing? 回答1: You need to turn the numerical constants into a string. However, #BM is an error, since the syntax is only valid for macro parameters. So you need to force en expansion through an

Creating and using LLVM bitcode libraries

試著忘記壹切 提交于 2019-12-05 17:36:10
问题 I have a C++ project that uses a C++ library that I also wrote. I'm using clang++ 3.3 to build everything. Each file in the library is compiled as clang++ -c -O -emit-llvm somefile.cpp -o somefile.bc I'm then using llvm-link to combine all the library *.bc files into a single bit code file like so llvm-link -o MyLibrary.bc somefile.bc someotherfile.bc etc.bc I'm conceptualizing this to be similar to creating an archive of object files, but I don't think that's true based on how things are

No rule to make target `/Makefile', needed by `Makefile'

不想你离开。 提交于 2019-12-05 17:20:24
I'm trying to 'make' using a pretty simple makefile. My makefile is named 'Makefile' so I'm simply using the command 'make'. I get this strange error: make: *** No rule to make target `/Makefile', needed by `Makefile'. Stop. If, however, I use make -f "full-path-to-makefile" it actually does run (with odd consequences...). I should say that I'm running all this from the directory where the Makefile lies, of course. I'm working on Mac OSX, using tcsh. Edit: I'm working in the LLVM framework, trying to compile a pass function and this is the associated makefile: LEVEL = ../../../ LIBRARYNAME =

Building autotooled software to LLVM bitcode

狂风中的少年 提交于 2019-12-05 17:16:01
问题 I would like to compile software using the autotools build system to LLVM bitcode; that is, I would like the executables obtained at the end to be LLVM bitcode, not actual machine code. (The goal is to be able to run LLVM bitcode analysis tools on the whole program.) I've tried specifying CC="clang -emit-llvm -use-gold-plugins" and variants to the configure script, to no avail. There is always something going wrong (e.g. the package builds .a static libraries, which are refused by the linker)

How do I create named metadata via the llvm-c api?

房东的猫 提交于 2019-12-05 15:54:44
I want to add debug metadata to my generated llvm IR, which is created via the C API. However, I can't figure out how to create named metadata nodes (such as !llvm.dbg.cu), or even how to create metadata nodes with unique numbers (ie. !0, !1, etc.). Adding metadata operands to instructions looks pretty simple, but I cannot figure out how to create standalone metadata nodes. As at LLVM 3.0, there is no function exposed in the C API for creating or modifying named metadata. A new function (LLVMAddNamedMetadataOperand) was recently added to the API , after the 3.0 release. If you're comfortable

LLVM backend for stack based machine

怎甘沉沦 提交于 2019-12-05 15:36:45
问题 Does anyone know any example of an open source LLVM backend for a stack based machine? I need this for education purposes. 回答1: The JVM is a stack-based virtual machine. VMKit was an open-source project of LLVM which implemented a JVM with a LLVM backend. The idea of VMKit was to create a toolkit for building virtual machines (or managed runtime environments) such as JVM, CLI/CLR, R's runtime etc. To find out more, see Nicolas Geoffray's PhD thesis. While the project is retired, the source