How to use LLVM config files with analyzers?

[sztomi]

I'm using clang config files in my custom toolchain. They are loaded based on symlinks to the actual compiler (this is similar to a compiler wrapper script, but saves a shell invocation):

--sysroot <CFGDIR>/../targets/x86_64-unknown-linux-musl
-Wl,--no-dynamic-linker
-Wl,-rpath,<CFGDIR>/../targets/x86_64-unknown-linux-musl/lib
-Wl,-rpath,<CFGDIR>/../lib/x86_64-unknown-linux-musl
-Qunused-arguments
-pie
-fPIC

(my compiler is a symlink to the actual clang++ binary called x86_64-unknown-linux-musl-clang++)

When I try to run clangsa/clang-tidy, I get lots of errors like

error: is pie differs in PCH file vs. current file [clang-diagnostic-error]

This suggests that it's calling plain clang or clang-tidy instead of x86_64-unknown-linux-musl-*. Is there a way to set the full paths to the commands to be called? I see some indication of this in package_layout.md but I lack a lot of context. Where do I write this config file and how do I tell CodeChecker to use it?

[bruntib]

Hi,

PCH files are generated during CTU analysis. Cross Translation Unit analysis works in two phases: first the source files are compiled to PCH files, so in the 2nd phase there's no need to recompile them when a function's definition is needed from another translation unit. Some elaboration would be needed about why the generated PCHs are incompatible with the analyzer invocation. One reason can be that two different clang compilers are used in the two phases, or different compiler options are used in the two phases. Maybe CodeChecker doesn't apply compiler flags from from the config file in the 1st phase.
Maybe if you could run the analysis with --verbose debug option then the generated clang invocations could be inspected in both phases.

[sztomi]

Hi,

Thanks for your answer. I was able to confirm that it was what I suspected above (the -pie flag was different because our compiler essentialy hardcodes that, while the system clang does not). Our project itself uses PCH files to speed up compilation (independently from CodeChecker) and these PCH files are generated using our compiler. The project cannot be built (or parsed by clang tools) before these files are generated.

I found that editing ~/.local/share/codechecker/config/package_layout.json to hardcode our particular compiler fixes the issue. I think it would be best to allow customizing the compiler via environment variables because it seems like I need to edit a config file that is internal to CodeChecker.

[whisperity]

There is an environment variable for this, I think it's called CC_ANALYZERS_FROM_PATH (but you can verify from the CodeChecker analyze --help output), at which point the clang/clang++ and clang-tidy binaries will come from PATH using the usual conventions: from front to back the first executable that matches in an appropriate directory will be selected.

I believe CodeChecker analyzers also respects this variable, so you can try whether it is found. CodeChecker analyzers --details should show the full path from which an analyser is resolved.

[sztomi]

CC_ANALYZERS_FROM_PATH doesn't do what I need. I have a multi-target toolchain where each compiler is a symlink, for example x86_64-plex-linux-musl-clang, pointing to clang. The .cfg files that are located in the same dir (e.g. x86_64-plex-linux-musl.cfg) will be loaded automatically by the frontend to apply flags (most typically, --target and -pie). CC_ANALYZERS_FROM_PATH overrides the default codechecker behavior of using what's set in package_layout.json, but it will simply try to use clang or clang-tidy from the PATH (i.e. it would load the wrong compiler). In short, to resolve this without editing the internal config of CodeChecker, there should be an environment variable to set the exact name of the compiler.

I would argue that similarly to how build systems widely recognize CC and CXX, it would be beneficial for CodeChecker to not distinguish between "from path" behavior vs. using the environment variable when present. Popen doesn't care if it's an absolute path or just the name of the command, I see no reason to take away this flexibility.

[bruntib]

I created a ticket about this issue: #3898.

[sztomi]

Thanks!