ENPM808X - Abhishekh Reddy Munnangi, 119399002
Note: The steps assume that the user already has the environment for ENPM808x course.
git clone https://github.com/armgits/armgits-valgrind-exercise.git armgits-valgrind-exercise
Note: Run the following commands from the project root directory
cmake -S ./ -B build/
Note: Re-run this command everytime when any
CMakeLists.txt
file is changed.
Normal
cmake --build build/
Build clean
cmake --build build/ --clean-first
Using bear
bear -- cmake --build build/ --clean-first
valgrind --leak-check=yes ./build/app/shell-app
Clean the build artifacts while retaining the build system
cmake --build build/ --target clean
Remove the build system including artifacts
rm -rf build/
Additional files and folders (if they exist)
rm -r .cache/ compile_commands.json
1. What happens when the executable is linked statically? Does Valgrind still detect those same bugs?
By rebuilding the project and re-running Valgrind after enabling static linking in the app/CMakeLists.txt
file, there are additional errors. If the previous two bugs were not fixed, Valgrind will detect the same bugs in the program in addition to the bugs from libraries after enabling static linking.
Linking the executable statically bakes in the links to the libraries the program relies on. This technically makes the library code to be the part of binary executable on which Valgrind runs its tests on.
If the library code the program relies on contains bugs the library authors are responsible for, they still show up in the actual program since Valgrind cannot differentiate library code from the code written by the programmer due to static linking.
By dynamically linking the libraries, Valgrind could clearly differentiate the library code from the program code and supress the errors from library code. This greatly improves debugging since the errors are now focused on the actual program written by the programmer.