From: Denys Vlasenko <vda.linux@googlemail.com>
To: sam@ravnborg.org, kai@germaschewski.name
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH 0/3] build system: section garbage collection for vmlinux
Date: Wed, 5 Sep 2007 14:43:21 +0100 [thread overview]
Message-ID: <200709051443.21522.vda.linux@googlemail.com> (raw)
Build system: section garbage collection for vmlinux
Newer gcc and binutils can do dead code and data removal
at link time. It is achieved using combination of
-ffunction-sections -fdata-sections options for gcc and
--gc-sections for ld.
Theory of operation:
Option -ffunction-sections instructs gcc to place each function
(including static ones) in it's own section named .text.function_name
instead of placing all functions in one big .text section.
At link time, ld normally coalesce all such sections into one
output section .text again. It is achieved by having *(.text.*) spec
along with *(.text) spec in built-in linker scripts.
If ld is invoked with --gc-sections, it tracks references, starting
from entry point and marks all input sections which are reachable
from there. Then it discards all input sections which are not marked.
This isn't buying much if you have one big .text section per .o module,
because even one referenced function will pull in entire section.
You need -ffunction-sections in order to split .text into per-function
sections and make --gc-sections much more useful.
-fdata-sections is analogous: it places each global or static variable
into .data.variable_name, .rodata.variable_name or .bss.variable_name.
How to use it in kernel:
First, we need to adapt existing code for new section names.
Basically, we need to stop using section names of the form
.text.xxxx
.data.xxxx
.rodata.xxxx
.bss.xxxx
in the kernel for - otherwise section placement done by kernel's
custom linker scripts produces broken vmlinux and vdso images.
Second, kernel linker scripts need to be adapted by adding KEEP(xxx)
directives around sections which are not directly referenced, but are
nevertheless used (initcalls, altinstructions, etc).
These patches fix section names and add
CONFIG_DISCARD_UNUSED_SECTIONS. It is not enabled
unconditionally because only newest binutils have
ld --gc-sections which is stable enough for kernel use.
IOW: this is an experimental feature for now.
Patches are conservative and mark a lot of things with
KEEP() directive in linker script, inhibiting GC for them.
Size savings are modest:
text data bss dec hex filename
5159478 1005139 406784 6571401 644589 linux-2.6.23-rc4.org/vmlinux
5131822 996090 401439 6529351 63a147 linux-2.6.23-rc4.gc/vmlinux
In this particular case, 402 objects were discarded, saving 42 kb.
Linker is unable to discard more because current infrastructure
is a bit flawed in this regard. It prevents some unused code
from being detected. In particular:
KEEP(__ex_table) -> .fixup -> get_user and friends
KEEP(.smp_locks) -> lock prefixes
This is an experimental build where KEEPs for them were removed:
text data bss dec hex filename
5131822 996090 401439 6529351 63a147 vmlinux
5065681 996090 401439 6463210 629eea vmlinux.sans_KEEP
52k of difference are due to __ex_table and .smp_locks being removed,
the remaining ~13k is genuinely unused .text.* sections.
Patches were run-tested on x86_64, and likely do not work on any other arch
(need to add KEEP() to arch/*/kernel/vmlinux.lds.S for each arch).
--
vda
next reply other threads:[~2007-09-05 13:43 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-05 13:43 Denys Vlasenko [this message]
2007-09-05 13:47 ` [PATCH 1/3] build system: section garbage collection for vmlinux Denys Vlasenko
2007-09-05 13:49 ` [PATCH 2/3] " Denys Vlasenko
2007-09-05 13:55 ` [PATCH 3/3] " Denys Vlasenko
2007-09-05 18:40 ` Denys Vlasenko
2007-09-05 20:46 ` Sam Ravnborg
2007-09-06 10:55 ` Denys Vlasenko
2007-09-06 22:33 ` Sam Ravnborg
2007-09-10 12:01 ` Sam Ravnborg
2007-09-10 19:02 ` Denys Vlasenko
2007-09-10 19:14 ` Sam Ravnborg
2007-09-11 11:23 ` Denys Vlasenko
2007-09-11 11:55 ` Sam Ravnborg
2007-09-05 20:07 ` [PATCH 1/3] " Sam Ravnborg
2007-09-06 10:59 ` Denys Vlasenko
2007-09-06 22:36 ` Sam Ravnborg
2007-09-08 15:02 ` Denys Vlasenko
2007-09-05 15:53 ` [PATCH 0/3] " Oleg Verych
2007-09-05 18:46 ` Denys Vlasenko
2007-09-05 20:34 ` Oleg Verych
2007-09-05 21:52 ` Adrian Bunk
2007-09-06 10:55 ` Denys Vlasenko
2007-09-06 11:40 ` Oleg Verych
2007-09-06 12:21 ` Adrian Bunk
2007-09-06 20:43 ` Oleg Verych
2007-09-06 20:39 ` Adrian Bunk
2007-09-06 21:16 ` Oleg Verych
2007-09-06 21:19 ` Adrian Bunk
2007-09-06 22:01 ` Oleg Verych
2007-09-06 22:43 ` Adrian Bunk
2007-09-06 12:33 ` Denys Vlasenko
2007-09-05 16:29 ` Daniel Walker
2007-09-05 18:37 ` Denys Vlasenko
2007-09-05 18:38 ` Daniel Walker
2007-09-05 19:14 ` Denys Vlasenko
2007-09-05 19:07 ` Daniel Walker
2007-09-05 19:49 ` Denys Vlasenko
2007-09-05 19:46 ` Daniel Walker
2007-09-06 10:57 ` Denys Vlasenko
2007-09-06 15:13 ` Daniel Walker
2007-09-06 17:07 ` Denys Vlasenko
2007-09-07 16:31 ` Daniel Walker
2007-09-07 17:24 ` Sam Ravnborg
2007-09-07 17:19 ` Daniel Walker
2007-09-07 17:30 ` Denys Vlasenko
2007-09-07 17:38 ` Daniel Walker
2007-09-05 19:31 ` Adrian Bunk
2007-09-05 19:24 ` Daniel Walker
2007-09-05 19:46 ` Adrian Bunk
2007-09-05 19:27 ` Adrian Bunk
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=200709051443.21522.vda.linux@googlemail.com \
--to=vda.linux@googlemail.com \
--cc=kai@germaschewski.name \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.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