December 6, 2019 at 21:49 #26782
When building VK’s sample “Hello World” LKM, I noticed that the resulting ELF file is a whopping 70kB in size and contains debugging information embedded inside.
How would I go about creating an undebuggable “Release” Configuration, that would not generate ELF binaries with the debugging information embedded inside …and do everything possible to minimize the size of the resulting binary ?
I looked at the options that VK passes to the
gcccompiler and there is myriad of them !!!
One of these options, the
-ggdbis most likely partly responsible for the large size of the resulting binary, but there might be other ones.
I have seen that in VK’s
Module build settingsthere are options to add
Additional Make argumentsand
CFLAGS…but no option to remove a flag like the
-isystem /usr/lib/gcc/arm-linux-gnueabihf/8/include -I/usr/src/linux-headers-4.19.0-6-common/arch/arm/include
-o /tmp/VisualKernel/c/Users/Mr/source/repos/LinuxKernelModule2/LinuxKernelModule2/.tmp_LinuxKernelModule2_main.o /tmp/VisualKernel/c/Users/Mr/source/repos/LinuxKernelModule2/LinuxKernelModule2/LinuxKernelModule2_main.cDecember 9, 2019 at 12:21 #26810December 12, 2019 at 17:51 #26860
70 KB is still orders of magnitude less than a typical Linux kernel + rootfs, so VisualKernel does not provide any special GUI for removing the debug symbols from the built modules.
That said, you can always remove the symbols from the built module by running the strip tool (you can conveniently use the custom post-build actions if you would like to automate it).December 13, 2019 at 02:15 #26863
… VisualKernel does not provide any special GUI for removing the debug symbols from the built modules.
You realize, this means that VisualKernel does not support “Release Builds” natively …and the user is forced to generate “Debug Builds” against his better judgement.
Massaging down these builds later is an ugly workaround. Also, it seems that it is impossible to add an overriding non-GUI option
Module Build Settings, since VK does not even respect changes made to that field (…the changes revert back after Project Properties window is reopened ) !
December 20, 2019 at 17:50 #26920
- This reply was modified 1 month, 1 week ago by Goerge255.
This limitation comes from the fact that the native Linux Kernel build system (KBuild) does not natively support separate debug/release build subdirectories, hence supporting Debug/Release builds from the VisualKernel GUI without the risk of combining incompatible files would require non-trivial patches to Kbuild.
Furthermore, in our experience, the release builds of performance-critical modules (e.g. drivers) are usually done as a part of a larger build system (e.g. Yocto), while the VisualKernel projects are used for debug builds.
Since VisualKernel uses unmodified KBuild Makefiles, you can always extend them to use conditional statements (e.g. ifeq()) in order to apply different flags depending on the arguments passed via command line. However, as this presents a risk of combining files built with different flags, it is not supported out-of-the-box and is only recommended for advanced users that are comfortable editing Makefiles.
You must be logged in to reply to this topic.