public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: josh@joshtriplett.org
To: "Peter Hüwe" <PeterHuewe@gmx.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: .exit.text section in vmlinux ?
Date: Tue, 21 Oct 2014 16:35:18 -0700	[thread overview]
Message-ID: <20141021233518.GA15840@cloud> (raw)
In-Reply-To: <201410212319.20340.PeterHuewe@gmx.de>

On Tue, Oct 21, 2014 at 11:19:01PM +0200, Peter Hüwe wrote:
> as far as I remember everything marked with __exit or __exit_data will only be 
> used/called when unloading a module, and gets moved to the .exit.text or 
> .exit.data sections.
> 
> Why are these sections present in the vmlinux/vmlinux.bin/bzImage and not 
> dropped by the linker or at least objdump? 
> This code will never be called for everything compiled in - in an allyesconfig 
> build these sections account for ~80kb of code.
> 
> Is there something I'm missing here, or can we add "--remove-section 
> .exit.data --remove-section .exit.text" to the OBJCOPYFLAGS for vmlinux?

Good catch!  I didn't realize that section even appeared in vmlinux; it
should be entirely omitted.

Removing it via objcopy would work, but seems suboptimal, since that
won't let the compiler know the functions are unused (and thus that it
can throw away code and data only referenced from __exit, or inline
functions into their now-only caller, etc).  So, ideally, when compiling
code in the kernel rather than in modules, we should tell the compiler
enough to omit functions tagged as __exit.

(Also, in the course of working on this, I discovered that several
files declare functions as "static inline ... __exit", which makes no
sense, and which actually forces an out-of-line version to exist even if
the function has no body.  For instance, exit_amd_microcode and
bcma_host_soc_unregister_driver.)

The following patch seems to mostly do the right thing, though for some
reason some __exit functions remain in the final binary (such as
md_exit and mon_exit):

--->8---
>From 1646d051a4a4c18b9a6163fceabcafa20628c728 Mon Sep 17 00:00:00 2001
From: Josh Triplett <josh@joshtriplett.org>
Date: Tue, 21 Oct 2014 16:14:19 -0700
Subject: [PATCH] linux/init.h: Always omit __exit code and data for in-kernel
 compilation

__exit code and data only exists for module removal; when compiling such
code in the kernel, omit the __exit functions to save space.  For x86
defconfig this saves about 9k, and significantly more in the compiled
binary size.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
 include/linux/init.h | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/include/linux/init.h b/include/linux/init.h
index 2df8e8d..daa329d 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -42,8 +42,14 @@
 #define __init		__section(.init.text) __cold notrace
 #define __initdata	__section(.init.data)
 #define __initconst	__constsection(.init.rodata)
+
+#ifdef MODULE
 #define __exitdata	__section(.exit.data)
 #define __exit_call	__used __section(.exitcall.exit)
+#else
+#define __exitdata	__always_unused
+#define __exit_call	__always_unused
+#endif
 
 /*
  * Some architecture have tool chains which do not handle rodata attributes
@@ -89,7 +95,11 @@
 #define __exitused  __used
 #endif
 
-#define __exit          __section(.exit.text) __exitused __cold notrace
+#ifdef MODULE
+#define __exit          __section(.exit.text) __cold notrace
+#else
+#define __exit          __always_unused
+#endif
 
 /* temporary, until all users are removed */
 #define __cpuinit
-- 
2.1.1


  reply	other threads:[~2014-10-21 23:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-21 21:19 .exit.text section in vmlinux ? Peter Hüwe
2014-10-21 23:35 ` josh [this message]
2014-10-21 23:56   ` Stephen Boyd
2014-10-22  0:10     ` Stephen Boyd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141021233518.GA15840@cloud \
    --to=josh@joshtriplett.org \
    --cc=PeterHuewe@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox