I haven't compiled Linux kernels in a couple of years, and now that I started doing so again I discovered that modules are installed with debug symbols by default unless INSTALL_MOD_STRIP=1 is passed to make modules_install, which makes them so enormous that my initrd images grew to be hundreds of megabytes.

I only found the INSTALL_MOD_STRIP option after googling around quite a bit, and even then only in forum threads where people ask why their modules are so large.

So I'm wondering, what is the reason this changed in the while I used precompiled kernels? Is there a reason modules are now installed with debug symbols by default (even though binary distributions still strip them off)? It seems rather esoteric to use debug symbols in the kernel, and it obviously has very large drawbacks in terms of installed size.

Basically, should I just consider INSTALL_MOD_STRIP as a part of the standard kernel compilation formula? Are there any other changes to the build process from around ~2.6.25 that I should be aware of?

  • That's quite a broad question, in short I'd say if you find yourself hand-crafting a kernel build you're either a module/kernel developer or you know what you're doing. Documentation/kbuild/*.txt should bring you up to date re the actual build process – hroptatyr Jan 22 '14 at 7:24

I'm just posting the log message from the relevant patch to answer your question who/why it got changed:

commit 2ea038917bbdd51a7ae4a898c6a04641324dd033
Author: Sam Ravnborg <sam@ravnborg.org>
Date:   Wed Jan 14 21:38:20 2009 +0100

Revert "kbuild: strip generated symbols from *.ko"

This reverts commit ad7a953c522ceb496611d127e51e278bfe0ff483.

And commit: ("allow stripping of generated symbols under CONFIG_KALLSYMS_ALL")

These stripping patches has caused a set of issues:

1) People have reported compatibility issues with binutils due to
   lack of support for `--strip-unneeded-symbols' with objcopy
   Reported by: Wenji
2) ccache and distcc no longer works as expeced
   Reported by: Ted, Roland, + others
3) The installed modules increased a lot in size
   Reported by: Ted, Davej + others

Reported-by: Wenji Huang <wenji.huang@oracle.com>
Reported-by: "Theodore Ts'o" <tytso@mit.edu>
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
  • Thanks for the idea to trace the history of the changes. I'll be doing that, but so far it doesn't seem to answer my basic question; namely what the rational for including debug symbols by default is, and why stripping installed modules is not the default behavior. – Dolda2000 Jan 25 '14 at 4:39
  • Well in general it does no harm (apart from making the binary larger, which admittedly in the case of the kernel is a valid point), it's not the default behaviour because of the 3 reasons mentioned: incompatibility with binutils, ccache and distcc problems and despite being stripped the modules increase in size – hroptatyr Jan 27 '14 at 6:28
  • That does not seem quite true. The commit you quoted only reverts changes to the stripping behavior, but INSTALL_MOD_STRIP existed long before that. As far as I can tell, it was introduced in commit ac031f26e8, which only mentions it as the solution to the problem of huge modules. – Dolda2000 Jan 27 '14 at 6:36
  • Also, I should mention that, at least as far as I remember (though it's been a while by now), the reason I had to go and find INSTALL_MOD_STRIP to begin with was that my initrd images grew so large without it that Grub wouldn't even accept them, in which case it's not entirely true that not stripping "does no harm". – Dolda2000 Jan 27 '14 at 6:37
  • Well I meant it does no harm in the general case, I did say kernel binaries are questionable here, as size does matter. That being said in my experience, at least with recent initrd formats (that can be compressed at least since about Apr 2000, far before INSTALL_MOD_STIP has been introduced), the overhead isn't that much of a problem because the sym table is quite redundant. – hroptatyr Jan 27 '14 at 6:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.