[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