Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to log direct invocations #79

Open
whisperity opened this issue Mar 10, 2017 · 1 comment
Open

Unable to log direct invocations #79

whisperity opened this issue Mar 10, 2017 · 1 comment

Comments

@whisperity
Copy link

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

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
Copy link
Owner

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"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants