[cfe-dev] LibTooling question

Mario Schwalbe mario at se.inf.tu-dresden.de
Wed Aug 1 07:00:27 PDT 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Manuel, Nick, CLANGers,

Am 01.08.2012 15:45, schrieb Manuel Klimek:
> On Tue, Jul 31, 2012 at 10:37 AM, Mario Schwalbe <mario at se.inf.tu-dresden.de> wrote: I've been playing with Clang's LibTooling classes closely following the tutorial at http://clang.llvm.org/docs/LibTooling.html in order to make use of clang as a frontend in our project.
> 
> However, I might need some assistence:
> 
> 1. Include headers: Using the ClangTool class (like the example suggests) it cannot find its own headers. The documentation states:
> 
> "Clang tools need their builtin headers and search for them the same way clang does. Thus, the default location to look for builtin headers is in a path $(dirname /path/to/tool)/../lib/clang/3.2/include relative to the tool binary."
> 
> But apparently the passed pseudo argv[0] is clang-tool, and, hence, the invocation contains:
> 
>> That should only be the case if you use runToolOnCode, and not if you use ClangTool.

No. I never tried runToolOnCode().

>> Does the code live somewhere you can point me to?

Yes. http://clang.llvm.org/docs/LibTooling.html. Basically, it is the ClangCheck
example if you use a FixedCompilationDatabase passed via the command line.
Btw: It works on Windows because several -internal-isystem options point to
VC headers which contain stddef.h and co.

I got it to work now using the ToolInvocation class. I just wanted to point out
that imho this behaviour renders the ClangTool class somewhat useless on Linux
and others might fight the same problem as well...

> 2. I finally managed to run a SyntaxOnlyAction as well as PrintPreprocessedAction. But how can I compile a module to LLVM IR?
> 
> 3. And is it possible to access the generated result (LLVM IR or preprocessed source code) without first writing to disk and re-reading.
> 
>> Regarding code generation I'm not sure :) The tooling is definitely built mainly with parsing in mind. I've looped in Nick for some comments on what might be necessary to get your use case working...

Never mind. I already found it by grepping the clang sources. ;-) The answer
are CodeGenActions like EmitLLVMAction and EmitBCAction. Although it seems like
I have to write to disk, since (a) the ToolInvocation class always generates an
- -o option, and (b) the derived CodeGenAction::takeModule() always returns NULL.
(I still don't know why.)

ciao,
Mario
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQGTZ6AAoJEDv0fP6GapNtmU0IALmHp8UTwwII53Q/YWkL6ckp
c5WozXRM9lnG5JD4QMoWN7c8/DKK+EACKnyllEynVmjk1x4cFLcFTODscavw2rDu
ensSfUM5R9jeCsF3PBwwVP/mQcbBjGmYHA+VGE9daZXrhvk6BOs4zxWUD/mcLpc4
hYXXAn1MvXiHq7E9aoi3a8KGiC033Mreafg1QqL9EFaiVANKfBaUFBL9GLex/whW
V/GYyjg/b9Yl0Yk6+6/pRnx7x82dVVVfHlf2eCd+KkblRYbciPG7bW4Xw78Gw0f/
c5GL5jfmNyMNipEBEKPQjCEBmcE5FNMEjfR8kyUap5hkSd+4LYc3dKNMA3D3VIg=
=Tm3T
-----END PGP SIGNATURE-----



More information about the cfe-dev mailing list