[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100723202448.GB27054@merkur.ravnborg.org>
Date: Fri, 23 Jul 2010 22:24:49 +0200
From: Sam Ravnborg <sam@...nborg.org>
To: Denys Vlasenko <vda.linux@...glemail.com>
Cc: Tim Abbott <tabbott@...lice.com>, Tim Bird <tim.bird@...sony.com>,
James Bottomley <James.Bottomley@...senpartnership.com>,
linux-kernel@...r.kernel.org,
Matt Fleming <matt@...sole-pimps.org>,
linux-arch@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
Michal Marek <mmarek@...e.cz>,
Parisc List <linux-parisc@...r.kernel.org>
Subject: Re: Testing of function/data-sections on linux-2.6.35-rc4
> * fix for kernel linker stripts: linux-2.6.35-rc4-fs.fix-kernel-linker-scripts.patch
> It makes _all_ linker scripts -ffunction/data-sections safe via:
> - *(.data)
> + *(.data .data.*)
>
This patch touches both the regular kernel linker scripts and the
boot linker scripts.
I would strongly prefer a split so you touched the boot linker
scripts in a separate patch.
In addition the patch handles more sections than
documented: rodata, bss, text.
The patch introduce the following syntax for input sections:
*(.bss .bss.*)
Where the kernel linker script would have one input
section per line.
Can we stick to the "layout" used in the kernel linker scripts?
The patch in addition in several places changes linker
scripts that already uses the two-lines layout to a single line approach.
These "fixes" should be omitted.
Why do we need *(.bss .bss.*)?
Does -fdata-sections introduce special .bss sectiosn too?
This is the kind of info the changelog should give us.
Sam
--- linux-2.6.35-rc4/arch/arm/boot/compressed/vmlinux.lds.in
+++ linux-2.6.35-rc4.new/arch/arm/boot/compressed/vmlinux.lds.in
@@ -29,12 +29,10 @@
.text : {
_start = .;
*(.start)
- *(.text)
- *(.text.*)
+ *(.text .text.*)
*(.fixup)
*(.gnu.warning)
- *(.rodata)
- *(.rodata.*)
+ *(.rodata .rodata.*)
*(.glue_7)
*(.glue_7t)
*(.piggydata)
This is one example where the patch only does layout changes.
--- linux-2.6.35-rc4/arch/arm/kernel/vmlinux.lds.S
+++ linux-2.6.35-rc4.new/arch/arm/kernel/vmlinux.lds.S
@@ -95,8 +95,7 @@
*(.fixup)
#endif
*(.gnu.warning)
- *(.rodata)
- *(.rodata.*)
+ *(.rodata .rodata.*)
*(.glue_7)
*(.glue_7t)
Likewise...
--- linux-2.6.35-rc4/arch/frv/kernel/vmlinux.lds.S
+++ linux-2.6.35-rc4.new/arch/frv/kernel/vmlinux.lds.S
@@ -114,7 +114,7 @@
.sbss : { *(.sbss .sbss.*) }
.bss : { *(.bss .bss.*) }
- .bss..stack : { *(.bss) }
+ .bss..stack : { *(.bss) } /* BUG??? we already absorbed it into .bss */
As the comments says the last line is redundant - remove it.
--- linux-2.6.35-rc4/include/asm-generic/vmlinux.lds.h
+++ linux-2.6.35-rc4.new/include/asm-generic/vmlinux.lds.h
@@ -140,9 +140,21 @@
#define TRACE_SYSCALLS()
#endif
+/* .data.foo are generated by gcc itself with -fdata-sections,
+ * whereas double-dot sections (like .data..percpu) are generated
+ * by kernel's magic macros.
+ *
+ * arch/.../vmlinux.lds.S decides where to place various double-dot sections
+ * as needed by its arch, here DATA_DATA needs to be careful and collect
+ * only .data and .data.foo sections, skipping .data..foo
+ *
+ * Same goes for .text, .bss and .rodata. In case of .rodata, various
+ * .rodata.foo sections are generated by gcc even without -fdata-sections
+ */
+
/* .data section */
#define DATA_DATA \
- *(.data) \
+ *(.data .data.[A-Za-z0-9_$^]*) \
*(.ref.data) \
DEV_KEEP(init.data) \
DEV_KEEP(exit.data) \
@@ -202,7 +214,7 @@
. = ALIGN((align)); \
.rodata : AT(ADDR(.rodata) - LOAD_OFFSET) { \
VMLINUX_SYMBOL(__start_rodata) = .; \
- *(.rodata) *(.rodata.*) \
+ *(.rodata .rodata.[A-Za-z0-9_$^]*) \
.rodata deserve same comment as .data
*(__vermagic) /* Kernel version magic */ \
*(__markers_strings) /* Markers: strings */ \
*(__tracepoints_strings)/* Tracepoints: strings */ \
@@ -501,7 +513,7 @@
.bss : AT(ADDR(.bss) - LOAD_OFFSET) { \
*(.bss..page_aligned) \
*(.dynbss) \
- *(.bss) \
+ *(.bss .bss.[A-Za-z0-9_$^]*) \
.bss deserve a comment too.
Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists