Multiple compilers in JSON compilation database

[gerioldman]

Hi,

I've run into a problem using the compile_commands.json file generated by Meson. As far as I can tell, codechecker seems to expect a database to exclusively for one target, or at least not have different compilers in the file. Currently, my meson system builds unit tests for the host machine, for the target, and the "whole software" itself, so all of it gets put in the same compile_commands.json file. When disabling the target unit test builds, and the software build, codechecker works. Could there by any other way of solving this other than me writing a script to separate the generated json file into several ones correlating only to one binary? I think that using several compilers shouldn't(?) cause a problem during analyis, only for Cross Translation Unit analysis.

Any thoughts?
Thanks, Geri

[bruntib]

Hi,

Cross Translation Unit analysis works in a way that if the analysis goes through a function call, then the body of that function is loaded on-the-fly. If the function is compiled to multiple targets by several build actions then CodeChecker can't decide which version to import, because linker information is not available. We haven't focused on gathering linking information so far, but we assume as a precondition that every function is compiled to exactly one platform (the diversity of compilers in itself shouldn't be a problem).
CodeChecker, however, helps in uniqueing build actions. Please, consult the documentation of --compile-uniqueing flag of CodeChecker analyze command. Maybe the regex version of this flag could help in choosing a specific platform for CTU analysis.

[gerioldman]

Hi,

I am sorry for not getting back to you earlier. I found the real culprit behind my problem. The software I am trying to analyize is embedded, which contains assembly files (startup code), and Meson puts that file into the compilation database as well. If I run codechecker with the following command:

codechecker analyze .\builddir\compile_commands.json --output .\reports --verbose debug

I get this output:

[DEBUG][2023-05-13 17:22:26] {system} [20152] <19180> - analyze.py:995 main() - args: Namespace(logfile='.\\builddir\\compile_commands.json', jobs=4, keep_gcc_include_fixed=False, keep_gcc_intrin=False, output_format='plist', makefile=False, compile_uniqueing='none', config_file=None, analyzer_config=['clang-tidy:HeaderFilterRegex=.*'], func=<function main at 0x0000021D609041F0>, func_process_config_file=<function process_config_file at 0x0000021D608CBC70>, output_path='H:\\Egyetem\\Msc\\sandbox\\reports', verbose='debug')
[DEBUG][2023-05-13 17:22:26] {system} [20152] <19180> - analyze.py:996 main() - Output will be stored to: 'H:\Egyetem\Msc\sandbox\reports'
[DEBUG][2023-05-13 17:22:26] {buildlogger} [20152] <19180> - log_parser.py:419 get_compiler_includes() - Retrieving default includes via cc -E -x c - -v
[DEBUG][2023-05-13 17:22:27] {buildlogger} [20152] <19180> - log_parser.py:419 get_compiler_includes() - Retrieving default includes via arm-none-eabi-gcc -std=gnu11 -E -x c - -v
[DEBUG][2023-05-13 17:22:28] {buildlogger} [20152] <19180> - log_parser.py:419 get_compiler_includes() - Retrieving default includes via arm-none-eabi-gcc -std=gnu11 -E -x '' - -v[ERROR][2023-05-13 17:22:28] {buildlogger} [20152] <19180> - log_parser.py:1350 parse_unique_log() - The compile database is not valid.
[DEBUG][2023-05-13 17:22:28] {buildlogger} [20152] <19180> - log_parser.py:1351 parse_unique_log() - Traceback (most recent call last):
  File "C:\Users\kgerg\AppData\Roaming\Python\Python310\site-packages\codechecker_analyzer\buildlog\log_parser.py", line 1288, in parse_unique_log
    action = parse_options(entry,
  File "C:\Users\kgerg\AppData\Roaming\Python\Python310\site-packages\codechecker_analyzer\buildlog\log_parser.py", line 1077, in parse_options
    ImplicitCompilerInfo.set(details, compiler_info_file)
  File "C:\Users\kgerg\AppData\Roaming\Python\Python310\site-packages\codechecker_analyzer\buildlog\log_parser.py", line 574, in set
    'compiler_includes': ICI.get_compiler_includes(
  File "C:\Users\kgerg\AppData\Roaming\Python\Python310\site-packages\codechecker_analyzer\buildlog\log_parser.py", line 423, in get_compiler_includes
    include_dirs = ICI.__parse_compiler_includes(cmd)
  File "C:\Users\kgerg\AppData\Roaming\Python\Python310\site-packages\codechecker_analyzer\buildlog\log_parser.py", line 379, in __parse_compiler_includes
    lines = ImplicitCompilerInfo.__get_compiler_err(compile_cmd)
  File "C:\Users\kgerg\AppData\Roaming\Python\Python310\site-packages\codechecker_analyzer\buildlog\log_parser.py", line 343, in __get_compiler_err
    proc = subprocess.Popen(
  File "C:\Program Files\Python310\lib\subprocess.py", line 971, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "C:\Program Files\Python310\lib\subprocess.py", line 1380, in _execute_child
    args = list2cmdline(args)
  File "C:\Program Files\Python310\lib\subprocess.py", line 563, in list2cmdline
    for arg in map(os.fsdecode, seq):
  File "C:\Program Files\Python310\lib\os.py", line 823, in fsdecode
    filename = fspath(filename)  # Does type-checking of `filename`.
TypeError: expected str, bytes or os.PathLike object, not NoneType

[DEBUG][2023-05-13 17:22:28] {buildlogger} [20152] <19180> - log_parser.py:1352 parse_unique_log() - expected str, bytes or os.PathLike object, not NoneType

Codechecker seems to invoke the arm-none-eabi-gcc compiler twice to get the compiler includes, but for the second time, it seems to put None at the language part, which causes the subprocess starting to freak out and stop. Is there any nice solution to filter out assembly files?

[bruntib]

Hi,
I created a PR which fixes this issue: #3914.