section name cleanup for parisc
cover section name cleanup for parisc
This patch series cleans up the section names on the parisc architecture. It requires the architecture-independent macro definitions from this patch series:
<http://www.spinics.net/lists/mips/msg33499.html>
The long-term goal here is to add support for building the kernel with -ffunction-sections -fdata-sections. This requires renaming all the magic section names in the kernel of the form .text.foo, .data.foo, .bss.foo, and .rodata.foo to not have collisions with sections generated for code like:
static int nosave = 0; /* -fdata-sections places in .data.nosave */ static void head(); /* -ffunction-sections places in .text.head */
Note that these patches have not been boot-tested (aside from testing the analogous changes on x86), since I don't have access to the appropriate hardware.
-Tim Abbott
Tim Abbott (5):
parisc: use NOSAVE_DATA macro for .data.nosave section.
parisc: use new macro for .data.cacheline_aligned section.
parisc: use new macros for .data.init_task.
parisc: use new macro for .data.read_mostly section.
parisc: convert to new generic read_mostly support.
arch/parisc/Kconfig | 3 +++ arch/parisc/include/asm/cache.h | 2 -- arch/parisc/kernel/head.S | 3 ++- arch/parisc/kernel/init_task.c | 2 +- arch/parisc/kernel/vmlinux.lds.S | 36 +++++------------------------------- 5 files changed, 11 insertions(+), 35 deletions(-)
PATCH 1/5 parisc: use NOSAVE_DATA macro for .data.nosave section.
.data.nosave should not need a separate output section; this change moves it into the .data section.
--- arch/parisc/kernel/vmlinux.lds.S | 12 +----------- 1 files changed, 1 insertions(+), 11 deletions(-)
arch/parisc/kernel/vmlinux.lds.S +1 -10
@@ -103,6 +103,7 @@ SECTIONS . = ALIGN(L1_CACHE_BYTES); /* Data */ .data : { + NOSAVE_DATA DATA_DATA CONSTRUCTORS }
@@ -118,17 +119,6 @@ SECTIONS *(.data.lock_aligned) } - /* nosave data is really only used for software suspend...it's here - * just in case we ever implement it - */ - . = ALIGN(PAGE_SIZE); - __nosave_begin = .; - .data_nosave : { - *(.data.nosave) - } - . = ALIGN(PAGE_SIZE); - __nosave_end = .;
PATCH 2/5 parisc: use new macro for .data.cacheline_aligned section.
.data.cacheline_aligned should not need a separate output section; this change moves it into the .data section.
--- arch/parisc/kernel/vmlinux.lds.S | 6 +----- 1 files changed, 1 insertions(+), 5 deletions(-)
arch/parisc/kernel/vmlinux.lds.S +1 -4
@@ -104,15 +104,11 @@ SECTIONS /* Data */ .data : { NOSAVE_DATA + CACHELINE_ALIGNED_DATA(L1_CACHE_BYTES) DATA_DATA CONSTRUCTORS } - . = ALIGN(L1_CACHE_BYTES); - .data.cacheline_aligned : { - *(.data.cacheline_aligned) - }
PATCH 3/5 parisc: use new macros for .data.init_task.
.data.init_task should not need a separate output section; this change moves it into the .data section.
--- arch/parisc/kernel/init_task.c | 2 +- arch/parisc/kernel/vmlinux.lds.S | 10 ++-------- 2 files changed, 3 insertions(+), 9 deletions(-)
arch/parisc/kernel/init_task.c +1 -1
@@ -48,7 +48,7 @@ EXPORT_SYMBOL(init_mm);* "init_task" linker map entry.. */ union thread_union init_thread_union - __attribute__((aligned(128))) __attribute__((__section__(".data.init_task"))) = + __attribute__((aligned(128))) __init_task_data = {INIT_THREAD_INFO (init_task) };#if PT_NLEVELS ==3
arch/parisc/kernel/vmlinux.lds.S +2 -7
@@ -103,6 +103,8 @@ SECTIONS . = ALIGN(L1_CACHE_BYTES); /* Data */ .data : { + /* assembler code expects init_task to be 16k aligned */ + INIT_TASK_DATA(16384) NOSAVE_DATA CACHELINE_ALIGNED_DATA(L1_CACHE_BYTES) DATA_DATA
@@ -133,14 +135,6 @@ SECTIONS } __bss_stop = .; - - /* assembler code expects init_task to be 16k aligned */ - . = ALIGN(16384); - /* init_task */ - .data.init_task : { - *(.data.init_task) - }
PATCH 4/5 parisc: use new macro for .data.read_mostly section.
.data.read_mostly should not need a separate output section; this change moves it into the .data section.
I used alignment L1_CACHE_BYTES instead of 16 since the whole point is for read-mostly data to have different cache lines than other stuff.
--- arch/parisc/kernel/vmlinux.lds.S | 8 +------- 1 files changed, 1 insertions(+), 7 deletions(-)
arch/parisc/kernel/vmlinux.lds.S +0 -5
@@ -94,19 +94,13 @@ SECTIONS __stop___unwind = .; } - /* rarely changed data like cpu maps */ - . = ALIGN(16); - .data.read_mostly : { - *(.data.read_mostly) - }
PATCH 5/5 parisc: convert to new generic read_mostly support.
--- arch/parisc/Kconfig | 3 +++ arch/parisc/include/asm/cache.h | 2 -- arch/parisc/kernel/head.S | 3 ++- 3 files changed, 5 insertions(+), 3 deletions(-)
arch/parisc/Kconfig +3 -0
@@ -101,6 +101,9 @@ config ARCH_MAY_HAVE_PC_FDC depends on BROKEN default y +config HAVE_READ_MOSTLY_DATA + def_bool y + source "init/Kconfig" source "kernel/Kconfig.freezer"
arch/parisc/include/asm/cache.h +0 -2
@@ -28,8 +28,6 @@#define SMP_CACHE_BYTES L1_CACHE_BYTES -#define __read_mostly __attribute__((__section__(".data.read_mostly"))) -void parisc_cache_init (void );/* initializes cache-flushing */ void disable_sr_hashing_asm (int );/* low level support for above */ void disable_sr_hashing (void );/* turns off space register hashing */
arch/parisc/kernel/head.S +2 -1
@@ -19,6 +19,7 @@ #include <asm/assembly.h> #include <asm/pgtable.h> +#include <linux/cache.h> #include <linux/linkage.h> #include <linux/init.h>
@@ -345,7 +346,7 @@ smp_slave_stext: ENDPROC(stext) #ifndef CONFIG_64BIT - .section .data.read_mostly + __READ_MOSTLY .align 4 .export $global$,data
Signature · 1 line
1.6.2.1
Helge Deller
maintainerRe: [PATCH 3/5] parisc: use new macros for .data.init_task.
In reply to Tim AbbottQuoted 7 lines · Tim Abbott
.data.init_task should not need a separate output section; this change moves it into the .data section.
Signed-off-by Tim Abbott <[email protected]>Cc Kyle McMartin <[email protected]>Cc Helge Deller <[email protected]>
I think this patch is wrong, although it is theoretically correct.
IIRC, gcc on hppa is not able to provide an alignment >= 8k, which is why we have done the 16k alignment inside the linker script. So, I think this change will prevent the parisc kernel to boot up. Needs testing.
Helge
Quoted 46 lines
--- arch/parisc/kernel/init_task.c | 2 +- arch/parisc/kernel/vmlinux.lds.S | 10 ++-------- 2 files changed, 3 insertions(+), 9 deletions(-)arch/parisc/kernel/init_task.c +1
-1@@ -48,7 +48,7 @@ EXPORT_SYMBOL(init_mm);* "init_task" linker map entry.. */ union thread_union init_thread_union - __attribute__((aligned(128))) __attribute__((__section__(".data.init_task"))) = + __attribute__((aligned(128))) __init_task_data = {INIT_THREAD_INFO (init_task) };#if PT_NLEVELS ==3 arch/parisc/kernel/vmlinux.lds.S +2
-8@@ -103,6 +103,8 @@ SECTIONS . = ALIGN(L1_CACHE_BYTES); /* Data */ .data : { + /* assembler code expects init_task to be 16k aligned */ + INIT_TASK_DATA(16384) NOSAVE_DATA CACHELINE_ALIGNED_DATA(L1_CACHE_BYTES) DATA_DATA@@ -133,14 +135,6 @@ SECTIONS } __bss_stop = .; - - /* assembler code expects init_task to be 16k aligned */ - . = ALIGN(16384); - /* init_task */ - .data.init_task : { - *(.data.init_task) - } - #ifdef CONFIG_64BIT . = ALIGN(16); /* Linkage tables */
Re: [PATCH 3/5] parisc: use new macros for .data.init_task.
Quoted 2 lines
IIRC, gcc on hppa is not able to provide an alignment >= 8k, which is why we have done the 16k alignment inside the linker script.
How does this arise? We have the following define for MAX_OFILE_ALIGNMENT in elfos.h:
#define MAX_OFILE_ALIGNMENT (((unsigned int) 1 << 28) * 8)
If you are correct, MAX_OFILE_ALIGNMENT should be changed.
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: [PATCH 3/5] parisc: use new macros for .data.init_task.
In reply to Helge DellerQuoted 7 lines · Helge Deller
I think this patch is wrong, although it is theoretically correct.
IIRC, gcc on hppa is not able to provide an alignment >= 8k, which is why we have done the 16k alignment inside the linker script. So, I think this change will prevent the parisc kernel to boot up. Needs testing.
I think you're confusing this with the 8-byte maximum alignment from kmalloc and on-stack that prevents us from just using a 16-byte aligned word as a lock on pa1.1?
The patch I trimmed from this mail looks correct to me.
regards, Kyle
Helge Deller
maintainerRe: [PATCH 3/5] parisc: use new macros for .data.init_task.
Quoted 9 lines · Kyle McMartin
Quoted 7 lines · Helge Deller
I think this patch is wrong, although it is theoretically correct.
IIRC, gcc on hppa is not able to provide an alignment >= 8k, which is why we have done the 16k alignment inside the linker script. So, I think this change will prevent the parisc kernel to boot up. Needs testing.
Quoted 3 lines
I think you're confusing this with the 8-byte maximum alignment from kmalloc and on-stack that prevents us from just using a 16-byte aligned word as a lock on pa1.1?
No, I was not confusing it with the 8byte-alignment.
I really meant that a > 8k alignment was not possible.
I tried exactly the same stuff once and failed.
I think the restriction came from hpux compatibility or some old gas...
Anyway, I just tried some assembly and it seems to work.
Quoted 1 line
The patch I trimmed from this mail looks correct to me.
If you apply it and it boots OK for you, I'm fine.
Helge
Re: [PATCH 3/5] parisc: use new macros for .data.init_task.
Quoted 3 lines
I really meant that a > 8k alignment was not possible.
I tried exactly the same stuff once and failed.
I think the restriction came from hpux compatibility or some old gas...
The maximum alignment on hpux is 4k bytes. This was implemented in 2004 in the PA backend for hpux. Prior to that, the default for MAX_OFILE_ALIGNMENT (BIGGEST_ALIGNMENT) was in effect for all PA targets. It looks like Carlos added the define to elfos.h in November 2006. So unless this was back ported, 4.2.0 would be the first gcc release to support large alignments on linux.
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: [PATCH 3/5] parisc: use new macros for .data.init_task.
In reply to Helge DellerQuoted 10 lines · Helge Deller
Quoted 7 lines · Tim Abbott
.data.init_task should not need a separate output section; this change moves it into the .data section.
Signed-off-by Tim Abbott <[email protected]>Cc Kyle McMartin <[email protected]>Cc Helge Deller <[email protected]>
Quoted 6 lines
I think this patch is wrong, although it is theoretically correct.
IIRC, gcc on hppa is not able to provide an alignment >= 8k, which is why we have done the 16k alignment inside the linker script. So, I think this change will prevent the parisc kernel to boot up. Needs testing.
The patch does not do much...
Quoted 8 lines
Helge
Quoted 5 lines
--- arch/parisc/kernel/init_task.c | 2 +- arch/parisc/kernel/vmlinux.lds.S | 10 ++-------- 2 files changed, 3 insertions(+), 9 deletions(-)
Quoted 11 lines
arch/parisc/kernel/init_task.c EXPORT_SYMBOL(init_mm); · line 52
Quoted 11 lines
arch/parisc/kernel/init_task.c +1
-1@@ -48,7 +48,7 @@ EXPORT_SYMBOL(init_mm);* "init_task" linker map entry.. */ union thread_union init_thread_union - __attribute__((aligned(128))) __attribute__((__section__(".data.init_task"))) = + __attribute__((aligned(128))) __init_task_data = {INIT_THREAD_INFO (init_task) };
This is a simple replacement with a nicer way to say "this belongs to the .data.init_task section - no functional difference.
Quoted 19 lines
Quoted 19 lines
arch/parisc/kernel/init_task.c +0
-0#if PT_NLEVELS ==3 arch/parisc/kernel/vmlinux.lds.S +2
-0@@ -103,6 +103,8 @@ SECTIONS . = ALIGN(L1_CACHE_BYTES); /* Data */ .data : { + /* assembler code expects init_task to be 16k aligned */ + INIT_TASK_DATA(16384) NOSAVE_DATA CACHELINE_ALIGNED_DATA(L1_CACHE_BYTES) DATA_DATA@@ -133,14 +135,6 @@ SECTIONS } __bss_stop = .;
Quoted 8 lines
arch/parisc/kernel/vmlinux.lds.S SECTIONS
Quoted 8 lines
arch/parisc/kernel/vmlinux.lds.S +0
-8- - /* assembler code expects init_task to be 16k aligned */ - . = ALIGN(16384); - /* init_task */ - .data.init_task : { - *(.data.init_task) - } -
This part moves away from a specific output section to including this in the .data output section - with the _same_ alignmnet.
So the only issue here is that we move init_task before NOSAVE_DATA etc.
I do not see why you think this changes alignmnet?
Sam
Helge Deller
maintainerRe: [PATCH 3/5] parisc: use new macros for .data.init_task.
Quoted 72 lines · Sam Ravnborg
Quoted 9 lines · Helge Deller
Quoted 7 lines · Tim Abbott
.data.init_task should not need a separate output section; this change moves it into the .data section.
Signed-off-by Tim Abbott <[email protected]>Cc Kyle McMartin <[email protected]>Cc Helge Deller <[email protected]>Quoted 6 lines
I think this patch is wrong, although it is theoretically correct.
IIRC, gcc on hppa is not able to provide an alignment >= 8k, which is why we have done the 16k alignment inside the linker script. So, I think this change will prevent the parisc kernel to boot up. Needs testing.
The patch does not do much...
Quoted 7 lines
Helge
Quoted 5 lines
--- arch/parisc/kernel/init_task.c | 2 +- arch/parisc/kernel/vmlinux.lds.S | 10 ++-------- 2 files changed, 3 insertions(+), 9 deletions(-)Quoted 11 lines
arch/parisc/kernel/init_task.c EXPORT_SYMBOL(init_mm); · line 52
Quoted 11 lines
arch/parisc/kernel/init_task.c +1
-1@@ -48,7 +48,7 @@ EXPORT_SYMBOL(init_mm);* "init_task" linker map entry.. */ union thread_union init_thread_union - __attribute__((aligned(128))) __attribute__((__section__(".data.init_task"))) = + __attribute__((aligned(128))) __init_task_data = {INIT_THREAD_INFO (init_task) };This is a simple replacement with a nicer way to say "this belongs to the .data.init_task section - no functional difference.
Quoted 19 lines
Quoted 19 lines
arch/parisc/kernel/init_task.c +0
-0#if PT_NLEVELS ==3 arch/parisc/kernel/vmlinux.lds.S +2
-0@@ -103,6 +103,8 @@ SECTIONS . = ALIGN(L1_CACHE_BYTES); /* Data */ .data : { + /* assembler code expects init_task to be 16k aligned */ + INIT_TASK_DATA(16384) NOSAVE_DATA CACHELINE_ALIGNED_DATA(L1_CACHE_BYTES) DATA_DATA@@ -133,14 +135,6 @@ SECTIONS } __bss_stop = .;Quoted 8 lines
arch/parisc/kernel/vmlinux.lds.S SECTIONS
Quoted 8 lines
arch/parisc/kernel/vmlinux.lds.S +0
-8- - /* assembler code expects init_task to be 16k aligned */ - . = ALIGN(16384); - /* init_task */ - .data.init_task : { - *(.data.init_task) - } -This part moves away from a specific output section to including this in the .data output section - with the _same_ alignmnet.
So the only issue here is that we moveinit_taskbeforeNOSAVE_DATAetc.
Quoted 1 line
I do not see why you think this changes alignmnet?
Ugh. Of course you are correct. It doesn't change anything. Patch is OK for me.
I missed the 16384 in INIT_TASK_DATA(16384).
Thanks,
Helge
Quoted 22 lines · Tim Abbott
This patch series cleans up the section names on the parisc architecture. It requires the architecture-independent macro definitions from this patch series:
<http://www.spinics.net/lists/mips/msg33499.html>
The long-term goal here is to add support for building the kernel with -ffunction-sections -fdata-sections. This requires renaming all the magic section names in the kernel of the form .text.foo, .data.foo, .bss.foo, and .rodata.foo to not have collisions with sections generated for code like:
static int nosave = 0; /* -fdata-sections places in .data.nosave */ static void
head(); /* -ffunction-sections places in .text.head */Note that these patches have not been boot-tested (aside from testing the analogous changes on x86), since I don't have access to the appropriate hardware.
-Tim Abbott
Quoted 7 lines
Tim Abbott (5):
parisc: useNOSAVE_DATAmacro for .data.nosave section.
parisc: use new macro for .data.cacheline_aligned section.
parisc: use new macros for .data.init_task.
parisc: use new macro for .data.read_mostly section.
parisc: convert to new genericread_mostlysupport.
Not sure what the easiest way to merge these will be... I'll apply them to a section-cleanup branch in the parisc git tree until the architecture independent portions are upstream.
regards, Kyle
Quoted 31 lines · Kyle McMartin
Quoted 22 lines · Tim Abbott
This patch series cleans up the section names on the parisc architecture. It requires the architecture-independent macro definitions from this patch series:
<http://www.spinics.net/lists/mips/msg33499.html>
The long-term goal here is to add support for building the kernel with -ffunction-sections -fdata-sections. This requires renaming all the magic section names in the kernel of the form .text.foo, .data.foo, .bss.foo, and .rodata.foo to not have collisions with sections generated for code like:
static int nosave = 0; /* -fdata-sections places in .data.nosave */ static void
head(); /* -ffunction-sections places in .text.head */Note that these patches have not been boot-tested (aside from testing the analogous changes on x86), since I don't have access to the appropriate hardware.
-Tim Abbott
Quoted 7 lines
Tim Abbott (5):
parisc: useNOSAVE_DATAmacro for .data.nosave section.
parisc: use new macro for .data.cacheline_aligned section.
parisc: use new macros for .data.init_task.
parisc: use new macro for .data.read_mostly section.
parisc: convert to new genericread_mostlysupport.
Quoted 3 lines
Not sure what the easiest way to merge these will be... I'll apply them to a section-cleanup branch in the parisc git tree until the architecture independent portions are upstream.
I expect the parisc stuff to be redone. I'm working at the arch independent stuff atm and will post a new patch later this weekend. That will make the current patch obsolete.
Sam