Unable to log direct invocations

[whisperity]

In the development of CodeChecker we hit an issue with using intercept-build: we are unable to log with intercept-build if a direct compiler invocation is passed as a build command.

Take, for example, the following lines:

intercept-build g++ -c main.cpp -o main.o
intercept-build clang++ -c main.cpp -o main.o

The result is an empty compile_commands.json

Trying to set --override-compiler and --use-cc/--use-c++ to the compiler executables themselves doesn't help either.

g++

g++ is /usr/bin/g++ which is a sym-link to /usr/bin/g++-5

15:59 $ g++ -v
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) 

In case of g++, setting --use-c++ /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus helps. This way, it looks like that proper compile database is created:

[
    {
        "arguments": [
            "c++", 
            "-c", 
            "-quiet", 
            "-imultiarch", 
            "x86_64-linux-gnu", 
            "-D_GNU_SOURCE", 
            "-quiet", 
            "-dumpbase", 
            "-mtune=generic", 
            "-march=x86-64", 
            "-auxbase", 
            "main", 
            "-fstack-protector-strong", 
            "-Wformat", 
            "-Wformat-security", 
            "-o", 
            "/tmp/cczGC4VM.s", 
            "main.cpp"
        ], 
        "directory": "/home/username/dummyproject", 
        "file": "main.cpp"
    }
]

However, this is not automatic, and very specific to the users' environment. :slightly_frowning_face:

clang

The problem is even more affecting when someone tries to use clang++ as their compiler. Both clang and clang++ are sym-links to clang-5.0:

16:01 $ clang++ -v
clang version 5.0.0 (github.com:llvm-mirror/clang 870fa3969cf0e9e914b21be0b8351f4b8b907eae) (github.com:llvm-mirror/llvm 0a652f13093ce838e1eeb04abe88940257c62e20)
Target: x86_64-unknown-linux-gnu

Using --use-c++ "/home/username/LLVM/build/bin/clang-5.0" does not help in this case, the compile JSON remains empty.

The problem lies in that a direct clang invocation creates an invocation which contains a -cc1 argument, which explicitly makes the executed command to be ignored. If I edit the file to "unignore" -cc1, the compile JSON is created, but it contains, seemingly, a lot of useless data:

[
    {
        "arguments": [
            "cc", 
            "-c", 
            "-cc1", 
            "-triple", 
            "x86_64-unknown-linux-gnu", 
            "-emit-obj", 
            "-mrelax-all", 
            "-disable-free", 
            "-disable-llvm-verifier", 
            "-discard-value-names", 
            "-main-file-name", 
            "-mrelocation-model", 
            "static", 
            "-mthread-model", 
            "posix", 
            "-mdisable-fp-elim", 
            "-fmath-errno", 
            "-masm-verbose", 
            "-mconstructor-aliases", 
            "-munwind-tables", 
            "-fuse-init-array", 
            "-target-cpu", 
            "x86-64", 
            "-dwarf-column-info", 
            "-debugger-tuning=gdb", 
            "-coverage-notes-file", 
            "/home/username/dummyproject/main.gcno", 
            "-resource-dir", 
            "/home/username/LLVM/build/lib/clang/5.0.0", 
            "-internal-isystem", 
            "/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0", 
            "-internal-isystem", 
            "/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/x86_64-linux-gnu/c++/5.4.0", 
            "-internal-isystem", 
            "/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/x86_64-linux-gnu/c++/5.4.0", 
            "-internal-isystem", 
            "/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/backward", 
            "-internal-isystem", 
            "/usr/local/include", 
            "-internal-isystem", 
            "/home/username/LLVM/build/lib/clang/5.0.0/include", 
            "-internal-externc-isystem", 
            "/usr/include/x86_64-linux-gnu", 
            "-internal-externc-isystem", 
            "/include", 
            "-internal-externc-isystem", 
            "/usr/include", 
            "-std=c++11", 
            "-fdeprecated-macro", 
            "-fdebug-compilation-dir", 
            "/home/username/dummyproject", 
            "-ferror-limit", 
            "19", 
            "-fmessage-length", 
            "166", 
            "-fobjc-runtime=gcc", 
            "-fcxx-exceptions", 
            "-fexceptions", 
            "-fdiagnostics-show-option", 
            "-fcolor-diagnostics", 
            "-o", 
            "main.o", 
            "-x", 
            "c++", 
            "main.cpp"
        ], 
        "directory": "/home/username/dummyproject", 
        "file": "main.cpp"
    }
]

[rizsotto]

Thanks for the report. This use-case was intentionally not addressed. Might fix in the future. A recommended workaround is:

intercept-build sh -c "g++ -c main.cpp -o main.o"
intercept-build sh -c "clang++ -c main.cpp -o main.o"