«log» sometimes does not put in "file": the subpath #3860
Comments
|
This is the output when log -verbose debug is executed: So the build runs basename and dirname. |
|
It turned out that the parameter after cc1plus -dumpbase is considered as input file, when it has appropriate filename extension. But it is not an input file. The patch below skips the parameter after -dumpbase. With the patch the generated log.json file contains `"command": ".../cc1plus … -dumpbase -dumpbase-ext …" . That is, it skips the parameter after -dumpbase, but keeps -dumpbase as part of the command. Nevertheless this change does solve my problem. diff --git a/analyzer/tools/build-logger/src/ldlogger-tool-gcc.c b/analyzer/tools/build-logger/src/ldlogger-tool-gcc.c
index 6a67c714..f3503d39 100644
--- a/analyzer/tools/build-logger/src/ldlogger-tool-gcc.c
+++ b/analyzer/tools/build-logger/src/ldlogger-tool-gcc.c
@@ -392,6 +392,10 @@ int loggerGccParserCollectActions(
*/
if (startsWith(current, "-I"))
lastIncPos = action->arguments.size + (current[2] ? 0 : 1);
+ else if (startsWith(current, "-dumpbase"))
+ /* file after -dumpbase must be ignored, it is not a source file
+ */
+ i++;
else if (startsWith(current, "-isystem"))
lastSysIncPos = action->arguments.size + (current[8] ? 0 : 1); |
|
Can this get some attention, please? Here the problem is described very well and a suboptimal fix is included. Somebody with experience on the codechecker internals can easily create a perfect fix. |
|
Hi, |
|
With GNU make 4.2.1 this problem does not happen. |
|
Hi, |
|
No, this does not help. With make 4.4 it fails, with make 4.2.1 it works. |
|
By it fails I mean that the build process terminates very early with the message “make: *** No rule to make target '/src/build/abc/def', needed by '/build/def'. Stop”. |
|
Could you, please, send some environmental info and a minimal reproducer? What linux distribution/version do you use? How did you install "make" itself? Through a package manager, or you compiled it for yourself? If compiled, then what flags did you use? Could you also attach a sample Makefile which presents this issue? |
|
I create an empty file /home/d/abc/a.c, then /home/d/cctest/makefile with this content ifndef A
A=/home/d/abc
endif
export A
all:
$(MAKE) -C band /home/d/cctest/b/makefile with this content a.c: $(A)/a.c
cp $< $@With make 4.4
prints And now
make 4.4 is installed by Fedora 38 (WSL2). |
|
Could you reproduce this? |
GNU make 4.3 uses posix_spawn() for initiating recursive make calls in subdirectories: make -C <subdirectory> Since we overwrote posix_spawn() through LD_PRELOAD and we didn't forward environment variables to the subprocess, the build of the submodule didn't get the environment variables set by a Makefile. This commit fixes this issue so the logging phase behaves the same way as the original build. Fixes Ericsson#3860
|
Hi, |
GNU make 4.3 uses posix_spawn() for initiating recursive make calls in subdirectories: make -C <subdirectory> Since we overwrote posix_spawn() through LD_PRELOAD and we didn't forward environment variables to the subprocess, the build of the submodule didn't get the environment variables set by a Makefile. This commit fixes this issue so the logging phase behaves the same way as the original build. Fixes Ericsson#3860
GNU make 4.3 uses posix_spawn() for initiating recursive make calls in subdirectories: make -C <subdirectory> Since we overwrote posix_spawn() through LD_PRELOAD and we didn't forward environment variables to the subprocess, the build of the submodule didn't get the environment variables set by a Makefile. This commit fixes this issue so the logging phase behaves the same way as the original build. Fixes Ericsson#3860
GNU make 4.3 uses posix_spawn() for initiating recursive make calls in subdirectories: make -C <subdirectory> Since we overwrote posix_spawn() through LD_PRELOAD and we didn't forward environment variables to the subprocess, the build of the submodule didn't get the environment variables set by a Makefile. This commit fixes this issue so the logging phase behaves the same way as the original build. Fixes Ericsson#3860
GNU make 4.3 uses posix_spawn() for initiating recursive make calls in subdirectories: make -C <subdirectory> Since we overwrote posix_spawn() through LD_PRELOAD and we didn't forward environment variables to the subprocess, the build of the submodule didn't get the environment variables set by a Makefile. This commit fixes this issue so the logging phase behaves the same way as the original build. Fixes Ericsson#3860
I call
$ CodeChecker log -b "make" -o json.json &> cc-log-outThen cc-log-out contains:
custom_link_command calls c++. Despite having «dll» this is all Linux code. Then
json.jsonincludes:{ "directory": "/git/productname/something/src/abcxyz", "command": "/usr/libexec/gcc/x86_64-redhat-linux/12/cc1plus -quiet -I . -I /git/productname/something/src/include -I /git/productname/something/src/unix/include -I . -imultilib 32 -D_GNU_SOURCE -D LINUX -D linux -D PIC -D TATRA_OFFSET -D USE_FFI -D DEBUG -D _DEBUG -D unix -D _UNIX_ -D UNIX -D STRICT /git/productname/something/src/abcxyz/unix/tatra.cpp -quiet -dumpdir /git/productname/something/obj-g/abcxyzb0.dll/unix/ -dumpbase tatra.cpp -dumpbase-ext .cpp -m32 -mtune=generic -march=i686 -g -p -fPIC -fprofile-arcs -ftest-coverage -o /tmp/ccfnhb0i.s", "file": "/git/productname/something/src/abcxyz/unix/tatra.cpp" } , { "directory": "/git/productname/something/src/abcxyz", "command": "/usr/libexec/gcc/x86_64-redhat-linux/12/cc1plus -quiet -I . -I /git/productname/something/src/include -I /git/productname/something/src/unix/include -I . -imultilib 32 -D_GNU_SOURCE -D LINUX -D linux -D PIC -D TATRA_OFFSET -D USE_FFI -D DEBUG -D _DEBUG -D unix -D _UNIX_ -D UNIX -D STRICT /git/productname/something/src/abcxyz/unix/tatra.cpp -quiet -dumpdir /git/productname/something/obj-g/abcxyzb0.dll/unix/ -dumpbase tatra.cpp -dumpbase-ext .cpp -m32 -mtune=generic -march=i686 -g -p -fPIC -fprofile-arcs -ftest-coverage -o /tmp/ccfnhb0i.s", "file": "tatra.cpp" }As next I execute «CodeChecker analyze json.json --analyzers clangsa --ctu --z3-refutation on -o x123», which runs in parallel. It
complains:
The problem report is, that for "directory": "/git/productname/something/src/abcxyz" “log” creates two files:
"file": "/git/productname/something/src/abcxyz/unix/tatra.cpp" and
"file": "tatra.cpp"
but these are supposed to be the same file. In particular /git/productname/something/src/abcxyz/tatra.cpp does not exist.
I use the latest codechecker (git commit eac25bc ) compiled from source and I run codechecker within its virtualevn (created by «make venv»).
The text was updated successfully, but these errors were encountered: