Open schmerl opened 2 years ago
Hey. This is a limitation with the current analysis. This is a slightly harder case of third-party API calls. Whereas for packages like TF, etc., we can write a set of models for certain API calls, for these packages, we need to extract summaries for DLLs (in the correct order) and then use those summaries when recovering models for binaries that use those same DLLs.
Right. If I look at the CMakeLists.txt, we have:
project(interactive_marker_twist_server)
find_package(catkin REQUIRED COMPONENTS
interactive_markers
roscpp
tf
visualization_msgs)
catkin_package()
include_directories(${catkin_INCLUDE_DIRS})
add_executable(${PROJECT_NAME} src/marker_server)
target_link_libraries(${PROJECT_NAME} ${catkin_LIBRARIES})
set_target_properties(${PROJECT_NAME}
PROPERTIES OUTPUT_NAME marker_server PREFIX "")
I suspect the include files for interactive_markers
are being added to ${catkin_INCLUDES}
in this magic, and we would want to add those to the source scope.
We only need the translation units for C++ recovery. The header files (provided by ${catkin_INCLUDES}
) are given to us for free by compile_commands.json
Here is (I think) an interesting case in husky. The launch file we have launches
twist_marker_server
from/ros_ws/src/husky/husky_control/launch/control.launch
. This loads the node that is represented by the source:/ros_ws/src/interactive_marker_twist_server/src/marker_server.cpp
. This calls the constructorserver("twist_marker_server")
that is included from another package:interactive_markers
. This is a call to the code in/ros_ws/src/interactive_markers/src/interactive_marker_server.cpp
that we could recover. Currently the recovery doesn't include this - is this a CMake processing error on my part for not including it among the places to look for source files?