Release Configuration – building binaries of small size

[Goerge255]

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 gcc compiler and there is myriad of them !!!
One of these options, the -ggdb is 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 Project Properties / Module build settings there are options to add Additional Make arguments and CFLAGS …but no option to remove a flag like the -ggdb

gcc-8 -Wp,-MD,/tmp/VisualKernel/c/Users/Mr/source/repos/LinuxKernelModule2/LinuxKernelModule2/.LinuxKernelModule2_main.o.d
-nostdinc
-isystem /usr/lib/gcc/arm-linux-gnueabihf/8/include -I/usr/src/linux-headers-4.19.0-6-common/arch/arm/include
-I./arch/arm/include/generated
-I/usr/src/linux-headers-4.19.0-6-common/include
-I./include
-I/usr/src/linux-headers-4.19.0-6-common/arch/arm/include/uapi
-I./arch/arm/include/generated/uapi
-I/usr/src/linux-headers-4.19.0-6-common/include/uapi
-I./include/generated/uapi
-include /usr/src/linux-headers-4.19.0-6-common/include/linux/kconfig.h
-include /usr/src/linux-headers-4.19.0-6-common/include/linux/compiler_types.h
-I/tmp/VisualKernel/c/Users/Mr/source/repos/LinuxKernelModule2/LinuxKernelModule2
-I/tmp/VisualKernel/c/Users/Mr/source/repos/LinuxKernelModule2/LinuxKernelModule2
-D__KERNEL__
-mlittle-endian
-Wall
-Wundef
-Wstrict-prototypes
-Wno-trigraphs
-fno-strict-aliasing
-fno-common
-fshort-wchar
-Werror-implicit-function-declaration
-Wno-format-security
-std=gnu89
-fno-PIE
-fno-dwarf2-cfi-asm
-fno-omit-frame-pointer
-mapcs
-mno-sched-prolog
-fno-ipa-sra
-mabi=aapcs-linux
-mfpu=vfp
-funwind-tables
-marm
-Wa,-mno-warn-deprecated
-D__LINUX_ARM_ARCH__=7
-march=armv7-a
-msoft-float
-Uarm
-fno-delete-null-pointer-checks
-Wno-frame-address
-Wno-format-truncation
-Wno-format-overflow
-Wno-int-in-bool-context
-O2
--param=allow-store-data-races=0
-Wframe-larger-than=1024
-fstack-protector-strong
-Wno-unused-but-set-variable
-Wno-unused-const-variable
-fno-omit-frame-pointer
-fno-optimize-sibling-calls
-fno-var-tracking-assignments
-g
-pg
-Wdeclaration-after-statement
-Wno-pointer-sign
-Wno-stringop-truncation
-fno-strict-overflow
-fno-merge-all-constants
-fmerge-constants
-fno-stack-check
-fconserve-stack
-Werror=implicit-int
-Werror=strict-prototypes
-Werror=date-time
-Werror=incompatible-pointer-types
-Werror=designated-init
-fmacro-prefix-map=/usr/src/linux-headers-4.19.0-6-common/=
-Wno-packed-not-aligned
-ggdb
-O0
-DMODULE
-DKBUILD_BASENAME='"LinuxKernelModule2_main"'
-DKBUILD_MODNAME='"LinuxKernelModule2"'
-c
-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.c

• This topic was modified 4 years, 4 months ago by Goerge255.
• This topic was modified 4 years, 4 months ago by Goerge255.
• This topic was modified 4 years, 4 months ago by Goerge255.
• This topic was modified 4 years, 4 months ago by Goerge255.

[Goerge255]

The sample “Hello World” LKM, built by most people in the Linux world, has a size of approximately 4kB.
See this post.

• This reply was modified 4 years, 4 months ago by Goerge255.

[support]

Hi,

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).

[Goerge255]

… 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 -g0 to CFLAGS  in Module Build Settings, since VK does not even respect changes made to that field (…the changes revert back after Project Properties window is reopened ) !

• This reply was modified 4 years, 4 months ago by Goerge255.

[support]

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.

[Author]

Posts