* .exit.text section in vmlinux ? @ 2014-10-21 21:19 Peter Hüwe 2014-10-21 23:35 ` josh 0 siblings, 1 reply; 4+ messages in thread From: Peter Hüwe @ 2014-10-21 21:19 UTC (permalink / raw) To: linux-kernel, Josh Triplett Hi, 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? Thanks, Peter ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: .exit.text section in vmlinux ? 2014-10-21 21:19 .exit.text section in vmlinux ? Peter Hüwe @ 2014-10-21 23:35 ` josh 2014-10-21 23:56 ` Stephen Boyd 0 siblings, 1 reply; 4+ messages in thread From: josh @ 2014-10-21 23:35 UTC (permalink / raw) To: Peter Hüwe; +Cc: linux-kernel 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 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: .exit.text section in vmlinux ? 2014-10-21 23:35 ` josh @ 2014-10-21 23:56 ` Stephen Boyd 2014-10-22 0:10 ` Stephen Boyd 0 siblings, 1 reply; 4+ messages in thread From: Stephen Boyd @ 2014-10-21 23:56 UTC (permalink / raw) To: josh, Peter Hüwe; +Cc: linux-kernel On 10/21/2014 04:35 PM, josh@joshtriplett.org wrote: > 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. Does it boot? Usually we can't get rid of the exit section because we have some table pointing at it somewhere for bug tables, alternatives, etc. See this comment in arch/x86/kernel/vmlinux.lds.S for example: /* * .exit.text is discard at runtime, not link time, to deal with * references from .altinstructions and .eh_frame */ .exit.text : AT(ADDR(.exit.text) - LOAD_OFFSET) { EXIT_TEXT } .exit.data : AT(ADDR(.exit.data) - LOAD_OFFSET) { EXIT_DATA } -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: .exit.text section in vmlinux ? 2014-10-21 23:56 ` Stephen Boyd @ 2014-10-22 0:10 ` Stephen Boyd 0 siblings, 0 replies; 4+ messages in thread From: Stephen Boyd @ 2014-10-22 0:10 UTC (permalink / raw) To: josh, Peter Hüwe; +Cc: linux-kernel On 10/21/2014 04:56 PM, Stephen Boyd wrote: > On 10/21/2014 04:35 PM, josh@joshtriplett.org wrote: >> --->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. > Does it boot? Usually we can't get rid of the exit section because we > have some table pointing at it somewhere for bug tables, alternatives, > etc. See this comment in arch/x86/kernel/vmlinux.lds.S for example: > > /* > * .exit.text is discard at runtime, not link time, to deal with > * references from .altinstructions and .eh_frame > */ > .exit.text : AT(ADDR(.exit.text) - LOAD_OFFSET) { > EXIT_TEXT > } > > .exit.data : AT(ADDR(.exit.data) - LOAD_OFFSET) { > EXIT_DATA > } > > Furthermore, on ARM we discard the exit text and exit data in the linker script if we're not using the generic bug tables or patching spinlocks for uniprocessor hardware (see arch/arm/kernel/vmlinux.lds.S). Maybe something similar can be done for x86? #if (defined(CONFIG_SMP_ON_UP) && !defined(CONFIG_DEBUG_SPINLOCK)) || \ defined(CONFIG_GENERIC_BUG) #define ARM_EXIT_KEEP(x) x #define ARM_EXIT_DISCARD(x) #else #define ARM_EXIT_KEEP(x) #define ARM_EXIT_DISCARD(x) x #endif -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-10-22 0:11 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-10-21 21:19 .exit.text section in vmlinux ? Peter Hüwe 2014-10-21 23:35 ` josh 2014-10-21 23:56 ` Stephen Boyd 2014-10-22 0:10 ` Stephen Boyd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox