Title
#extensions
Daniel Bretón Suárez

Daniel Bretón Suárez

10/06/2022, 7:14 AM
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
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
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
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

alessandrogario

10/06/2022, 7:31 PM
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)
7:32 PM
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
Daniel Bretón Suárez

Daniel Bretón Suárez

10/07/2022, 1:01 PM
--rootoption is used to chose the folder which contains all the sources, each source should have associated a .gcdaand .gcnofile (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 gcdaand
gcno
files under osquery/build/external/extension_hello/CMakeFiles/hello_my_friend_extension_test.dirso the util is not able to "link" the files
a

alessandrogario

10/07/2022, 1:04 PM
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
1:05 PM
The current system is not great, but there are some reasons for why I think it was made this way
1:06 PM
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
1:06 PM
If the extension is built autonomously, it will have to solve those problems all over again
1:07 PM
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
1:07 PM
So I would not be against having a proper SDK
1:08 PM
We could still provide a cpp extension template for beginners that already integrates with the osquery-toolchain
1:09 PM
(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)
Daniel Bretón Suárez

Daniel Bretón Suárez

10/07/2022, 2:39 PM
I agree with you, osquery is not responsible for third-party extensions
a

alessandrogario

10/07/2022, 2:41 PM
I wonder how many users rely on this, maybe we do have to provide a migration plan
Daniel Bretón Suárez

Daniel Bretón Suárez

10/07/2022, 2:48 PM
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

alessandrogario

10/07/2022, 3:00 PM
That would definitely help! But I was thinking about redistribution
3:01 PM
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
3:01 PM
People who want to ship to CentOS 6 will be forced to build everything directly there
3:02 PM
The toolchain is not enough to cover that if they end up using external libraries
3:02 PM
those external libraries will either have to be built with the osquery-toolchain themselves, or they'll have to just go with CentOS 6
3:03 PM
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