[cfe-dev] LibTooling question

Wed Aug 1 07:10:13 PDT 2012

On Wed, Aug 1, 2012 at 4:00 PM, Mario Schwalbe
<mario at se.inf.tu-dresden.de> wrote:
> -----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 need more context to reproduce. For me, with the latest clang-check
built from head, and the following setup:

$ find /tmp/c
/tmp/c
/tmp/c/bin
/tmp/c/bin/clang-check
/tmp/c/lib
/tmp/c/lib/clang
/tmp/c/lib/clang/3.2
/tmp/c/lib/clang/3.2/include
...
/tmp/c/lib/clang/3.2/include/stddef.h
...

$ clang-check t2.cc -- -c -v
Processing: /home/klimek/Snippets/t2.cc.
clang version 3.2 (trunk)
Target: x86_64-unknown-linux-gnu
Thread model: posix
clang Invocation:
 "/tmp/c/bin/clang-check" "-cc1" "-triple" "x86_64-unknown-linux-gnu"
"-fsyntax-only" "-disable-free" "-main-file-name" "t2.cc"
"-mrelocation-model" "static" "-mdisable-fp-elim" "-fmath-errno"
"-masm-verbose" "-mconstructor-aliases" "-munwind-tables"
"-target-cpu" "x86-64" "-momit-leaf-frame-pointer" "-v"
"-resource-dir" "/tmp/c/bin/../lib/clang/3.2" "-fmodule-cache-path"
"/var/tmp/clang-module-cache" "-internal-isystem"
"/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6"
"-internal-isystem"
"/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/x86_64-linux-gnu"
"-internal-isystem"
"/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/backward"
"-internal-isystem" "/usr/local/include" "-internal-isystem"
"/tmp/c/bin/../lib/clang/3.2/include" "-internal-externc-isystem"
"/usr/include/x86_64-linux-gnu" "-internal-externc-isystem" "/include"
"-internal-externc-isystem" "/usr/include" "-fdeprecated-macro"
"-fdebug-compilation-dir" "/home/klimek/Snippets" "-ferror-limit" "19"
"-fmessage-length" "362" "-mstackrealign" "-fobjc-runtime=gcc"
"-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option"
"-fcolor-diagnostics" "-x" "c++" "/home/klimek/Snippets/t2.cc"

clang -cc1 version 3.2 based upon LLVM 3.2svn default target
x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6
 /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/x86_64-linux-gnu
 /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/backward
 /usr/local/include
 /tmp/c/bin/../lib/clang/3.2/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.

Which looks exactly like it should.

Can you post the output of calling your tool with -- -c -v?

Thanks,
/Manuel

>
> 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-----