I have an existing and working source-to-source code modification tool using libtooling (written in C++). Now I want to integrate this tool into clang, so users can compile the modified source code without actually saving it somewhere.
The modification part isn't problematic, Matchers + Rewriters work the same way with clang, my problem is how to tell the compiler to reparse the source code after my changes.
Related
I`m trying to find best solution for parsing C++ code for my refactor support tool. I decided to use clang frontend because it is meant to be frontend of C++ compiler. I found the documentation page that describes parsing of C++ code using clang LibTooling. But, unfortunately, it looks for me that LibTooling cannot be used separately from clang infrastructure installed on the tool user side.
So, my question: is it possible to compile Clang LibTooling to standalone parser that my be reused between C++ parse projects without clang infrastructure? Ideal solution for me is shown on the picture. I want to compile LibTooling linking it with my wrapping library (that may simplify / adopt LibTooling API for my purposes) and then reuse it between different projects.
P.S.: Maybe, something like it where performed in Firolino's clang project - but it looks that full clang installation should be used for too.
P.P.S.: As for me, solution that is whanted for my may be useful for all C++ community. So if somebody want to cooperate with me in making this project - you are welcome!
Given some C++ features are supported on GCC but not Clang, it's possible for my codebase to compile with GCC, but not clang.
As per title, would there be any issues with running clang-format on said codebase?
Tried running clang-format on my codebase and everything seems to work. However, I want to be very sure that I'm not missing anything.
A formatter (such as clang-format) doesn't need to compile the source in order to format it. As such, clang-format may work on source that cannot be compiled by clang.
However, some language features are significant syntactical additions to the language (such as function attributes and lambdas have been). If the formatter hasn't been updated to handle such syntax change, then it may fail to work, or it may produce an undesirable format.
I have a software that is able to generate C code that I would like to use in a just-in-time compilation context. From what I understand, LLVM/Clang is the way to go and, for maintainability of the project, I'd like to use the C API of llvm and Clang (libclang).
I started out creating a libclang context using clang_createIndex and a translation unit using createTranslationUnitFromSourceFile (would have been nice to be able to avoid going via the file system and pass the source code as a string instead). But I pretty much get stuck there. How can I go from the libclang translation unit to an LLVM "execution engine" which is what appears to be needed for JIT? Or is this not even possible using the C API?
The best method to learn how to use a body of code is to investigate the examples you're given.
There exist tutorials on how to leverage the clang/llvm tools to compile C++ code and emit LLVM-IR, to compile LLVM-IR to LLVM-Bitcode, and to execute that LLVM-bitcode. All that is necessary to learn to incorporate this functionality in our application is to investigate the execution path of these tools, to find the sequence of methods that accomplish what we want.
Here is an example using the example tools of compiling a cpp file to llvm-bitcode, and executing it.
clang++ -c -O3 -emit-llvm main.cpp -o main.bc
lli main.bc
This is a great start, we can just look at the source behind the tools, and investigate the execution path outlined by the arguments. Since these tools are merely interfaces exposing the underlying functionality available in the llvm/clang libraries that we can add to our project, following the execution path shallowly will give us a sequence of library available methods that we can call within our application to accomplish the same results.
Once the sequence of library methods is trivially established, you can delve into breaking individual library methods into their underlying functionality, and tease out the exact behavior we desire through a relatively small set of modifications here and there, rather than trying to reimplement something from the ground up.
I'm writing a C++ program where I need to be able to parse C code into an AST, perform some operations on it, and then convert it back to a string representation. In almost all similar questions I've read, the answer is "use clang".
However, according to http://amnoid.de/tmp/clangtut/tut.html, the flag -fno-rtti must apparently be provided when compiling code which uses clang, but I'm using features such as virtual functions and down-casting objects using dynamic_cast in my own code. Is there still a way of using clang, or do I need to resort to another library?
Clang itself must be compiled with -fno-rtti, but I don't believe there's any requirement for -fno-rtti when you're using clang to compile (or just build an AST from) other code.
Either recompile Clang with RTTI enabled, or build it as a shared library (though this one I'm not entirely sure about).
We have recently downloaded, installed and compiled gcc-3.0.4 code. gcc compiler has built successfully and we where able to compile some same test cpp file. I would like to know how we can modify gcc source code so that we add additional run time debugging statements like the binary in execution compiled by my gcc should print below statement in a log file:
filename.cpp::FunctionName#linenumber-statement
or any additional information that I can insert via this tailored compiler code.
Have you looked at the macros __FILE__ and __LINE__? They do that for you without modifying the compiler. See here for more information.
My general understand of the GCC architecture is, that it is divided into front-end (parser), middle (optimization in a special intermediate language), and a back-end (generating platform dependent output). So, for your purposes you would have to look into the back-end part.
Don't do that with an ancient compiler like GCC 3.0.
With a recent GCC 4.9 (in end of 2014 or january 2015) you could customize the compiler, e.g. with a MELT extension, which would add a new optimization pass working on Gimple. That pass would insert a Gimple statement (hopefully a call to some debugging print) before each Gimple call statement.
This is a non-trivial work (perhaps weeks of work). You need to understand all of Gimple