ARM kernel size fixes

PATCH Superseded Ard Biesheuvel 4 participants 25 messages Mar 12, 2015 – Mar 13, 2015

Subsystems (2)

Arm (32-bit) Arm/faraday FA526 port

lore

Share & tools

lore

Ard Biesheuvel

author

2015-03-12 17:38 UTC #0 lore raw

cover ARM kernel size fixes

This series is a suggested approach to preventing linker failures on large kernels. It is somewhat unpolished, and posted for comments/testing primarily.

The issues were found and reported by Arnd Bergmann, and these patches are loosely based on his initial approach to work around them.

Ard Biesheuvel (6):
ARM: replace PROCINFO embedded branch with relative offset
ARM: move HYP text to end of .text section
ARM: add macro to perform far branches (b/bl)
ARM: use bl_far to call __hyp_stub_install_secondary from the .data
section
ARM: move the .idmap.text section closer to .head.text
ARM: keep .text and .fixup regions together

 arch/arm/include/asm/assembler.h | 29 +++++++++++++++++++++++++++++
 arch/arm/kernel/head.S           | 14 ++++++++------
 arch/arm/kernel/sleep.S          |  2 +-
 arch/arm/kernel/vmlinux.lds.S    | 16 ++++++++++------
 arch/arm/kvm/init.S              |  5 +----
 arch/arm/kvm/interrupts.S        |  4 +---
 arch/arm/mm/proc-arm1020.S       |  4 ++--
 arch/arm/mm/proc-arm1020e.S      |  4 ++--
 arch/arm/mm/proc-arm1022.S       |  4 ++--
 arch/arm/mm/proc-arm1026.S       |  4 ++--
 arch/arm/mm/proc-arm720.S        |  4 ++--
 arch/arm/mm/proc-arm740.S        |  4 ++--
 arch/arm/mm/proc-arm7tdmi.S      |  4 ++--
 arch/arm/mm/proc-arm920.S        |  4 ++--
 arch/arm/mm/proc-arm922.S        |  4 ++--
 arch/arm/mm/proc-arm925.S        |  4 ++--
 arch/arm/mm/proc-arm926.S        |  4 ++--
 arch/arm/mm/proc-arm940.S        |  4 ++--
 arch/arm/mm/proc-arm946.S        |  4 ++--
 arch/arm/mm/proc-arm9tdmi.S      |  4 ++--
 arch/arm/mm/proc-fa526.S         |  4 ++--
 arch/arm/mm/proc-feroceon.S      |  5 +++--
 arch/arm/mm/proc-macros.S        |  4 ++++
 arch/arm/mm/proc-mohawk.S        |  4 ++--
 arch/arm/mm/proc-sa110.S         |  4 ++--
 arch/arm/mm/proc-sa1100.S        |  4 ++--
 arch/arm/mm/proc-v6.S            |  4 ++--
 arch/arm/mm/proc-v7.S            |  4 ++--
 arch/arm/mm/proc-v7m.S           |  4 ++--
 arch/arm/mm/proc-xsc3.S          |  4 ++--
 arch/arm/mm/proc-xscale.S        |  4 ++--
 31 files changed, 103 insertions(+), 68 deletions(-)

Signature · 1 line

1.8.3.2

Ard Biesheuvel

author

2015-03-12 17:38 UTC #1 lore raw

PATCH 1/6 ARM: replace PROCINFO embedded branch with relative offset

This patch replaces the 'branch to setup()' instructions embedded in the PROCINFO structs with the offset to that setup function relative to the base of the struct. This preserves the position independent nature of that field, but uses a data item rather than an instruction.

This is mainly done to prevent linker failures on large kernels, where the setup function is out of reach for the branch.

Signed-off-by Ard Biesheuvel <[email protected]>

---
 arch/arm/kernel/head.S      | 14 ++++++++------
 arch/arm/mm/proc-arm1020.S  |  4 ++--
 arch/arm/mm/proc-arm1020e.S |  4 ++--
 arch/arm/mm/proc-arm1022.S  |  4 ++--
 arch/arm/mm/proc-arm1026.S  |  4 ++--
 arch/arm/mm/proc-arm720.S   |  4 ++--
 arch/arm/mm/proc-arm740.S   |  4 ++--
 arch/arm/mm/proc-arm7tdmi.S |  4 ++--
 arch/arm/mm/proc-arm920.S   |  4 ++--
 arch/arm/mm/proc-arm922.S   |  4 ++--
 arch/arm/mm/proc-arm925.S   |  4 ++--
 arch/arm/mm/proc-arm926.S   |  4 ++--
 arch/arm/mm/proc-arm940.S   |  4 ++--
 arch/arm/mm/proc-arm946.S   |  4 ++--
 arch/arm/mm/proc-arm9tdmi.S |  4 ++--
 arch/arm/mm/proc-fa526.S    |  4 ++--
 arch/arm/mm/proc-feroceon.S |  5 +++--
 arch/arm/mm/proc-macros.S   |  4 ++++
 arch/arm/mm/proc-mohawk.S   |  4 ++--
 arch/arm/mm/proc-sa110.S    |  4 ++--
 arch/arm/mm/proc-sa1100.S   |  4 ++--
 arch/arm/mm/proc-v6.S       |  4 ++--
 arch/arm/mm/proc-v7.S       |  4 ++--
 arch/arm/mm/proc-v7m.S      |  4 ++--
 arch/arm/mm/proc-xsc3.S     |  4 ++--
 arch/arm/mm/proc-xscale.S   |  4 ++--
 26 files changed, 61 insertions(+), 54 deletions(-)

arch/arm/kernel/head.S +8 -6

index 01963273c07a..698b38bfca8f 100644
@@ -138,8 +138,9 @@ ENTRY(stext)
 						@ mmu has been enabled
 	adr	lr, BSYM(1f)			@ return (PIC) address
 	mov	r8, r4				@ set TTBR1 to swapper_pg_dir
- ARM(	add	pc, r10, #PROCINFO_INITFUNC	)
- THUMB(	add	r12, r10, #PROCINFO_INITFUNC	)
+	ldr	r12, [r10, #PROCINFO_INITFUNC]
+ ARM(	add	pc, r12, r10			)
+ THUMB(	add	r12, r12, r10			)
  THUMB(	ret	r12				)
 1:	b	__enable_mmu
 ENDPROC(stext)

@@ -386,10 +387,11 @@ ENTRY(secondary_startup)
 	ldr	r8, [r7, lr]			@ get secondary_data.swapper_pg_dir
 	adr	lr, BSYM(__enable_mmu)		@ return address
 	mov	r13, r12			@ __secondary_switched address
- ARM(	add	pc, r10, #PROCINFO_INITFUNC	) @ initialise processor
-						  @ (return control reg)
- THUMB(	add	r12, r10, #PROCINFO_INITFUNC	)
- THUMB(	ret	r12				)
+	ldr	r12, [r10, #PROCINFO_INITFUNC]
+ ARM(	add	pc, r12, r10		)	@ initialise processor
+						@ (return control reg)
+ THUMB(	add	r12, r12, r10		)
+ THUMB(	ret	r12			)
 ENDPROC(secondary_startup)
 ENDPROC(secondary_startup_arm)

arch/arm/mm/proc-arm1020.S +2 -2

index 86ee5d47ce3c..7ddd45d6ca52 100644
@@ -507,7 +507,7 @@ cpu_arm1020_name:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__arm1020_proc_info,#object
 __arm1020_proc_info:

@@ -519,7 +519,7 @@ __arm1020_proc_info:
 	.long   PMD_TYPE_SECT | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__arm1020_setup
+	initfn	__arm1020_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB

arch/arm/mm/proc-arm1020e.S +2 -2

index a6331d78601f..d15f556782a8 100644
@@ -465,7 +465,7 @@ arm1020e_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__arm1020e_proc_info,#object
 __arm1020e_proc_info:

@@ -479,7 +479,7 @@ __arm1020e_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__arm1020e_setup
+	initfn	__arm1020e_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB | HWCAP_EDSP

arch/arm/mm/proc-arm1022.S +2 -2

index a126b7a59928..6245e422e95c 100644
@@ -448,7 +448,7 @@ arm1022_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__arm1022_proc_info,#object
 __arm1022_proc_info:

@@ -462,7 +462,7 @@ __arm1022_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__arm1022_setup
+	initfn	__arm1022_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB | HWCAP_EDSP

arch/arm/mm/proc-arm1026.S +2 -2

index fc294067e977..944114b566ef 100644
@@ -442,7 +442,7 @@ arm1026_crval:
 	string	cpu_arm1026_name, "ARM1026EJ-S"
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__arm1026_proc_info,#object
 __arm1026_proc_info:

@@ -456,7 +456,7 @@ __arm1026_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__arm1026_setup
+	initfn	__arm1026_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP|HWCAP_JAVA

arch/arm/mm/proc-arm720.S +2 -2

index 2baa66b3ac9b..4bd5f8dcbc29 100644
@@ -186,7 +186,7 @@ arm720_crval:
  * See <asm/procinfo.h> for a definition of this structure.
  */
 	
-		.section ".proc.info.init", #alloc, #execinstr
+		.section ".proc.info.init", #alloc
 
 .macro arm720_proc_info name:req, cpu_val:req, cpu_mask:req, cpu_name:req, cpu_flush:req
 		.type	__\name\()_proc_info,#object

@@ -203,7 +203,7 @@ __\name\()_proc_info:
 			PMD_BIT4 | \
 			PMD_SECT_AP_WRITE | \
 			PMD_SECT_AP_READ
-		b	\cpu_flush				@ cpu_flush
+		initfn	\cpu_flush				@ cpu_flush
 		.long	cpu_arch_name				@ arch_name
 		.long	cpu_elf_name				@ elf_name
 		.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB	@ elf_hwcap

arch/arm/mm/proc-arm740.S +2 -2

index ac1ea6b3bce4..1dadba6744ec 100644
@@ -132,14 +132,14 @@ __arm740_setup:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 	.type	__arm740_proc_info,#object
 __arm740_proc_info:
 	.long	0x41807400
 	.long	0xfffffff0
 	.long	0
 	.long	0
-	b	__arm740_setup
+	initfn	__arm740_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB | HWCAP_26BIT

arch/arm/mm/proc-arm7tdmi.S +2 -2

index bf6ba4bc30ff..c322a416cb9a 100644
@@ -76,7 +76,7 @@ __arm7tdmi_setup:
 
 		.align
 
-		.section ".proc.info.init", #alloc, #execinstr
+		.section ".proc.info.init", #alloc
 
 .macro arm7tdmi_proc_info name:req, cpu_val:req, cpu_mask:req, cpu_name:req, \
 	extra_hwcaps=0

@@ -86,7 +86,7 @@ __\name\()_proc_info:
 		.long	\cpu_mask
 		.long	0
 		.long	0
-		b	__arm7tdmi_setup
+		initfn	__arm7tdmi_setup
 		.long	cpu_arch_name
 		.long	cpu_elf_name
 		.long	HWCAP_SWP | HWCAP_26BIT | ( \extra_hwcaps )

arch/arm/mm/proc-arm920.S +2 -2

index 22bf8dde4f84..f129bdede5cc 100644
@@ -448,7 +448,7 @@ arm920_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__arm920_proc_info,#object
 __arm920_proc_info:

@@ -464,7 +464,7 @@ __arm920_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__arm920_setup
+	initfn	__arm920_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB

arch/arm/mm/proc-arm922.S +2 -2

index 0c6d5ac5a6d4..53b5bddb0ee9 100644
@@ -426,7 +426,7 @@ arm922_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__arm922_proc_info,#object
 __arm922_proc_info:

@@ -442,7 +442,7 @@ __arm922_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__arm922_setup
+	initfn	__arm922_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB

arch/arm/mm/proc-arm925.S +2 -2

index c32d073282ea..94a88a734210 100644
@@ -494,7 +494,7 @@ arm925_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 .macro arm925_proc_info name:req, cpu_val:req, cpu_mask:req, cpu_name:req, cache
 	.type	__\name\()_proc_info,#object

@@ -510,7 +510,7 @@ __\name\()_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__arm925_setup
+	initfn	__arm925_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB

arch/arm/mm/proc-arm926.S +2 -2

index 252b2503038d..0fe423de5118 100644
@@ -474,7 +474,7 @@ arm926_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__arm926_proc_info,#object
 __arm926_proc_info:

@@ -490,7 +490,7 @@ __arm926_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__arm926_setup
+	initfn	__arm926_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP|HWCAP_JAVA

arch/arm/mm/proc-arm940.S +2 -2

index e5212d489377..7ad2642dfcda 100644
@@ -354,14 +354,14 @@ __arm940_setup:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__arm940_proc_info,#object
 __arm940_proc_info:
 	.long	0x41009400
 	.long	0xff00fff0
 	.long	0
-	b	__arm940_setup
+	initfn	__arm940_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB

arch/arm/mm/proc-arm946.S +2 -2

index b3dd9b2d0b8e..f129dcadb8e8 100644
@@ -409,14 +409,14 @@ __arm946_setup:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 	.type	__arm946_proc_info,#object
 __arm946_proc_info:
 	.long	0x41009460
 	.long	0xff00fff0
 	.long	0
 	.long	0
-	b	__arm946_setup
+	initfn	__arm946_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB

arch/arm/mm/proc-arm9tdmi.S +2 -2

index 8227322bbb8f..a8828b63a981 100644
@@ -70,7 +70,7 @@ __arm9tdmi_setup:
 
 		.align
 
-		.section ".proc.info.init", #alloc, #execinstr
+		.section ".proc.info.init", #alloc
 
 .macro arm9tdmi_proc_info name:req, cpu_val:req, cpu_mask:req, cpu_name:req
 		.type	__\name\()_proc_info, #object

@@ -79,7 +79,7 @@ __\name\()_proc_info:
 		.long	\cpu_mask
 		.long	0
 		.long	0
-		b	__arm9tdmi_setup
+		initfn	__arm9tdmi_setup
 		.long	cpu_arch_name
 		.long	cpu_elf_name
 		.long	HWCAP_SWP | HWCAP_THUMB | HWCAP_26BIT

arch/arm/mm/proc-fa526.S +2 -2

index c494886892ba..afb100b96081 100644
@@ -190,7 +190,7 @@ fa526_cr1_set:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__fa526_proc_info,#object
 __fa526_proc_info:

@@ -206,7 +206,7 @@ __fa526_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__fa526_setup
+	initfn	__fa526_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF

arch/arm/mm/proc-feroceon.S +3 -2

index 03a1b75f2e16..5bd769a2bbbe 100644
@@ -584,7 +584,7 @@ feroceon_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 .macro feroceon_proc_info name:req, cpu_val:req, cpu_mask:req, cpu_name:req, cache:req
 	.type	__\name\()_proc_info,#object

@@ -601,7 +601,8 @@ __\name\()_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__feroceon_setup
+	initfn	__feroceon_setup
+	.long __feroceon_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP

arch/arm/mm/proc-macros.S +4 -0

index 082b9f2f7e90..5bed45aeac40 100644
@@ -331,3 +331,7 @@ ENTRY(\name\()_tlb_fns)
 	.globl	\x
 	.equ	\x, \y
 .endm
+
+.macro	initfn, initfunc
+	.long	\initfunc - . + PROCINFO_INITFUNC
+.endm

arch/arm/mm/proc-mohawk.S +2 -2

index 53d393455f13..a15a2c150460 100644
@@ -427,7 +427,7 @@ mohawk_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__88sv331x_proc_info,#object
 __88sv331x_proc_info:

@@ -443,7 +443,7 @@ __88sv331x_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__mohawk_setup
+	initfn	__mohawk_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP

arch/arm/mm/proc-sa110.S +2 -2

index 8008a0461cf5..4668067e7a08 100644
@@ -199,7 +199,7 @@ sa110_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__sa110_proc_info,#object
 __sa110_proc_info:

@@ -213,7 +213,7 @@ __sa110_proc_info:
 	.long   PMD_TYPE_SECT | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__sa110_setup
+	initfn	__sa110_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_26BIT | HWCAP_FAST_MULT

arch/arm/mm/proc-sa1100.S +2 -2

index 89f97ac648a9..4acd3cbaa7fe 100644
@@ -242,7 +242,7 @@ sa1100_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 .macro sa1100_proc_info name:req, cpu_val:req, cpu_mask:req, cpu_name:req
 	.type	__\name\()_proc_info,#object

@@ -257,7 +257,7 @@ __\name\()_proc_info:
 	.long   PMD_TYPE_SECT | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__sa1100_setup
+	initfn	__sa1100_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_26BIT | HWCAP_FAST_MULT

arch/arm/mm/proc-v6.S +2 -2

index d0390f4b3f18..5c05a2948dfa 100644
@@ -264,7 +264,7 @@ v6_crval:
 	string	cpu_elf_name, "v6"
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	/*
 	 * Match any ARMv6 processor core.

@@ -287,7 +287,7 @@ __v6_proc_info:
 		PMD_SECT_XN | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__v6_setup
+	initfn	__v6_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	/* See also feat_v6_fixup() for HWCAP_TLS */

arch/arm/mm/proc-v7.S +2 -2

index 8b4ee5e81c14..eda1eba132c6 100644
@@ -462,7 +462,7 @@ __v7_setup_stack:
 	string	cpu_elf_name, "v7"
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	/*
 	 * Standard v7 proc info content

@@ -474,7 +474,7 @@ __v7_setup_stack:
 			PMD_SECT_AF | PMD_FLAGS_UP | \mm_mmuflags)
 	.long	PMD_TYPE_SECT | PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ | PMD_SECT_AF | \io_mmuflags
-	W(b)	\initfunc
+	initfn	\initfunc
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB | HWCAP_FAST_MULT | \

arch/arm/mm/proc-v7m.S +2 -2

index d1e68b553d3b..89119d50f57d 100644
@@ -135,7 +135,7 @@ __v7m_setup_stack_top:
 	string cpu_elf_name "v7m"
 	string cpu_v7m_name "ARMv7-M"
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	/*
 	 * Match any ARMv7-M processor core.

@@ -146,7 +146,7 @@ __v7m_proc_info:
 	.long	0x000f0000		@ Mask for ID
 	.long   0			@ proc_info_list.__cpu_mm_mmu_flags
 	.long   0			@ proc_info_list.__cpu_io_mmu_flags
-	b	__v7m_setup		@ proc_info_list.__cpu_flush
+	initfn	__v7m_setup		@ proc_info_list.__cpu_flush
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT

arch/arm/mm/proc-xsc3.S +2 -2

index f8acdfece036..1b0b945126f8 100644
@@ -499,7 +499,7 @@ xsc3_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 .macro xsc3_proc_info name:req, cpu_val:req, cpu_mask:req
 	.type	__\name\()_proc_info,#object

@@ -514,7 +514,7 @@ __\name\()_proc_info:
 	.long	PMD_TYPE_SECT | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__xsc3_setup
+	initfn	__xsc3_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP

arch/arm/mm/proc-xscale.S +2 -2

index afa2b3c4df4a..7805cd098140 100644
@@ -612,7 +612,7 @@ xscale_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 .macro xscale_proc_info name:req, cpu_val:req, cpu_mask:req, cpu_name:req, cache
 	.type	__\name\()_proc_info,#object

@@ -627,7 +627,7 @@ __\name\()_proc_info:
 	.long	PMD_TYPE_SECT | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__xscale_setup
+	initfn	__xscale_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP

Signature · 1 line

1.8.3.2

Nicolas Pitre

2015-03-12 20:24 UTC #2 lore raw

PATCH 1/6 ARM: replace PROCINFO embedded branch with relative offset

Quoted 8 lines · Ard Biesheuvel

This patch replaces the 'branch to setup()' instructions embedded in the PROCINFO structs with the offset to that setup function relative to the base of the struct. This preserves the position independent nature of that field, but uses a data item rather than an instruction.
This is mainly done to prevent linker failures on large kernels, where the setup function is out of reach for the branch.

Looks fine to me.

Acked-by Nicolas Pitre <[email protected]>

Quoted 604 lines

Signed-off-by Ard Biesheuvel <[email protected]>

---
 arch/arm/kernel/head.S      | 14 ++++++++------
 arch/arm/mm/proc-arm1020.S  |  4 ++--
 arch/arm/mm/proc-arm1020e.S |  4 ++--
 arch/arm/mm/proc-arm1022.S  |  4 ++--
 arch/arm/mm/proc-arm1026.S  |  4 ++--
 arch/arm/mm/proc-arm720.S   |  4 ++--
 arch/arm/mm/proc-arm740.S   |  4 ++--
 arch/arm/mm/proc-arm7tdmi.S |  4 ++--
 arch/arm/mm/proc-arm920.S   |  4 ++--
 arch/arm/mm/proc-arm922.S   |  4 ++--
 arch/arm/mm/proc-arm925.S   |  4 ++--
 arch/arm/mm/proc-arm926.S   |  4 ++--
 arch/arm/mm/proc-arm940.S   |  4 ++--
 arch/arm/mm/proc-arm946.S   |  4 ++--
 arch/arm/mm/proc-arm9tdmi.S |  4 ++--
 arch/arm/mm/proc-fa526.S    |  4 ++--
 arch/arm/mm/proc-feroceon.S |  5 +++--
 arch/arm/mm/proc-macros.S   |  4 ++++
 arch/arm/mm/proc-mohawk.S   |  4 ++--
 arch/arm/mm/proc-sa110.S    |  4 ++--
 arch/arm/mm/proc-sa1100.S   |  4 ++--
 arch/arm/mm/proc-v6.S       |  4 ++--
 arch/arm/mm/proc-v7.S       |  4 ++--
 arch/arm/mm/proc-v7m.S      |  4 ++--
 arch/arm/mm/proc-xsc3.S     |  4 ++--
 arch/arm/mm/proc-xscale.S   |  4 ++--
 26 files changed, 61 insertions(+), 54 deletions(-)

arch/arm/kernel/head.S +8 -6

index 01963273c07a..698b38bfca8f 100644
@@ -138,8 +138,9 @@ ENTRY(stext)
 						@ mmu has been enabled
 	adr	lr, BSYM(1f)			@ return (PIC) address
 	mov	r8, r4				@ set TTBR1 to swapper_pg_dir
- ARM(	add	pc, r10, #PROCINFO_INITFUNC	)
- THUMB(	add	r12, r10, #PROCINFO_INITFUNC	)
+	ldr	r12, [r10, #PROCINFO_INITFUNC]
+ ARM(	add	pc, r12, r10			)
+ THUMB(	add	r12, r12, r10			)
  THUMB(	ret	r12				)
 1:	b	__enable_mmu
 ENDPROC(stext)

@@ -386,10 +387,11 @@ ENTRY(secondary_startup)
 	ldr	r8, [r7, lr]			@ get secondary_data.swapper_pg_dir
 	adr	lr, BSYM(__enable_mmu)		@ return address
 	mov	r13, r12			@ __secondary_switched address
- ARM(	add	pc, r10, #PROCINFO_INITFUNC	) @ initialise processor
-						  @ (return control reg)
- THUMB(	add	r12, r10, #PROCINFO_INITFUNC	)
- THUMB(	ret	r12				)
+	ldr	r12, [r10, #PROCINFO_INITFUNC]
+ ARM(	add	pc, r12, r10		)	@ initialise processor
+						@ (return control reg)
+ THUMB(	add	r12, r12, r10		)
+ THUMB(	ret	r12			)
 ENDPROC(secondary_startup)
 ENDPROC(secondary_startup_arm)

arch/arm/mm/proc-arm1020.S +2 -2

index 86ee5d47ce3c..7ddd45d6ca52 100644
@@ -507,7 +507,7 @@ cpu_arm1020_name:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__arm1020_proc_info,#object
 __arm1020_proc_info:

@@ -519,7 +519,7 @@ __arm1020_proc_info:
 	.long   PMD_TYPE_SECT | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__arm1020_setup
+	initfn	__arm1020_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB

arch/arm/mm/proc-arm1020e.S +2 -2

index a6331d78601f..d15f556782a8 100644
@@ -465,7 +465,7 @@ arm1020e_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__arm1020e_proc_info,#object
 __arm1020e_proc_info:

@@ -479,7 +479,7 @@ __arm1020e_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__arm1020e_setup
+	initfn	__arm1020e_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB | HWCAP_EDSP

arch/arm/mm/proc-arm1022.S +2 -2

index a126b7a59928..6245e422e95c 100644
@@ -448,7 +448,7 @@ arm1022_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__arm1022_proc_info,#object
 __arm1022_proc_info:

@@ -462,7 +462,7 @@ __arm1022_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__arm1022_setup
+	initfn	__arm1022_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB | HWCAP_EDSP

arch/arm/mm/proc-arm1026.S +2 -2

index fc294067e977..944114b566ef 100644
@@ -442,7 +442,7 @@ arm1026_crval:
 	string	cpu_arm1026_name, "ARM1026EJ-S"
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__arm1026_proc_info,#object
 __arm1026_proc_info:

@@ -456,7 +456,7 @@ __arm1026_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__arm1026_setup
+	initfn	__arm1026_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP|HWCAP_JAVA

arch/arm/mm/proc-arm720.S +2 -2

index 2baa66b3ac9b..4bd5f8dcbc29 100644
@@ -186,7 +186,7 @@ arm720_crval:
  * See <asm/procinfo.h> for a definition of this structure.
  */
 
-		.section ".proc.info.init", #alloc, #execinstr
+		.section ".proc.info.init", #alloc
 
 .macro arm720_proc_info name:req, cpu_val:req, cpu_mask:req, cpu_name:req, cpu_flush:req
 		.type	__\name\()_proc_info,#object

@@ -203,7 +203,7 @@ __\name\()_proc_info:
 			PMD_BIT4 | \
 			PMD_SECT_AP_WRITE | \
 			PMD_SECT_AP_READ
-		b	\cpu_flush				@ cpu_flush
+		initfn	\cpu_flush				@ cpu_flush
 		.long	cpu_arch_name				@ arch_name
 		.long	cpu_elf_name				@ elf_name
 		.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB	@ elf_hwcap

arch/arm/mm/proc-arm740.S +2 -2

index ac1ea6b3bce4..1dadba6744ec 100644
@@ -132,14 +132,14 @@ __arm740_setup:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 	.type	__arm740_proc_info,#object
 __arm740_proc_info:
 	.long	0x41807400
 	.long	0xfffffff0
 	.long	0
 	.long	0
-	b	__arm740_setup
+	initfn	__arm740_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB | HWCAP_26BIT

arch/arm/mm/proc-arm7tdmi.S +2 -2

index bf6ba4bc30ff..c322a416cb9a 100644
@@ -76,7 +76,7 @@ __arm7tdmi_setup:
 
 		.align
 
-		.section ".proc.info.init", #alloc, #execinstr
+		.section ".proc.info.init", #alloc
 
 .macro arm7tdmi_proc_info name:req, cpu_val:req, cpu_mask:req, cpu_name:req, \
 	extra_hwcaps=0

@@ -86,7 +86,7 @@ __\name\()_proc_info:
 		.long	\cpu_mask
 		.long	0
 		.long	0
-		b	__arm7tdmi_setup
+		initfn	__arm7tdmi_setup
 		.long	cpu_arch_name
 		.long	cpu_elf_name
 		.long	HWCAP_SWP | HWCAP_26BIT | ( \extra_hwcaps )

arch/arm/mm/proc-arm920.S +2 -2

index 22bf8dde4f84..f129bdede5cc 100644
@@ -448,7 +448,7 @@ arm920_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__arm920_proc_info,#object
 __arm920_proc_info:

@@ -464,7 +464,7 @@ __arm920_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__arm920_setup
+	initfn	__arm920_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB

arch/arm/mm/proc-arm922.S +2 -2

index 0c6d5ac5a6d4..53b5bddb0ee9 100644
@@ -426,7 +426,7 @@ arm922_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__arm922_proc_info,#object
 __arm922_proc_info:

@@ -442,7 +442,7 @@ __arm922_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__arm922_setup
+	initfn	__arm922_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB

arch/arm/mm/proc-arm925.S +2 -2

index c32d073282ea..94a88a734210 100644
@@ -494,7 +494,7 @@ arm925_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 .macro arm925_proc_info name:req, cpu_val:req, cpu_mask:req, cpu_name:req, cache
 	.type	__\name\()_proc_info,#object

@@ -510,7 +510,7 @@ __\name\()_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__arm925_setup
+	initfn	__arm925_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB

arch/arm/mm/proc-arm926.S +2 -2

index 252b2503038d..0fe423de5118 100644
@@ -474,7 +474,7 @@ arm926_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__arm926_proc_info,#object
 __arm926_proc_info:

@@ -490,7 +490,7 @@ __arm926_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__arm926_setup
+	initfn	__arm926_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP|HWCAP_JAVA

arch/arm/mm/proc-arm940.S +2 -2

index e5212d489377..7ad2642dfcda 100644
@@ -354,14 +354,14 @@ __arm940_setup:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__arm940_proc_info,#object
 __arm940_proc_info:
 	.long	0x41009400
 	.long	0xff00fff0
 	.long	0
-	b	__arm940_setup
+	initfn	__arm940_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB

arch/arm/mm/proc-arm946.S +2 -2

index b3dd9b2d0b8e..f129dcadb8e8 100644
@@ -409,14 +409,14 @@ __arm946_setup:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 	.type	__arm946_proc_info,#object
 __arm946_proc_info:
 	.long	0x41009460
 	.long	0xff00fff0
 	.long	0
 	.long	0
-	b	__arm946_setup
+	initfn	__arm946_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB

arch/arm/mm/proc-arm9tdmi.S +2 -2

index 8227322bbb8f..a8828b63a981 100644
@@ -70,7 +70,7 @@ __arm9tdmi_setup:
 
 		.align
 
-		.section ".proc.info.init", #alloc, #execinstr
+		.section ".proc.info.init", #alloc
 
 .macro arm9tdmi_proc_info name:req, cpu_val:req, cpu_mask:req, cpu_name:req
 		.type	__\name\()_proc_info, #object

@@ -79,7 +79,7 @@ __\name\()_proc_info:
 		.long	\cpu_mask
 		.long	0
 		.long	0
-		b	__arm9tdmi_setup
+		initfn	__arm9tdmi_setup
 		.long	cpu_arch_name
 		.long	cpu_elf_name
 		.long	HWCAP_SWP | HWCAP_THUMB | HWCAP_26BIT

arch/arm/mm/proc-fa526.S +2 -2

index c494886892ba..afb100b96081 100644
@@ -190,7 +190,7 @@ fa526_cr1_set:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__fa526_proc_info,#object
 __fa526_proc_info:

@@ -206,7 +206,7 @@ __fa526_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__fa526_setup
+	initfn	__fa526_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF

arch/arm/mm/proc-feroceon.S +3 -2

index 03a1b75f2e16..5bd769a2bbbe 100644
@@ -584,7 +584,7 @@ feroceon_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 .macro feroceon_proc_info name:req, cpu_val:req, cpu_mask:req, cpu_name:req, cache:req
 	.type	__\name\()_proc_info,#object

@@ -601,7 +601,8 @@ __\name\()_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__feroceon_setup
+	initfn	__feroceon_setup
+	.long __feroceon_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP

arch/arm/mm/proc-macros.S +4 -0

index 082b9f2f7e90..5bed45aeac40 100644
@@ -331,3 +331,7 @@ ENTRY(\name\()_tlb_fns)
 	.globl	\x
 	.equ	\x, \y
 .endm
+
+.macro	initfn, initfunc
+	.long	\initfunc - . + PROCINFO_INITFUNC
+.endm

arch/arm/mm/proc-mohawk.S +2 -2

index 53d393455f13..a15a2c150460 100644
@@ -427,7 +427,7 @@ mohawk_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__88sv331x_proc_info,#object
 __88sv331x_proc_info:

@@ -443,7 +443,7 @@ __88sv331x_proc_info:
 		PMD_BIT4 | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__mohawk_setup
+	initfn	__mohawk_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP

arch/arm/mm/proc-sa110.S +2 -2

index 8008a0461cf5..4668067e7a08 100644
@@ -199,7 +199,7 @@ sa110_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	.type	__sa110_proc_info,#object
 __sa110_proc_info:

@@ -213,7 +213,7 @@ __sa110_proc_info:
 	.long   PMD_TYPE_SECT | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__sa110_setup
+	initfn	__sa110_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_26BIT | HWCAP_FAST_MULT

arch/arm/mm/proc-sa1100.S +2 -2

index 89f97ac648a9..4acd3cbaa7fe 100644
@@ -242,7 +242,7 @@ sa1100_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 .macro sa1100_proc_info name:req, cpu_val:req, cpu_mask:req, cpu_name:req
 	.type	__\name\()_proc_info,#object

@@ -257,7 +257,7 @@ __\name\()_proc_info:
 	.long   PMD_TYPE_SECT | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__sa1100_setup
+	initfn	__sa1100_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_26BIT | HWCAP_FAST_MULT

arch/arm/mm/proc-v6.S +2 -2

index d0390f4b3f18..5c05a2948dfa 100644
@@ -264,7 +264,7 @@ v6_crval:
 	string	cpu_elf_name, "v6"
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	/*
 	 * Match any ARMv6 processor core.

@@ -287,7 +287,7 @@ __v6_proc_info:
 		PMD_SECT_XN | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__v6_setup
+	initfn	__v6_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	/* See also feat_v6_fixup() for HWCAP_TLS */

arch/arm/mm/proc-v7.S +2 -2

index 8b4ee5e81c14..eda1eba132c6 100644
@@ -462,7 +462,7 @@ __v7_setup_stack:
 	string	cpu_elf_name, "v7"
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	/*
 	 * Standard v7 proc info content

@@ -474,7 +474,7 @@ __v7_setup_stack:
 			PMD_SECT_AF | PMD_FLAGS_UP | \mm_mmuflags)
 	.long	PMD_TYPE_SECT | PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ | PMD_SECT_AF | \io_mmuflags
-	W(b)	\initfunc
+	initfn	\initfunc
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB | HWCAP_FAST_MULT | \

arch/arm/mm/proc-v7m.S +2 -2

index d1e68b553d3b..89119d50f57d 100644
@@ -135,7 +135,7 @@ __v7m_setup_stack_top:
 	string cpu_elf_name "v7m"
 	string cpu_v7m_name "ARMv7-M"
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 	/*
 	 * Match any ARMv7-M processor core.

@@ -146,7 +146,7 @@ __v7m_proc_info:
 	.long	0x000f0000		@ Mask for ID
 	.long   0			@ proc_info_list.__cpu_mm_mmu_flags
 	.long   0			@ proc_info_list.__cpu_io_mmu_flags
-	b	__v7m_setup		@ proc_info_list.__cpu_flush
+	initfn	__v7m_setup		@ proc_info_list.__cpu_flush
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT

arch/arm/mm/proc-xsc3.S +2 -2

index f8acdfece036..1b0b945126f8 100644
@@ -499,7 +499,7 @@ xsc3_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 .macro xsc3_proc_info name:req, cpu_val:req, cpu_mask:req
 	.type	__\name\()_proc_info,#object

@@ -514,7 +514,7 @@ __\name\()_proc_info:
 	.long	PMD_TYPE_SECT | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__xsc3_setup
+	initfn	__xsc3_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP

arch/arm/mm/proc-xscale.S +2 -2

index afa2b3c4df4a..7805cd098140 100644
@@ -612,7 +612,7 @@ xscale_crval:
 
 	.align
 
-	.section ".proc.info.init", #alloc, #execinstr
+	.section ".proc.info.init", #alloc
 
 .macro xscale_proc_info name:req, cpu_val:req, cpu_mask:req, cpu_name:req, cache
 	.type	__\name\()_proc_info,#object

@@ -627,7 +627,7 @@ __\name\()_proc_info:
 	.long	PMD_TYPE_SECT | \
 		PMD_SECT_AP_WRITE | \
 		PMD_SECT_AP_READ
-	b	__xscale_setup
+	initfn	__xscale_setup
 	.long	cpu_arch_name
 	.long	cpu_elf_name
 	.long	HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP

Signature · 1 line

1.8.3.2

Russell King - ARM Linux

2015-03-12 20:50 UTC #3 lore raw

PATCH 1/6 ARM: replace PROCINFO embedded branch with relative offset

In reply to Ard Biesheuvel

arch/arm/kernel/head.S ENTRY(stext) · line 144

Quoted 10 lines · Ard Biesheuvel

arch/arm/kernel/head.S +3 -2

@@ -138,8 +138,9 @@ ENTRY(stext)
 						@ mmu has been enabled
 	adr	lr, BSYM(1f)			@ return (PIC) address
 	mov	r8, r4				@ set TTBR1 to swapper_pg_dir
- ARM(	add	pc, r10, #PROCINFO_INITFUNC	)
- THUMB(	add	r12, r10, #PROCINFO_INITFUNC	)
+	ldr	r12, [r10, #PROCINFO_INITFUNC]
+ ARM(	add	pc, r12, r10			)
+ THUMB(	add	r12, r12, r10			)
  THUMB(	ret	r12				)

Given this change, I'd prefer a slightly different result:

	ldr	r12, [r10, #PROCINFO_INITFUNC]
	add	r12, r12, r10
	ret	r12

Quoted 5 lines

arch/arm/kernel/head.S +0 -0

 1:	b	__enable_mmu
 ENDPROC(stext)

@@ -386,10 +387,11 @@ ENTRY(secondary_startup)
 	ldr	r8, [r7, lr]			@ get secondary_data.swapper_pg_dir
 	adr	lr, BSYM(__enable_mmu)		@ return address

arch/arm/kernel/head.S ENTRY(secondary_startup) · line 394

Quoted 10 lines

arch/arm/kernel/head.S +5 -4

 	mov	r13, r12			@ __secondary_switched address
- ARM(	add	pc, r10, #PROCINFO_INITFUNC	) @ initialise processor
-						  @ (return control reg)
- THUMB(	add	r12, r10, #PROCINFO_INITFUNC	)
- THUMB(	ret	r12				)
+	ldr	r12, [r10, #PROCINFO_INITFUNC]
+ ARM(	add	pc, r12, r10		)	@ initialise processor
+						@ (return control reg)
+ THUMB(	add	r12, r12, r10		)
+ THUMB(	ret	r12			)

and same here. It means that we have less code to look at, at the expense of one additional ARM instruction.

arch/arm/mm/proc-macros.S ENTRY(\name\()_tlb_fns) · line 337

Quoted 4 lines

arch/arm/mm/proc-macros.S +4 -0

+
+.macro	initfn, initfunc
+	.long	\initfunc - . + PROCINFO_INITFUNC
+.endm

The more I look at this, the more I find it hard to decide whether this is correct or not, and that means it's bad. It is correct, but it needs some thought to confirm that. I'd prefer a different solution.

The value which we want to place into this location is the difference between the start of the procinfo structure and the target symbol. So let's do that - we have a symbol for each procinfo structure, let's make "initfn" take that symbol and do the computation using that.

Thanks.

Signature · 2 lines

FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Ard Biesheuvel

author

2015-03-12 21:00 UTC #4 lore raw

PATCH 1/6 ARM: replace PROCINFO embedded branch with relative offset

Quoted 14 lines · Russell King - ARM Linux

arch/arm/kernel/head.S ENTRY(stext) · line 144

Quoted 10 lines · Ard Biesheuvel

arch/arm/kernel/head.S +3 -2

@@ -138,8 +138,9 @@ ENTRY(stext)
                                              @ mmu has been enabled
      adr     lr, BSYM(1f)                    @ return (PIC) address
      mov     r8, r4                          @ set TTBR1 to swapper_pg_dir
- ARM(        add     pc, r10, #PROCINFO_INITFUNC     )
- THUMB(      add     r12, r10, #PROCINFO_INITFUNC    )
+     ldr     r12, [r10, #PROCINFO_INITFUNC]
+ ARM(        add     pc, r12, r10                    )
+ THUMB(      add     r12, r12, r10                   )
  THUMB(      ret     r12                             )

Given this change, I'd prefer a slightly different result:

Quoted 4 lines

        ldr     r12, [r10, #PROCINFO_INITFUNC]
        add     r12, r12, r10
        ret     r12

Good idea

Quoted 24 lines

Quoted 5 lines

arch/arm/kernel/head.S +0 -0

 1:   b       __enable_mmu
 ENDPROC(stext)

@@ -386,10 +387,11 @@ ENTRY(secondary_startup)
      ldr     r8, [r7, lr]                    @ get secondary_data.swapper_pg_dir
      adr     lr, BSYM(__enable_mmu)          @ return address

arch/arm/kernel/head.S ENTRY(secondary_startup) · line 394

Quoted 10 lines

arch/arm/kernel/head.S +5 -4

      mov     r13, r12                        @ __secondary_switched address
- ARM(        add     pc, r10, #PROCINFO_INITFUNC     ) @ initialise processor
-                                               @ (return control reg)
- THUMB(      add     r12, r10, #PROCINFO_INITFUNC    )
- THUMB(      ret     r12                             )
+     ldr     r12, [r10, #PROCINFO_INITFUNC]
+ ARM(        add     pc, r12, r10            )       @ initialise processor
+                                             @ (return control reg)
+ THUMB(      add     r12, r12, r10           )
+ THUMB(      ret     r12                     )

and same here. It means that we have less code to look at, at the expense of one additional ARM instruction.

arch/arm/mm/proc-macros.S ENTRY(\name\()_tlb_fns) · line 337

Quoted 4 lines

arch/arm/mm/proc-macros.S +4 -0

+
+.macro       initfn, initfunc
+     .long   \initfunc - . + PROCINFO_INITFUNC
+.endm

Quoted 9 lines

The more I look at this, the more I find it hard to decide whether this is correct or not, and that means it's bad. It is correct, but it needs some thought to confirm that. I'd prefer a different solution.
The value which we want to place into this location is the difference between the start of the procinfo structure and the target symbol. So let's do that - we have a symbol for each procinfo structure, let's make "initfn" take that symbol and do the computation using that.

I agree. I'll respin with these changes

Ard Biesheuvel

author

2015-03-12 17:38 UTC #5 lore raw

PATCH 2/6 ARM: move HYP text to end of .text section

In reply to Ard Biesheuvel

The HYP text is essentially a separate binary from the kernel proper, so it can be moved away from the rest of the kernel. This helps prevent link failures due to branch relocations exceeding their range.

Signed-off-by Ard Biesheuvel <[email protected]>

---
 arch/arm/kernel/vmlinux.lds.S | 8 ++++++--
 arch/arm/kvm/init.S           | 5 +----
 arch/arm/kvm/interrupts.S     | 4 +---
 3 files changed, 8 insertions(+), 9 deletions(-)

arch/arm/kernel/vmlinux.lds.S +6 -2

index b31aa73e8076..e3b9403bd2d6 100644
@@ -22,11 +22,14 @@
 	ALIGN_FUNCTION();						\
 	VMLINUX_SYMBOL(__idmap_text_start) = .;				\
 	*(.idmap.text)							\
-	VMLINUX_SYMBOL(__idmap_text_end) = .;				\
+	VMLINUX_SYMBOL(__idmap_text_end) = .;
+
+#define HYP_TEXT							\
 	. = ALIGN(32);							\
 	VMLINUX_SYMBOL(__hyp_idmap_text_start) = .;			\
 	*(.hyp.idmap.text)						\
-	VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;
+	VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;			\
+	*(.hyp.text)
 
 #ifdef CONFIG_HOTPLUG_CPU
 #define ARM_CPU_DISCARD(x)

@@ -118,6 +121,7 @@ SECTIONS
 		. = ALIGN(4);
 		*(.got)			/* Global offset table		*/
 			ARM_CPU_KEEP(PROC_INFO)
+			HYP_TEXT
 	}
 
 #ifdef CONFIG_DEBUG_RODATA

arch/arm/kvm/init.S +1 -4

index 3988e72d16ff..7a377d36de5d 100644
@@ -51,8 +51,7 @@
  *   Switches to the runtime PGD, set stack and vectors.
  */
 
-	.text
-	.pushsection    .hyp.idmap.text,"ax"
+	.section    ".hyp.idmap.text", #alloc
 	.align 5
 __kvm_hyp_init:
 	.globl __kvm_hyp_init

@@ -155,5 +154,3 @@ target:	@ We're now in the trampoline code, switch page tables
 
 	.globl __kvm_hyp_init_end
 __kvm_hyp_init_end:
-
-	.popsection

arch/arm/kvm/interrupts.S +1 -3

index 79caf79b304a..db22e9bedfcd 100644
@@ -27,7 +27,7 @@
 #include <asm/vfpmacros.h>
 #include "interrupts_head.S"
 
-	.text
+	.section	".hyp.text", #alloc
 
 __kvm_hyp_code_start:
 	.globl __kvm_hyp_code_start

@@ -316,8 +316,6 @@ THUMB(	orr	r2, r2, #PSR_T_BIT	)
 	eret
 .endm
 
-	.text
-
 	.align 5
 __kvm_hyp_vector:
 	.globl __kvm_hyp_vector

Signature · 1 line

1.8.3.2

Ard Biesheuvel

author

2015-03-12 17:38 UTC #6 lore raw

PATCH 3/6 ARM: add macro to perform far branches (b/bl)

In reply to Ard Biesheuvel

These macros execute PC-relative branches, but with a larger reach than the 24 bits that are available in the b and bl opcodes.

Signed-off-by Ard Biesheuvel <[email protected]>

---
 arch/arm/include/asm/assembler.h | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

arch/arm/include/asm/assembler.h +29 -0

index f67fd3afebdf..bd08c3c1b73f 100644
@@ -108,6 +108,35 @@
 	.endm
 #endif
 
+	/*
+	 * Macros to emit relative branches that may exceed the range
+	 * of the 24-bit immediate of the ordinary b/bl instructions.
+	 * NOTE: this doesn't work with locally defined symbols, as they
+	 * might lack the ARM/Thumb annotation (even if they are annotated
+	 * as functions)
+	 */
+	.macro  b_far, target, tmpreg
+#if defined(CONFIG_CPU_32v7) || defined(CONFIG_CPU_32v7M)
+ ARM(	movt	\tmpreg, #:upper16:(\target - (8888f + 8))	)
+ ARM(	movw	\tmpreg, #:lower16:(\target - (8888f + 8))	)
+ THUMB(	movt    \tmpreg, #:upper16:(\target - (8888f + 4))	)
+ THUMB(	movw	\tmpreg, #:lower16:(\target - (8888f + 4))	)
+8888:	add	pc, pc, \tmpreg
+#else
+	ldr	\tmpreg, 8889f
+8888:	add	pc, pc, \tmpreg
+	.align 	2
+8889:
+ ARM(	.word   \target - (8888b + 8)           )
+#endif
+	.endm
+
+	.macro	bl_far, target, tmpreg=ip
+	adr	lr, 8887f
+	b_far	\target, \tmpreg
+8887:
+	.endm
+
 	.macro asm_trace_hardirqs_off
 #if defined(CONFIG_TRACE_IRQFLAGS)
 	stmdb   sp!, {r0-r3, ip, lr}

Signature · 1 line

1.8.3.2

Nicolas Pitre

2015-03-12 20:32 UTC #7 lore raw

PATCH 3/6 ARM: add macro to perform far branches (b/bl)

Quoted 13 lines · Ard Biesheuvel

These macros execute PC-relative branches, but with a larger reach than the 24 bits that are available in the b and bl opcodes.
Signed-off-by Ard Biesheuvel <[email protected]>
---
 arch/arm/include/asm/assembler.h | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
arch/arm/include/asm/assembler.h +0 -0
index f67fd3afebdf..bd08c3c1b73f 100644

arch/arm/include/asm/assembler.h line 116

Quoted 9 lines

arch/arm/include/asm/assembler.h +6 -0

@@ -108,6 +108,35 @@
 	.endm
 #endif
 
+	/*
+	 * Macros to emit relative branches that may exceed the range
+	 * of the 24-bit immediate of the ordinary b/bl instructions.
+	 * NOTE: this doesn't work with locally defined symbols, as they
+	 * might lack the ARM/Thumb annotation (even if they are annotated
+	 * as functions)

I really hope you won't need a far call with local symbols ever!

Quoted 4 lines

arch/arm/include/asm/assembler.h +4 -0

+	 */
+	.macro  b_far, target, tmpreg
+#if defined(CONFIG_CPU_32v7) || defined(CONFIG_CPU_32v7M)
+ ARM(	movt	\tmpreg, #:upper16:(\target - (8888f + 8))	)

arch/arm/include/asm/assembler.h line 130

Quoted 10 lines

arch/arm/include/asm/assembler.h +10 -0

+ ARM(	movw	\tmpreg, #:lower16:(\target - (8888f + 8))	)
+ THUMB(	movt    \tmpreg, #:upper16:(\target - (8888f + 4))	)
+ THUMB(	movw	\tmpreg, #:lower16:(\target - (8888f + 4))	)
+8888:	add	pc, pc, \tmpreg
+#else
+	ldr	\tmpreg, 8889f
+8888:	add	pc, pc, \tmpreg
+	.align 	2
+8889:
+ ARM(	.word   \target - (8888b + 8)           )

The Thumb relocation value is missing here.

Quoted 16 lines

arch/arm/include/asm/assembler.h +9 -0

+#endif
+	.endm
+
+	.macro	bl_far, target, tmpreg=ip
+	adr	lr, 8887f
+	b_far	\target, \tmpreg
+8887:
+	.endm
+
 	.macro asm_trace_hardirqs_off
 #if defined(CONFIG_TRACE_IRQFLAGS)
 	stmdb   sp!, {r0-r3, ip, lr}

Signature · 1 line

1.8.3.2

Ard Biesheuvel

author

2015-03-12 20:36 UTC #8 lore raw

PATCH 3/6 ARM: add macro to perform far branches (b/bl)

Quoted 18 lines · Nicolas Pitre

Quoted 16 lines · Ard Biesheuvel
These macros execute PC-relative branches, but with a larger reach than the 24 bits that are available in the b and bl opcodes.
Signed-off-by Ard Biesheuvel <[email protected]>
---
 arch/arm/include/asm/assembler.h | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
arch/arm/include/asm/assembler.h +0 -0
index f67fd3afebdf..bd08c3c1b73f 100644
@@ -108,6 +108,35 @@
      .endm
 #endif
 

Quoted 9 lines

arch/arm/include/asm/assembler.h line 116

Quoted 6 lines

arch/arm/include/asm/assembler.h +6 -0

+     /*
+      * Macros to emit relative branches that may exceed the range
+      * of the 24-bit immediate of the ordinary b/bl instructions.
+      * NOTE: this doesn't work with locally defined symbols, as they
+      * might lack the ARM/Thumb annotation (even if they are annotated
+      * as functions)

I really hope you won't need a far call with local symbols ever!

Well, if you use pushsection/popsection, then local, numbered labels you refer to can be quite far away in the output image, and those will not have the thumb bit set.

Quoted 8 lines

arch/arm/include/asm/assembler.h +8 -0

+      */
+     .macro  b_far, target, tmpreg
+#if defined(CONFIG_CPU_32v7) || defined(CONFIG_CPU_32v7M)
+ ARM(        movt    \tmpreg, #:upper16:(\target - (8888f + 8))      )
+ ARM(        movw    \tmpreg, #:lower16:(\target - (8888f + 8))      )
+ THUMB(      movt    \tmpreg, #:upper16:(\target - (8888f + 4))      )
+ THUMB(      movw    \tmpreg, #:lower16:(\target - (8888f + 4))      )
+8888:        add     pc, pc, \tmpreg

Quoted 9 lines

arch/arm/include/asm/assembler.h line 130
Quoted 6 lines
arch/arm/include/asm/assembler.h +6 -0
+#else
+     ldr     \tmpreg, 8889f
+8888:        add     pc, pc, \tmpreg
+     .align  2
+8889:
+ ARM(        .word   \target - (8888b + 8)           )
The Thumb relocation value is missing here.

Yes, this is bogus. But Thumb2 implies v7 or v7m, so it is not actually incorrect in this case.
But I will fix it in the next version

Quoted 5 lines

arch/arm/include/asm/assembler.h line 135
Quoted 5 lines
arch/arm/include/asm/assembler.h +5 -0
+#endif
+     .endm
+
+     .macro  bl_far, target, tmpreg=ip
+     adr     lr, 8887f

BTW just realised this needs a BSYM()

Quoted 11 lines

arch/arm/include/asm/assembler.h +4 -1

+     b_far   \target, \tmpreg
+8887:
+     .endm
+
      .macro asm_trace_hardirqs_off
 #if defined(CONFIG_TRACE_IRQFLAGS)
      stmdb   sp!, {r0-r3, ip, lr}
--

1.8.3.2

Nicolas Pitre

2015-03-12 21:03 UTC #9 lore raw

PATCH 3/6 ARM: add macro to perform far branches (b/bl)

Quoted 29 lines · Ard Biesheuvel

Quoted 18 lines · Nicolas Pitre
Quoted 16 lines · Ard Biesheuvel
These macros execute PC-relative branches, but with a larger reach than the 24 bits that are available in the b and bl opcodes.
Signed-off-by Ard Biesheuvel <[email protected]>
---
 arch/arm/include/asm/assembler.h | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
arch/arm/include/asm/assembler.h +0 -0
index f67fd3afebdf..bd08c3c1b73f 100644
@@ -108,6 +108,35 @@
      .endm
 #endif
 
Quoted 9 lines
arch/arm/include/asm/assembler.h line 116
Quoted 6 lines
arch/arm/include/asm/assembler.h +6 -0
+     /*
+      * Macros to emit relative branches that may exceed the range
+      * of the 24-bit immediate of the ordinary b/bl instructions.
+      * NOTE: this doesn't work with locally defined symbols, as they
+      * might lack the ARM/Thumb annotation (even if they are annotated
+      * as functions)
I really hope you won't need a far call with local symbols ever!

Quoted 3 lines

Well, if you use pushsection/popsection, then local, numbered labels you refer to can be quite far away in the output image, and those will not have the thumb bit set.

Indeed.

Quoted 18 lines

Quoted 8 lines

arch/arm/include/asm/assembler.h +8 -0

+      */
+     .macro  b_far, target, tmpreg
+#if defined(CONFIG_CPU_32v7) || defined(CONFIG_CPU_32v7M)
+ ARM(        movt    \tmpreg, #:upper16:(\target - (8888f + 8))      )
+ ARM(        movw    \tmpreg, #:lower16:(\target - (8888f + 8))      )
+ THUMB(      movt    \tmpreg, #:upper16:(\target - (8888f + 4))      )
+ THUMB(      movw    \tmpreg, #:lower16:(\target - (8888f + 4))      )
+8888:        add     pc, pc, \tmpreg

Quoted 9 lines

arch/arm/include/asm/assembler.h line 130
Quoted 6 lines
arch/arm/include/asm/assembler.h +6 -0
+#else
+     ldr     \tmpreg, 8889f
+8888:        add     pc, pc, \tmpreg
+     .align  2
+8889:
+ ARM(        .word   \target - (8888b + 8)           )
The Thumb relocation value is missing here.

Quoted 2 lines

Yes, this is bogus. But Thumb2 implies v7 or v7m, so it is not actually incorrect in this case.

The ".align 2" would be redundant in that case too.

Quoted 1 line

But I will fix it in the next version

Is it worth optimizing the ARM mode with movw/movt on ARMv7? If not then this could be simplified as only:

             .macro  b_far, target, tmpreg
 THUMB(      movt    \tmpreg, #:upper16:(\target - (8888f + 4))      )
 THUMB(      movw    \tmpreg, #:lower16:(\target - (8888f + 4))      )
 ARM(        ldr     \tmpreg, 8888f+4                                )
 8888:       add     pc, pc, \tmpreg
 ARM(        .word   \target - (8888b + 8)           )

.endm

Nicolas

Ard Biesheuvel

author

2015-03-12 21:15 UTC #10 lore raw

PATCH 3/6 ARM: add macro to perform far branches (b/bl)

Quoted 55 lines · Nicolas Pitre

Quoted 29 lines · Ard Biesheuvel
Quoted 18 lines · Nicolas Pitre
Quoted 16 lines · Ard Biesheuvel
These macros execute PC-relative branches, but with a larger reach than the 24 bits that are available in the b and bl opcodes.
Signed-off-by Ard Biesheuvel <[email protected]>
---
 arch/arm/include/asm/assembler.h | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
arch/arm/include/asm/assembler.h +0 -0
index f67fd3afebdf..bd08c3c1b73f 100644
@@ -108,6 +108,35 @@
      .endm
 #endif
 
Quoted 9 lines
arch/arm/include/asm/assembler.h line 116
Quoted 6 lines
arch/arm/include/asm/assembler.h +6 -0
+     /*
+      * Macros to emit relative branches that may exceed the range
+      * of the 24-bit immediate of the ordinary b/bl instructions.
+      * NOTE: this doesn't work with locally defined symbols, as they
+      * might lack the ARM/Thumb annotation (even if they are annotated
+      * as functions)
I really hope you won't need a far call with local symbols ever!
Quoted 3 lines
Well, if you use pushsection/popsection, then local, numbered labels you refer to can be quite far away in the output image, and those will not have the thumb bit set.
Indeed.
Quoted 18 lines
Quoted 17 lines
Quoted 4 lines
arch/arm/include/asm/assembler.h +4 -0
+      */
+     .macro  b_far, target, tmpreg
+#if defined(CONFIG_CPU_32v7) || defined(CONFIG_CPU_32v7M)
+ ARM(        movt    \tmpreg, #:upper16:(\target - (8888f + 8))      )
arch/arm/include/asm/assembler.h line 130
Quoted 10 lines
arch/arm/include/asm/assembler.h +10 -0
+ ARM(        movw    \tmpreg, #:lower16:(\target - (8888f + 8))      )
+ THUMB(      movt    \tmpreg, #:upper16:(\target - (8888f + 4))      )
+ THUMB(      movw    \tmpreg, #:lower16:(\target - (8888f + 4))      )
+8888:        add     pc, pc, \tmpreg
+#else
+     ldr     \tmpreg, 8889f
+8888:        add     pc, pc, \tmpreg
+     .align  2
+8889:
+ ARM(        .word   \target - (8888b + 8)           )
The Thumb relocation value is missing here.

Quoted 5 lines

Quoted 2 lines
Yes, this is bogus. But Thumb2 implies v7 or v7m, so it is not actually incorrect in this case.
The ".align 2" would be redundant in that case too.

Correct, the #else bit is essentially ARM only

Quoted 5 lines

Quoted 1 line
But I will fix it in the next version
Is it worth optimizing the ARM mode with movw/movt on ARMv7? If not then this could be simplified as only:

Quoted 8 lines

             .macro  b_far, target, tmpreg
 THUMB(      movt    \tmpreg, #:upper16:(\target - (8888f + 4))      )
 THUMB(      movw    \tmpreg, #:lower16:(\target - (8888f + 4))      )
 ARM(        ldr     \tmpreg, 8888f+4                                )
 8888:       add     pc, pc, \tmpreg
 ARM(        .word   \target - (8888b + 8)           )

.endm

movw/movt is preferred if available, since it circumvents the D-cache. And actually, I should rewrite the bl_far macro for v7 to use blx instead of adr+ldr to make better use of the return stack predictor or whatever it is called in the h/w

And, as Russell points out, I should put a PC_BIAS #define somewhere that assumes the correct value for the used mode, instead of the +4/+8 immediates.

So I am thinking along the lines of

.macro b_far, target, tmpreg
#if defined(CONFIG_CPU_32v7) || defined(CONFIG_CPU_32v7M) movt \tmpreg, #:upper16:(\target - (8888f + PC_BIAS)) movw \tmpreg, #:lower16:(\target - (8888f + PC_BIAS)) 8888: add pc, pc, \tmpreg
#else
ldr \tmpreg, =\target - (8888f + PC_BIAS)
8888: add pc, pc, \tmpreg
#endif
.endm

.macro bl_far, target, tmpreg=ip
#if defined(CONFIG_CPU_32v7) || defined(CONFIG_CPU_32v7M) movt \tmpreg, #:upper16:(\target - (8887f + PC_BIAS)) movw \tmpreg, #:lower16:(\target - (8887f + PC_BIAS)) 8887: add \tmpreg, \tmpreg, pc
blx \tmpreg
#else
adr lr, BSYM(8887f)
b_far \target, \tmpreg
8887:
#endif
.endm

Ard Biesheuvel

author

2015-03-12 21:37 UTC #11 lore raw

PATCH 3/6 ARM: add macro to perform far branches (b/bl)

Quoted 89 lines · Ard Biesheuvel

Quoted 55 lines · Nicolas Pitre
Quoted 29 lines · Ard Biesheuvel
Quoted 18 lines · Nicolas Pitre
Quoted 16 lines · Ard Biesheuvel
These macros execute PC-relative branches, but with a larger reach than the 24 bits that are available in the b and bl opcodes.
Signed-off-by Ard Biesheuvel <[email protected]>
---
 arch/arm/include/asm/assembler.h | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
arch/arm/include/asm/assembler.h +0 -0
index f67fd3afebdf..bd08c3c1b73f 100644
@@ -108,6 +108,35 @@
      .endm
 #endif
 
Quoted 9 lines
arch/arm/include/asm/assembler.h line 116
Quoted 6 lines
arch/arm/include/asm/assembler.h +6 -0
+     /*
+      * Macros to emit relative branches that may exceed the range
+      * of the 24-bit immediate of the ordinary b/bl instructions.
+      * NOTE: this doesn't work with locally defined symbols, as they
+      * might lack the ARM/Thumb annotation (even if they are annotated
+      * as functions)
I really hope you won't need a far call with local symbols ever!
Quoted 3 lines
Well, if you use pushsection/popsection, then local, numbered labels you refer to can be quite far away in the output image, and those will not have the thumb bit set.
Indeed.
Quoted 18 lines
Quoted 17 lines
Quoted 4 lines
arch/arm/include/asm/assembler.h +4 -0
+      */
+     .macro  b_far, target, tmpreg
+#if defined(CONFIG_CPU_32v7) || defined(CONFIG_CPU_32v7M)
+ ARM(        movt    \tmpreg, #:upper16:(\target - (8888f + 8))      )
arch/arm/include/asm/assembler.h line 130
Quoted 10 lines
arch/arm/include/asm/assembler.h +10 -0
+ ARM(        movw    \tmpreg, #:lower16:(\target - (8888f + 8))      )
+ THUMB(      movt    \tmpreg, #:upper16:(\target - (8888f + 4))      )
+ THUMB(      movw    \tmpreg, #:lower16:(\target - (8888f + 4))      )
+8888:        add     pc, pc, \tmpreg
+#else
+     ldr     \tmpreg, 8889f
+8888:        add     pc, pc, \tmpreg
+     .align  2
+8889:
+ ARM(        .word   \target - (8888b + 8)           )
The Thumb relocation value is missing here.
Quoted 5 lines
Quoted 2 lines
Yes, this is bogus. But Thumb2 implies v7 or v7m, so it is not actually incorrect in this case.
The ".align 2" would be redundant in that case too.
Correct, the #else bit is essentially ARM only
Quoted 5 lines
Quoted 1 line
But I will fix it in the next version
Is it worth optimizing the ARM mode with movw/movt on ARMv7? If not then this could be simplified as only:
Quoted 8 lines
             .macro  b_far, target, tmpreg
 THUMB(      movt    \tmpreg, #:upper16:(\target - (8888f + 4))      )
 THUMB(      movw    \tmpreg, #:lower16:(\target - (8888f + 4))      )
 ARM(        ldr     \tmpreg, 8888f+4                                )
 8888:       add     pc, pc, \tmpreg
 ARM(        .word   \target - (8888b + 8)           )
.endm
movw/movt is preferred if available, since it circumvents the D-cache. And actually, I should rewrite the bl_far macro for v7 to use blx instead of adr+ldr to make better use of the return stack predictor or whatever it is called in the h/w
And, as Russell points out, I should put a PC_BIAS #define somewhere that assumes the correct value for the used mode, instead of the +4/+8 immediates.
So I am thinking along the lines of

Quoted 7 lines

.macro b_far, target, tmpreg
#if defined(CONFIG_CPU_32v7) || defined(CONFIG_CPU_32v7M) movt \tmpreg, #:upper16:(\target - (8888f + PC_BIAS)) movw \tmpreg, #:lower16:(\target - (8888f + PC_BIAS)) 8888: add pc, pc, \tmpreg
#else
ldr \tmpreg, =\target - (8888f + PC_BIAS)

Replying to self: this doesn't work

/home/ard/linux-2.6/arch/arm/kernel/sleep.S: Assembler messages:
/home/ard/linux-2.6/arch/arm/kernel/sleep.S:131: Error: constant expression expected -- `ldr ip,=__hyp_stub_install_secondary-8888f+4'

so the only way this is feasible is with an explicit literal, which kind of sucks indeed for Dcache performance

Any other ideas?

Quoted 16 lines

8888: add pc, pc, \tmpreg
#endif
.endm
.macro bl_far, target, tmpreg=ip
#if defined(CONFIG_CPU_32v7) || defined(CONFIG_CPU_32v7M) movt \tmpreg, #:upper16:(\target - (8887f + PC_BIAS)) movw \tmpreg, #:lower16:(\target - (8887f + PC_BIAS)) 8887: add \tmpreg, \tmpreg, pc
blx \tmpreg
#else
adr lr, BSYM(8887f)
b_far \target, \tmpreg
8887:
#endif
.endm

Nicolas Pitre

2015-03-12 22:26 UTC #12 lore raw

PATCH 3/6 ARM: add macro to perform far branches (b/bl)

Quoted 100 lines · Ard Biesheuvel

Quoted 89 lines · Ard Biesheuvel
Quoted 55 lines · Nicolas Pitre
Quoted 29 lines · Ard Biesheuvel
Quoted 18 lines · Nicolas Pitre
Quoted 16 lines · Ard Biesheuvel
These macros execute PC-relative branches, but with a larger reach than the 24 bits that are available in the b and bl opcodes.
Signed-off-by Ard Biesheuvel <[email protected]>
---
 arch/arm/include/asm/assembler.h | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
arch/arm/include/asm/assembler.h +0 -0
index f67fd3afebdf..bd08c3c1b73f 100644
@@ -108,6 +108,35 @@
      .endm
 #endif
 
Quoted 9 lines
arch/arm/include/asm/assembler.h line 116
Quoted 6 lines
arch/arm/include/asm/assembler.h +6 -0
+     /*
+      * Macros to emit relative branches that may exceed the range
+      * of the 24-bit immediate of the ordinary b/bl instructions.
+      * NOTE: this doesn't work with locally defined symbols, as they
+      * might lack the ARM/Thumb annotation (even if they are annotated
+      * as functions)
I really hope you won't need a far call with local symbols ever!
Quoted 3 lines
Well, if you use pushsection/popsection, then local, numbered labels you refer to can be quite far away in the output image, and those will not have the thumb bit set.
Indeed.
Quoted 18 lines
Quoted 17 lines
Quoted 4 lines
arch/arm/include/asm/assembler.h +4 -0
+      */
+     .macro  b_far, target, tmpreg
+#if defined(CONFIG_CPU_32v7) || defined(CONFIG_CPU_32v7M)
+ ARM(        movt    \tmpreg, #:upper16:(\target - (8888f + 8))      )
arch/arm/include/asm/assembler.h line 130
Quoted 10 lines
arch/arm/include/asm/assembler.h +10 -0
+ ARM(        movw    \tmpreg, #:lower16:(\target - (8888f + 8))      )
+ THUMB(      movt    \tmpreg, #:upper16:(\target - (8888f + 4))      )
+ THUMB(      movw    \tmpreg, #:lower16:(\target - (8888f + 4))      )
+8888:        add     pc, pc, \tmpreg
+#else
+     ldr     \tmpreg, 8889f
+8888:        add     pc, pc, \tmpreg
+     .align  2
+8889:
+ ARM(        .word   \target - (8888b + 8)           )
The Thumb relocation value is missing here.
Quoted 5 lines
Quoted 2 lines
Yes, this is bogus. But Thumb2 implies v7 or v7m, so it is not actually incorrect in this case.
The ".align 2" would be redundant in that case too.
Correct, the #else bit is essentially ARM only
Quoted 5 lines
Quoted 1 line
But I will fix it in the next version
Is it worth optimizing the ARM mode with movw/movt on ARMv7? If not then this could be simplified as only:
Quoted 8 lines
             .macro  b_far, target, tmpreg
 THUMB(      movt    \tmpreg, #:upper16:(\target - (8888f + 4))      )
 THUMB(      movw    \tmpreg, #:lower16:(\target - (8888f + 4))      )
 ARM(        ldr     \tmpreg, 8888f+4                                )
 8888:       add     pc, pc, \tmpreg
 ARM(        .word   \target - (8888b + 8)           )
.endm
movw/movt is preferred if available, since it circumvents the D-cache. And actually, I should rewrite the bl_far macro for v7 to use blx instead of adr+ldr to make better use of the return stack predictor or whatever it is called in the h/w
And, as Russell points out, I should put a PC_BIAS #define somewhere that assumes the correct value for the used mode, instead of the +4/+8 immediates.
So I am thinking along the lines of
Quoted 7 lines
.macro b_far, target, tmpreg
#if defined(CONFIG_CPU_32v7) || defined(CONFIG_CPU_32v7M) movt \tmpreg, #:upper16:(\target - (8888f + PC_BIAS)) movw \tmpreg, #:lower16:(\target - (8888f + PC_BIAS)) 8888: add pc, pc, \tmpreg
#else
ldr \tmpreg, =\target - (8888f + PC_BIAS)
Replying to self: this doesn't work

Quoted 8 lines

/home/ard/linux-2.6/arch/arm/kernel/sleep.S: Assembler messages:
/home/ard/linux-2.6/arch/arm/kernel/sleep.S:131: Error: constant expression expected -- `ldr ip,=__hyp_stub_install_secondary-8888f+4'
so the only way this is feasible is with an explicit literal, which kind of sucks indeed for Dcache performance
Any other ideas?

Let's not get overboard with this if the only place it is used is in non cache performance critical spots such as the resume code which is the only case so far.

Nicolas

Russell King - ARM Linux

2015-03-12 20:56 UTC #13 lore raw

PATCH 3/6 ARM: add macro to perform far branches (b/bl)

In reply to Ard Biesheuvel

Quoted 11 lines · Ard Biesheuvel

arch/arm/include/asm/assembler.h +11 -0

+	/*
+	 * Macros to emit relative branches that may exceed the range
+	 * of the 24-bit immediate of the ordinary b/bl instructions.
+	 * NOTE: this doesn't work with locally defined symbols, as they
+	 * might lack the ARM/Thumb annotation (even if they are annotated
+	 * as functions)
+	 */
+	.macro  b_far, target, tmpreg
+#if defined(CONFIG_CPU_32v7) || defined(CONFIG_CPU_32v7M)
+ ARM(	movt	\tmpreg, #:upper16:(\target - (8888f + 8))	)
+ ARM(	movw	\tmpreg, #:lower16:(\target - (8888f + 8))	)

arch/arm/include/asm/assembler.h line 131

Quoted 10 lines

arch/arm/include/asm/assembler.h +10 -0

+ THUMB(	movt    \tmpreg, #:upper16:(\target - (8888f + 4))	)
+ THUMB(	movw	\tmpreg, #:lower16:(\target - (8888f + 4))	)
+8888:	add	pc, pc, \tmpreg
+#else
+	ldr	\tmpreg, 8889f
+8888:	add	pc, pc, \tmpreg
+	.align 	2
+8889:
+ ARM(	.word   \target - (8888b + 8)           )
+#endif

I'm really hating this. It's potentially polluting the data cache (which relies on proximity of data to be effective) with instructions. I wonder whether we can use ldr \tmpreg, =\target - (8888b + 8) here, and let the assembler build some literal pools (maybe with appropriate .ltorg statements if necessary)?

Another reason I'm hating it is the difference in those movt and movw instructions just because we have a different PC offset between Thumb and ARM. A better way to deal with that would be some common definition somewhere of that offset.

Signature · 2 lines

FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Ard Biesheuvel

author

2015-03-12 17:38 UTC #14 lore raw

PATCH 4/6 ARM: use bl_far to call __hyp_stub_install_secondary from the .data section

In reply to Ard Biesheuvel

Signed-off-by Ard Biesheuvel <[email protected]>

---
 arch/arm/kernel/sleep.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/kernel/sleep.S +1 -1

index e1e60e5a7a27..0ea3813fedce 100644
@@ -128,7 +128,7 @@ ENDPROC(cpu_resume_after_mmu)
 ENTRY(cpu_resume)
 ARM_BE8(setend be)			@ ensure we are in BE mode
 #ifdef CONFIG_ARM_VIRT_EXT
-	bl	__hyp_stub_install_secondary
+	bl_far	__hyp_stub_install_secondary
 #endif
 	safe_svcmode_maskall r1
 	mov	r1, #0

Signature · 1 line

1.8.3.2

Ard Biesheuvel

author

2015-03-12 17:38 UTC #15 lore raw

PATCH 5/6 ARM: move the .idmap.text section closer to .head.text

In reply to Ard Biesheuvel

This moves the .idmap.text section closer to .head.text, so that relative branches are less likely to go out of range if the kernel text gets bigger.

Signed-off-by Ard Biesheuvel <[email protected]>

---
 arch/arm/kernel/vmlinux.lds.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/kernel/vmlinux.lds.S +1 -1

index e3b9403bd2d6..2e7b2220ef5f 100644
@@ -103,6 +103,7 @@ SECTIONS
 
 	.text : {			/* Real text segment		*/
 		_stext = .;		/* Text and read-only data	*/
+			IDMAP_TEXT
 			__exception_text_start = .;
 			*(.exception.text)
 			__exception_text_end = .;

@@ -111,7 +112,6 @@ SECTIONS
 			SCHED_TEXT
 			LOCK_TEXT
 			KPROBES_TEXT
-			IDMAP_TEXT
 #ifdef CONFIG_MMU
 			*(.fixup)
 #endif

Signature · 1 line

1.8.3.2

Nicolas Pitre

2015-03-12 20:33 UTC #16 lore raw

PATCH 5/6 ARM: move the .idmap.text section closer to .head.text

Quoted 5 lines · Ard Biesheuvel

This moves the .idmap.text section closer to .head.text, so that relative branches are less likely to go out of range if the kernel text gets bigger.
Signed-off-by Ard Biesheuvel <[email protected]>

Acked-by Nicolas Pitre <[email protected]>

Quoted 28 lines

---
 arch/arm/kernel/vmlinux.lds.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/kernel/vmlinux.lds.S +1 -1

index e3b9403bd2d6..2e7b2220ef5f 100644
@@ -103,6 +103,7 @@ SECTIONS
 
 	.text : {			/* Real text segment		*/
 		_stext = .;		/* Text and read-only data	*/
+			IDMAP_TEXT
 			__exception_text_start = .;
 			*(.exception.text)
 			__exception_text_end = .;

@@ -111,7 +112,6 @@ SECTIONS
 			SCHED_TEXT
 			LOCK_TEXT
 			KPROBES_TEXT
-			IDMAP_TEXT
 #ifdef CONFIG_MMU
 			*(.fixup)
 #endif

Signature · 1 line

1.8.3.2

Ard Biesheuvel

author

2015-03-12 17:38 UTC #17 lore raw

PATCH 6/6 ARM: keep .text and .fixup regions together

In reply to Ard Biesheuvel

Fixup snippets are put into a dedicated section so that they don't bloat cache lines with instructions that are usually not executed. But there is no reason to put all these snippets together at the far end of the .text output region, where the branch instruction they contain could go out of range if the kernel grows in size.

Instead, emit .text and .fixup regions together for each input object. They should still be out of the way, but not so far that they go out of range.

Signed-off-by Ard Biesheuvel <[email protected]>

---

Note that the TEXT_TEXT macro will emit *(.text) again but this should be harmless.

 arch/arm/kernel/vmlinux.lds.S | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

arch/arm/kernel/vmlinux.lds.S +3 -3

index 2e7b2220ef5f..01630c38fd6c 100644
@@ -108,13 +108,13 @@ SECTIONS
 			*(.exception.text)
 			__exception_text_end = .;
 			IRQENTRY_TEXT
+#ifdef CONFIG_MMU
+			*(.text .fixup)
+#endif
 			TEXT_TEXT
 			SCHED_TEXT
 			LOCK_TEXT
 			KPROBES_TEXT
-#ifdef CONFIG_MMU
-			*(.fixup)
-#endif
 			*(.gnu.warning)
 			*(.glue_7)
 			*(.glue_7t)

Signature · 1 line

1.8.3.2

Nicolas Pitre

2015-03-12 20:34 UTC #18 lore raw

PATCH 6/6 ARM: keep .text and .fixup regions together

Quoted 11 lines · Ard Biesheuvel

Fixup snippets are put into a dedicated section so that they don't bloat cache lines with instructions that are usually not executed. But there is no reason to put all these snippets together at the far end of the .text output region, where the branch instruction they contain could go out of range if the kernel grows in size.
Instead, emit .text and .fixup regions together for each input object. They should still be out of the way, but not so far that they go out of range.
Signed-off-by Ard Biesheuvel <[email protected]>

Acked-by Nicolas Pitre <[email protected]>

Quoted 33 lines

---

Note that the TEXT_TEXT macro will emit *(.text) again but this should be harmless.

 arch/arm/kernel/vmlinux.lds.S | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

arch/arm/kernel/vmlinux.lds.S +3 -3

index 2e7b2220ef5f..01630c38fd6c 100644
@@ -108,13 +108,13 @@ SECTIONS
 			*(.exception.text)
 			__exception_text_end = .;
 			IRQENTRY_TEXT
+#ifdef CONFIG_MMU
+			*(.text .fixup)
+#endif
 			TEXT_TEXT
 			SCHED_TEXT
 			LOCK_TEXT
 			KPROBES_TEXT
-#ifdef CONFIG_MMU
-			*(.fixup)
-#endif
 			*(.gnu.warning)
 			*(.glue_7)
 			*(.glue_7t)

Signature · 1 line

1.8.3.2

Russell King - ARM Linux

2015-03-12 21:10 UTC #19 lore raw

PATCH 6/6 ARM: keep .text and .fixup regions together

In reply to Ard Biesheuvel

Quoted 10 lines · Ard Biesheuvel

Fixup snippets are put into a dedicated section so that they don't bloat cache lines with instructions that are usually not executed. But there is no reason to put all these snippets together at the far end of the .text output region, where the branch instruction they contain could go out of range if the kernel grows in size.
Instead, emit .text and .fixup regions together for each input object. They should still be out of the way, but not so far that they go out of range.

Quoted 5 lines

Signed-off-by Ard Biesheuvel <[email protected]>
---
Note that the TEXT_TEXT macro will emit *(.text) again but this should be harmless.

However, I wonder if by doing this, we're weakening the ability for kallsyms final link to succeed:

/* .text section. Map to function alignment to avoid address changes
* during second ld run in second ld pass when generating System.map */

Can we not just move .fixup before TEXT_TEXT? The only thing between it and .text would be .text.hot.

Signature · 2 lines

FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Ard Biesheuvel

author

2015-03-12 21:18 UTC #20 lore raw

PATCH 6/6 ARM: keep .text and .fixup regions together

Quoted 17 lines · Russell King - ARM Linux

Quoted 10 lines · Ard Biesheuvel
Fixup snippets are put into a dedicated section so that they don't bloat cache lines with instructions that are usually not executed. But there is no reason to put all these snippets together at the far end of the .text output region, where the branch instruction they contain could go out of range if the kernel grows in size.
Instead, emit .text and .fixup regions together for each input object. They should still be out of the way, but not so far that they go out of range.
Quoted 5 lines
Signed-off-by Ard Biesheuvel <[email protected]>
---
Note that the TEXT_TEXT macro will emit *(.text) again but this should be harmless.

Quoted 9 lines

However, I wonder if by doing this, we're weakening the ability for kallsyms final link to succeed:
/* .text section. Map to function alignment to avoid address changes
* during second ld run in second ld pass when generating System.map */
Can we not just move .fixup before TEXT_TEXT? The only thing between it and .text would be .text.hot.

Putting .fixup before .text already helps, but not enough for the .config Arnd gave me that I have been testing this with.

What *(.text .fixup) does (i.e., putting both section names inside the parentheses), is emitting both sections for each input object file, so they will always be close to the object that it refers to, so it is not the same thing.

Russell King - ARM Linux

2015-03-12 21:22 UTC #21 lore raw

PATCH 6/6 ARM: keep .text and .fixup regions together

Quoted 29 lines · Ard Biesheuvel

Quoted 17 lines · Russell King - ARM Linux
Quoted 10 lines · Ard Biesheuvel
Fixup snippets are put into a dedicated section so that they don't bloat cache lines with instructions that are usually not executed. But there is no reason to put all these snippets together at the far end of the .text output region, where the branch instruction they contain could go out of range if the kernel grows in size.
Instead, emit .text and .fixup regions together for each input object. They should still be out of the way, but not so far that they go out of range.
Quoted 5 lines
Signed-off-by Ard Biesheuvel <[email protected]>
---
Note that the TEXT_TEXT macro will emit *(.text) again but this should be harmless.
Quoted 9 lines
However, I wonder if by doing this, we're weakening the ability for kallsyms final link to succeed:
/* .text section. Map to function alignment to avoid address changes
* during second ld run in second ld pass when generating System.map */
Can we not just move .fixup before TEXT_TEXT? The only thing between it and .text would be .text.hot.

Quoted 7 lines

Putting .fixup before .text already helps, but not enough for the .config Arnd gave me that I have been testing this with.
What *(.text .fixup) does (i.e., putting both section names inside the parentheses), is emitting both sections for each input object file, so they will always be close to the object that it refers to, so it is not the same thing.

I'll suggest a different solution then - how about modifying asm-generic/vmlinux.lds.h to change *(.text) to *(.text .text.fixup) and we move all the .fixup sections to .text.fixup ? Arnd?

Signature · 2 lines

FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Arnd Bergmann

2015-03-13 11:18 UTC #22 lore raw

PATCH 6/6 ARM: keep .text and .fixup regions together

Quoted 17 lines · On Thursday 12 March 2015 21:22:02 Russell King - ARM Linux wrote:

Quoted 16 lines · Ard Biesheuvel
Quoted 12 lines
Quoted 2 lines
Note that the TEXT_TEXT macro will emit *(.text) again but this should be harmless.
However, I wonder if by doing this, we're weakening the ability for kallsyms final link to succeed:
/* .text section. Map to function alignment to avoid address changes
* during second ld run in second ld pass when generating System.map */
Can we not just move .fixup before TEXT_TEXT? The only thing between it and .text would be .text.hot.
Putting .fixup before .text already helps, but not enough for the .config Arnd gave me that I have been testing this with.

Quoted 8 lines

Quoted 4 lines
What *(.text .fixup) does (i.e., putting both section names inside the parentheses), is emitting both sections for each input object file, so they will always be close to the object that it refers to, so it is not the same thing.
I'll suggest a different solution then - how about modifying asm-generic/vmlinux.lds.h to change *(.text) to *(.text .text.fixup) and we move all the .fixup sections to .text.fixup ? Arnd?

No objections from me, but I really don't know enough about the possible side-effects this may have on the other architectures, so we need to run this by the linux-arch mailing list.

Arnd

Ard Biesheuvel

author

2015-03-13 11:26 UTC #23 lore raw

PATCH 6/6 ARM: keep .text and .fixup regions together

Quoted 23 lines · Arnd Bergmann

Quoted 22 lines · On Thursday 12 March 2015 21:22:02 Russell King - ARM Linux wrote:
Quoted 20 lines · Ard Biesheuvel
Quoted 12 lines
Quoted 2 lines
Note that the TEXT_TEXT macro will emit *(.text) again but this should be harmless.
However, I wonder if by doing this, we're weakening the ability for kallsyms final link to succeed:
/* .text section. Map to function alignment to avoid address changes
* during second ld run in second ld pass when generating System.map */
Can we not just move .fixup before TEXT_TEXT? The only thing between it and .text would be .text.hot.
Putting .fixup before .text already helps, but not enough for the .config Arnd gave me that I have been testing this with.
What *(.text .fixup) does (i.e., putting both section names inside the parentheses), is emitting both sections for each input object file, so they will always be close to the object that it refers to, so it is not the same thing.

Quoted 8 lines

Quoted 3 lines
I'll suggest a different solution then - how about modifying asm-generic/vmlinux.lds.h to change *(.text) to *(.text .text.fixup) and we move all the .fixup sections to .text.fixup ? Arnd?
No objections from me, but I really don't know enough about the possible side-effects this may have on the other architectures, so we need to run this by the linux-arch mailing list.

I don't think it could affect any other architecture if nobody is populating .text.fixup yet.

Arnd Bergmann

2015-03-13 11:52 UTC #24 lore raw

PATCH 6/6 ARM: keep .text and .fixup regions together

Quoted 28 lines · On Friday 13 March 2015 12:26:11 Ard Biesheuvel wrote:

Quoted 27 lines · Arnd Bergmann
Quoted 25 lines · On Thursday 12 March 2015 21:22:02 Russell King - ARM Linux wrote:
Quoted 13 lines · Ard Biesheuvel
Quoted 12 lines
Quoted 2 lines
Note that the TEXT_TEXT macro will emit *(.text) again but this should be harmless.
However, I wonder if by doing this, we're weakening the ability for kallsyms final link to succeed:
/* .text section. Map to function alignment to avoid address changes
* during second ld run in second ld pass when generating System.map */
Can we not just move .fixup before TEXT_TEXT? The only thing between it and .text would be .text.hot.
Quoted 7 lines
Putting .fixup before .text already helps, but not enough for the .config Arnd gave me that I have been testing this with.
What *(.text .fixup) does (i.e., putting both section names inside the parentheses), is emitting both sections for each input object file, so they will always be close to the object that it refers to, so it is not the same thing.
I'll suggest a different solution then - how about modifying asm-generic/vmlinux.lds.h to change *(.text) to *(.text .text.fixup) and we move all the .fixup sections to .text.fixup ? Arnd?

Quoted 7 lines

Quoted 4 lines
No objections from me, but I really don't know enough about the possible side-effects this may have on the other architectures, so we need to run this by the linux-arch mailing list.
I don't think it could affect any other architecture if nobody is populating .text.fixup yet.

Ah, I missed that part of the suggestion. Yes, sounds good to me then.

Arnd