I'm trying to build a coverage report for an exten...
# extensions
d
I'm trying to build a coverage report for an extension using the
gcovr
tool (on which I have very little knowledge).
.gcno
and
.gcda
files are generated but test coverage is always 0% in all the sources. At the moment I'm blocked, all the guides I've read say it should work. Maybe someone can point me in the right direction? I think it is related to the way extensions are built because sources are in a different folder than binaries. However,
gcovr
has a
--root
option on which source files can be specified so it might not be the problem. This are the steps I'm performing on Ubuntu
Copy code
cd osquery
ln -s /home/danielbreton/workspace/osquery-extension-hello/ external/extension_hello
cd build
cmake -DOSQUERY_TOOLCHAIN_SYSROOT=/usr/local/osquery-toolchain -DOSQUERY_BUILD_TESTS=ON -DENABLE_COVERAGE=true ..
cmake --build . -j$(nproc) --target hello_my_friend_extension_test
./external/extension_hello/hello_my_friend_extension_test
gcovr --xml-pretty --exclude-unreachable-branches --print-summary -o coverage.xml --root /home/danielbreton/workspace/osquery-extension-hello/
And this is the complete
CMakeLists.txt
for the extension
Copy code
project("hello_my_friend_extension")

addOsqueryExtension(
  "${PROJECT_NAME}"
  hello.cpp
  main.cpp
)

set(common_test_files
  hello.cpp
)

add_executable(
  "${PROJECT_NAME}_test"
  EXCLUDE_FROM_ALL
  ${common_test_files}
  test.cpp
)

if(ENABLE_COVERAGE)
  message("Enabling coverage")
  # set compiler flags
  set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -O0 -fprofile-arcs -ftest-coverage")
  set(CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -O0 -fprofile-arcs -ftest-coverage")
  # find required tools
  find_program(GCOVR gcovr REQUIRED)
endif()

target_link_libraries("${PROJECT_NAME}_test" PRIVATE
  thirdparty_googletest
  osquery_sdk_pluginsdk
  osquery_extensions_implthrift
)

if(ENABLE_COVERAGE)
  add_link_options("--coverage")
endif()
Project tree
Copy code
danielbreton@2022-EMEA-0022 ~/workspace/osquery-extension-hello (feature/UA-1101)$ tree
.
├── CMakeLists.txt
├── hello.cpp
├── hello.h
├── main.cpp
├── README.md
└── test.cpp
a
Can you elaborate more on the --root option? I think that from the CMake standpoint the extension is still in the osquery source tree, so those paths should not be too different from the core files (but I may have misunderstood)
On the path thingy, we sadly have a problem with the include namespaces that we had to add due to Facebook's Buck build system. I think it would be great to completely remove them now that we are back to CMake
d
`--root`option is used to chose the folder which contains all the sources, each source should have associated a `.gcda`and `.gcno`file (with the same name) to build the coverage report. I'm worried about having the source files on the extension folder (outside osquery) and those `gcda`and
gcno
files under `osquery/build/external/extension_hello/CMakeFiles/hello_my_friend_extension_test.dir`so the util is not able to "link" the files
a
I see; I think the link we create is to be considered just a workaround, and we should consider the build process as compiling osquery & the extension together
The current system is not great, but there are some reasons for why I think it was made this way
1. Originally, it was meant to be this way to ease moving code from/to core and extensions 2. Redistribution issues: if the extension is built inside the osquery build process, it will inherit the redistributable properties of the osquery toolchain + all the libraries that have been imported
If the extension is built autonomously, it will have to solve those problems all over again
I can understand both points, but I don't really think it should be osquery's responsibility to ensure that third-party C++ extensions are built the right way
So I would not be against having a proper SDK
We could still provide a cpp extension template for beginners that already integrates with the osquery-toolchain
(this is also mostly a Linux issue, backward compatibility on Windows and macOS is implemented in a much more sane way through official Xcode/VS features)
d
I agree with you, osquery is not responsible for third-party extensions
a
I wonder how many users rely on this, maybe we do have to provide a migration plan
d
Well, if i'm able to generate the coverage reports, I will explain how. Also, I have a guide for beginners and a very basic extension I've done for myself based on the docs and TOB public repository. Maybe it helps others
a
That would definitely help! But I was thinking about redistribution
If we remove this integration I think we need to provide at least a couple of notes on what they will have to handle on their own
People who want to ship to CentOS 6 will be forced to build everything directly there
The toolchain is not enough to cover that if they end up using external libraries
those external libraries will either have to be built with the osquery-toolchain themselves, or they'll have to just go with CentOS 6
another alternative that some teams are adopting is to just build once for every distro they want to support and have their own repositories set up