- This topic has 4 replies, 2 voices, and was last updated 4 years, 11 months ago by
.
-
Posts
-
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
Project Properties/Module build settingsthere are options to addAdditional Make argumentsandCFLAGS…but no option to remove a flag like the-ggdbgcc-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.cThe sample “Hello World” LKM, built by most people in the Linux world, has a size of approximately 4kB.
See this post.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).
… 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-g0toCFLAGSinModule Build Settings, since VK does not even respect changes made to that field (…the changes revert back after Project Properties window is reopened ) !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.