Brief: I’m trying to run the sonarcscanner on a mynewt project. Mynewt is an embedded RTOS that’s written in C and uses GCC to build. The scanner is unable to detect the child processes of the ‘newt’ build automation tool. I suspect it may be related to mynewt’s build automation tool being built in golang.
Discussion: If I understand how SonarScanner works, it just intercepts the glibc syscalls, right? I’m wondering if the problem is related to newt being a golang program that sends most of its syscalls through libpthread instead of glibc. Is this a problem that’s perhaps been solved on the golang scanner already?
strace:
strace -f -o trace.log ./build-wrapper-linux-x86-64 --out-dir sonar-out newt build my_blinky_sim
(... many lines skipped)
Thu Jan 02 17:19:02 2020: executing: <newt build my_blinky_sim>
Thu Jan 02 17:19:02 2020: initializing json file
Thu Jan 02 17:19:02 2020: process created with pid: 4388
Thu Jan 02 17:19:02 2020: parent pid: 4385
Thu Jan 02 17:19:02 2020: working directory: </home/gfreese/ws/mynewt-sonar-test>
Thu Jan 02 17:19:02 2020: executable: </home/gfreese/ws/mynewt-sonar-test/build-wrapper-linux-x86-64>
Thu Jan 02 17:19:02 2020: argv[0]: <./build-wrapper-linux-x86-64>
Thu Jan 02 17:19:02 2020: argv[1]: <-c>
Thu Jan 02 17:19:02 2020: argv[2]: <>
Thu Jan 02 17:19:02 2020: argv[3]: <newt>
Thu Jan 02 17:19:02 2020: argv[4]: <build>
Thu Jan 02 17:19:02 2020: argv[5]: <my_blinky_sim>
Thu Jan 02 17:19:02 2020: skipping process with pid: 4388
Thu Jan 02 17:19:02 2020: process created with pid: 4389
Thu Jan 02 17:19:02 2020: parent pid: 4388
Thu Jan 02 17:19:02 2020: working directory: </home/gfreese/ws/mynewt-sonar-test>
Thu Jan 02 17:19:02 2020: executable: </home/gfreese/opt/newt/newt>
Thu Jan 02 17:19:02 2020: argv[0]: <newt>
Thu Jan 02 17:19:02 2020: argv[1]: <build>
Thu Jan 02 17:19:02 2020: argv[2]: <my_blinky_sim>
Thu Jan 02 17:19:02 2020: skipping process with pid: 4389
Thu Jan 02 17:19:15 2020: finalizing json file
Thu Jan 02 17:19:15 2020: returned with code: 0
is this the log with the {{haswell}} workaround in place?
Is /home/gfreese/opt/newt/newt statically linked? We do intercept glibc syscalls using dynamic libraries which means that we cannot follow statically linked binaries.
No worries =). No, I’m not running the docker container. It’s just running straight on my Ubuntu 19.04 system (sidenote- the ldd output was from a different machine).
So… does your scanner for golang operate any differently? I’m assuming it would be hooking libpthread, right? Is it possible to get this scanner to do that?
running ./build-wrapper-linux-x86/build-wrapper-linux-x86-64 --out-dir cfam-out go run main.go doesn’t see the gcc call. I guess it is the way that go fork and exec programs on linux, I need to investigate.