Skip to contentSkip to conversation

powerpc/ppc64: Allow allmodconfig to build (finally !)

PATCH In review Benjamin Herrenschmidt 4 participants 18 messages May 12, 2014 – Jun 12, 2014 PowerPC

lore
Share & tools
lore

Benjamin Herrenschmidt

author
#0 lore raw

PATCH 1/1 powerpc/ppc64: Allow allmodconfig to build (finally !)

This shuffles code around in exceptions-64s.S in order to allow an allmodconfig build to succeed.

The main problems were:

- We have a fixed hole from 0x7000 to 0x8000 for use by FW,
under some circumstances the code before that would grow too big and hit the . = 0x7000

- The various attempts at making space in there would trigger
cases where short conditional branches from assembly would no longer be able to reach their target. This is especially nasty when these branches reside in alternate feature sections which are appended at the end of each .o file

This fixes it by essentially moving all the "second level" exception handlers to after the hole and moving a couple of functions near the hole itself so they sit at reachable distance of both the first level handlers (before the hole) and the alternate feature sections (end of file).

In the long run, if we start hitting this again, we'll probably have to split the file in two, probably at the hole location, to keep the alt sections used by the first level handlers close to them, and move everything else further away.

But for now, this will do.

Signed-off-by Benjamin Herrenschmidt <[email protected]>

---

arch/powerpc/kernel/exceptions-64s.S +186 -235
index 3afd391..833a68d 100644
@@ -533,70 +533,6 @@ do_stab_bolted_pSeries:
 	KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x900)
 	KVM_HANDLER(PACA_EXGEN, EXC_HV, 0x982)
 
-#ifdef CONFIG_PPC_DENORMALISATION
-denorm_assist:
-BEGIN_FTR_SECTION
-/*
- * To denormalise we need to move a copy of the register to itself.
- * For POWER6 do that here for all FP regs.
- */
-	mfmsr	r10
-	ori	r10,r10,(MSR_FP|MSR_FE0|MSR_FE1)
-	xori	r10,r10,(MSR_FE0|MSR_FE1)
-	mtmsrd	r10
-	sync
-
-#define FMR2(n)  fmr (n), (n) ; fmr n+1, n+1
-#define FMR4(n)  FMR2(n) ; FMR2(n+2)
-#define FMR8(n)  FMR4(n) ; FMR4(n+4)
-#define FMR16(n) FMR8(n) ; FMR8(n+8)
-#define FMR32(n) FMR16(n) ; FMR16(n+16)
-	FMR32(0)
-
-FTR_SECTION_ELSE
-/*
- * To denormalise we need to move a copy of the register to itself.
- * For POWER7 do that here for the first 32 VSX registers only.
- */
-	mfmsr	r10
-	oris	r10,r10,MSR_VSX@h
-	mtmsrd	r10
-	sync
-
-#define XVCPSGNDP2(n) XVCPSGNDP(n,n,n) ; XVCPSGNDP(n+1,n+1,n+1)
-#define XVCPSGNDP4(n) XVCPSGNDP2(n) ; XVCPSGNDP2(n+2)
-#define XVCPSGNDP8(n) XVCPSGNDP4(n) ; XVCPSGNDP4(n+4)
-#define XVCPSGNDP16(n) XVCPSGNDP8(n) ; XVCPSGNDP8(n+8)
-#define XVCPSGNDP32(n) XVCPSGNDP16(n) ; XVCPSGNDP16(n+16)
-	XVCPSGNDP32(0)
-
-ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
-
-BEGIN_FTR_SECTION
-	b	denorm_done
-END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
-/*
- * To denormalise we need to move a copy of the register to itself.
- * For POWER8 we need to do that for all 64 VSX registers
- */
-	XVCPSGNDP32(32)
-denorm_done:
-	mtspr	SPRN_HSRR0,r11
-	mtcrf	0x80,r9
-	ld	r9,PACA_EXGEN+EX_R9(r13)
-	RESTORE_PPR_PACA(PACA_EXGEN, r10)
-BEGIN_FTR_SECTION
-	ld	r10,PACA_EXGEN+EX_CFAR(r13)
-	mtspr	SPRN_CFAR,r10
-END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
-	ld	r10,PACA_EXGEN+EX_R10(r13)
-	ld	r11,PACA_EXGEN+EX_R11(r13)
-	ld	r12,PACA_EXGEN+EX_R12(r13)
-	ld	r13,PACA_EXGEN+EX_R13(r13)
-	HRFID
-	b	.
-#endif
-
 	.align	7
 	/* moved from 0xe00 */
 	STD_EXCEPTION_HV_OOL(0xe02, h_data_storage)

@@ -623,43 +559,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
 	KVM_HANDLER(PACA_EXGEN, EXC_HV, 0xf82)
 
 /*
- * An interrupt came in while soft-disabled. We set paca->irq_happened, then:
- * - If it was a decrementer interrupt, we bump the dec to max and and return.
- * - If it was a doorbell we return immediately since doorbells are edge
- *   triggered and won't automatically refire.
- * - else we hard disable and return.
- * This is called with r10 containing the value to OR to the paca field.
- */
-#define MASKED_INTERRUPT(_H)				\
-masked_##_H##interrupt:					\
-	std	r11,PACA_EXGEN+EX_R11(r13);		\
-	lbz	r11,PACAIRQHAPPENED(r13);		\
-	or	r11,r11,r10;				\
-	stb	r11,PACAIRQHAPPENED(r13);		\
-	cmpwi	r10,PACA_IRQ_DEC;			\
-	bne	1f;					\
-	lis	r10,0x7fff;				\
-	ori	r10,r10,0xffff;				\
-	mtspr	SPRN_DEC,r10;				\
-	b	2f;					\
-1:	cmpwi	r10,PACA_IRQ_DBELL;			\
-	beq	2f;					\
-	mfspr	r10,SPRN_##_H##SRR1;			\
-	rldicl	r10,r10,48,1; /* clear MSR_EE */	\
-	rotldi	r10,r10,16;				\
-	mtspr	SPRN_##_H##SRR1,r10;			\
-2:	mtcrf	0x80,r9;				\
-	ld	r9,PACA_EXGEN+EX_R9(r13);		\
-	ld	r10,PACA_EXGEN+EX_R10(r13);		\
-	ld	r11,PACA_EXGEN+EX_R11(r13);		\
-	GET_SCRATCH0(r13);				\
-	##_H##rfid;					\
-	b	.
-	
-	MASKED_INTERRUPT()
-	MASKED_INTERRUPT(H)
-
-/*
  * Called from arch_local_irq_enable when an interrupt needs
  * to be resent. r3 contains 0x500, 0x900, 0xa00 or 0xe80 to indicate
  * which kind of interrupt. MSR:EE is already off. We generate a

@@ -759,50 +658,6 @@ kvmppc_skip_Hinterrupt:
 	b	.
 #endif
 
-/*
- * Code from here down to __end_handlers is invoked from the
- * exception prologs above.  Because the prologs assemble the
- * addresses of these handlers using the LOAD_HANDLER macro,
- * which uses an ori instruction, these handlers must be in
- * the first 64k of the kernel image.
- */
-
-/*** Common interrupt handlers ***/
-
-	STD_EXCEPTION_COMMON(0x100, system_reset, .system_reset_exception)
-
-	STD_EXCEPTION_COMMON_ASYNC(0x500, hardware_interrupt, do_IRQ)
-	STD_EXCEPTION_COMMON_ASYNC(0x900, decrementer, .timer_interrupt)
-	STD_EXCEPTION_COMMON(0x980, hdecrementer, .hdec_interrupt)
-#ifdef CONFIG_PPC_DOORBELL
-	STD_EXCEPTION_COMMON_ASYNC(0xa00, doorbell_super, .doorbell_exception)
-#else
-	STD_EXCEPTION_COMMON_ASYNC(0xa00, doorbell_super, .unknown_exception)
-#endif
-	STD_EXCEPTION_COMMON(0xb00, trap_0b, .unknown_exception)
-	STD_EXCEPTION_COMMON(0xd00, single_step, .single_step_exception)
-	STD_EXCEPTION_COMMON(0xe00, trap_0e, .unknown_exception)
-	STD_EXCEPTION_COMMON(0xe40, emulation_assist, .emulation_assist_interrupt)
-	STD_EXCEPTION_COMMON(0xe60, hmi_exception, .unknown_exception)
-#ifdef CONFIG_PPC_DOORBELL
-	STD_EXCEPTION_COMMON_ASYNC(0xe80, h_doorbell, .doorbell_exception)
-#else
-	STD_EXCEPTION_COMMON_ASYNC(0xe80, h_doorbell, .unknown_exception)
-#endif
-	STD_EXCEPTION_COMMON_ASYNC(0xf00, performance_monitor, .performance_monitor_exception)
-	STD_EXCEPTION_COMMON(0x1300, instruction_breakpoint, .instruction_breakpoint_exception)
-	STD_EXCEPTION_COMMON(0x1502, denorm, .unknown_exception)
-#ifdef CONFIG_ALTIVEC
-	STD_EXCEPTION_COMMON(0x1700, altivec_assist, .altivec_assist_exception)
-#else
-	STD_EXCEPTION_COMMON(0x1700, altivec_assist, .unknown_exception)
-#endif
-#ifdef CONFIG_CBE_RAS
-	STD_EXCEPTION_COMMON(0x1200, cbe_system_error, .cbe_system_error_exception)
-	STD_EXCEPTION_COMMON(0x1600, cbe_maintenance, .cbe_maintenance_exception)
-	STD_EXCEPTION_COMMON(0x1800, cbe_thermal, .cbe_thermal_exception)
-#endif /* CONFIG_CBE_RAS */
-
 	/*
 	 * Relocation-on interrupts: A subset of the interrupts can be delivered
 	 * with IR=1/DR=1, if AIL==2 and MSR.HV won't be changed by delivering

@@ -949,6 +804,17 @@ hv_facility_unavailable_relon_trampoline:
 #endif
 	STD_RELON_EXCEPTION_PSERIES(0x5700, 0x1700, altivec_assist)
 
+	/* Equivalents to the above handlers for relocation-on interrupt vectors */
+	STD_RELON_EXCEPTION_HV_OOL(0xe40, emulation_assist)
+	MASKABLE_RELON_EXCEPTION_HV_OOL(0xe80, h_doorbell)
+
+	STD_RELON_EXCEPTION_PSERIES_OOL(0xf00, performance_monitor)
+	STD_RELON_EXCEPTION_PSERIES_OOL(0xf20, altivec_unavailable)
+	STD_RELON_EXCEPTION_PSERIES_OOL(0xf40, vsx_unavailable)
+	STD_RELON_EXCEPTION_PSERIES_OOL(0xf60, facility_unavailable)
+	STD_RELON_EXCEPTION_HV_OOL(0xf80, hv_facility_unavailable)
+
+
 	/* Other future vectors */
 	.align	7
 	.globl	__end_interrupts

@@ -1028,11 +894,183 @@ END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
 	bl	.kernel_bad_stack
 	b	1b
 
+
+#if defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV)
 /*
- * Here r13 points to the paca, r9 contains the saved CR,
- * SRR0 and SRR1 are saved in r11 and r12,
- * r9 - r13 are saved in paca->exgen.
+ * Data area reserved for FWNMI option.
+ * This address (0x7000) is fixed by the RPA.
  */
+	.= 0x7000
+	.globl fwnmi_data_area
+fwnmi_data_area:
+
+	/* pseries and powernv need to keep the whole page from
+	 * 0x7000 to 0x8000 free for use by the firmware
+	 */
+	. = 0x8000
+#endif /* defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV) */
+
+/*
+ * Denorm interrupt assist moved out of line to here, where it remains
+ * close enough to the call site which uses a small conditional branch
+ */
+#ifdef CONFIG_PPC_DENORMALISATION
+denorm_assist:
+BEGIN_FTR_SECTION
+/*
+ * To denormalise we need to move a copy of the register to itself.
+ * For POWER6 do that here for all FP regs.
+ */
+	mfmsr	r10
+	ori	r10,r10,(MSR_FP|MSR_FE0|MSR_FE1)
+	xori	r10,r10,(MSR_FE0|MSR_FE1)
+	mtmsrd	r10
+	sync
+
+#define FMR2(n)  fmr (n), (n) ; fmr n+1, n+1
+#define FMR4(n)  FMR2(n) ; FMR2(n+2)
+#define FMR8(n)  FMR4(n) ; FMR4(n+4)
+#define FMR16(n) FMR8(n) ; FMR8(n+8)
+#define FMR32(n) FMR16(n) ; FMR16(n+16)
+	FMR32(0)
+
+FTR_SECTION_ELSE
+/*
+ * To denormalise we need to move a copy of the register to itself.
+ * For POWER7 do that here for the first 32 VSX registers only.
+ */
+	mfmsr	r10
+	oris	r10,r10,MSR_VSX@h
+	mtmsrd	r10
+	sync
+
+#define XVCPSGNDP2(n) XVCPSGNDP(n,n,n) ; XVCPSGNDP(n+1,n+1,n+1)
+#define XVCPSGNDP4(n) XVCPSGNDP2(n) ; XVCPSGNDP2(n+2)
+#define XVCPSGNDP8(n) XVCPSGNDP4(n) ; XVCPSGNDP4(n+4)
+#define XVCPSGNDP16(n) XVCPSGNDP8(n) ; XVCPSGNDP8(n+8)
+#define XVCPSGNDP32(n) XVCPSGNDP16(n) ; XVCPSGNDP16(n+16)
+	XVCPSGNDP32(0)
+
+ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
+
+BEGIN_FTR_SECTION
+	b	denorm_done
+END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
+/*
+ * To denormalise we need to move a copy of the register to itself.
+ * For POWER8 we need to do that for all 64 VSX registers
+ */
+	XVCPSGNDP32(32)
+denorm_done:
+	mtspr	SPRN_HSRR0,r11
+	mtcrf	0x80,r9
+	ld	r9,PACA_EXGEN+EX_R9(r13)
+	RESTORE_PPR_PACA(PACA_EXGEN, r10)
+BEGIN_FTR_SECTION
+	ld	r10,PACA_EXGEN+EX_CFAR(r13)
+	mtspr	SPRN_CFAR,r10
+END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
+	ld	r10,PACA_EXGEN+EX_R10(r13)
+	ld	r11,PACA_EXGEN+EX_R11(r13)
+	ld	r12,PACA_EXGEN+EX_R12(r13)
+	ld	r13,PACA_EXGEN+EX_R13(r13)
+	HRFID
+	b	.
+#endif
+
+/*
+ * An interrupt came in while soft-disabled. We set paca->irq_happened, then:
+ * - If it was a decrementer interrupt, we bump the dec to max and and return.
+ * - If it was a doorbell we return immediately since doorbells are edge
+ *   triggered and won't automatically refire.
+ * - else we hard disable and return.
+ * This is called with r10 containing the value to OR to the paca field.
+ *
+ * Warning: This code is reached using a (small) conditional branch from both
+ * the 1st level exception handlers below 0x8000 and the alternate feature
+ * sections of that file which the linker puts right after the text in here.
+ *
+ * For that to work, we thus need this code to be roughly near the "middle"
+ * so that we can reach it with <32k offsets. Here works... for now.
+ */
+#define MASKED_INTERRUPT(_H)				\
+masked_##_H##interrupt:					\
+	std	r11,PACA_EXGEN+EX_R11(r13);		\
+	lbz	r11,PACAIRQHAPPENED(r13);		\
+	or	r11,r11,r10;				\
+	stb	r11,PACAIRQHAPPENED(r13);		\
+	cmpwi	r10,PACA_IRQ_DEC;			\
+	bne	1f;					\
+	lis	r10,0x7fff;				\
+	ori	r10,r10,0xffff;				\
+	mtspr	SPRN_DEC,r10;				\
+	b	2f;					\
+1:	cmpwi	r10,PACA_IRQ_DBELL;			\
+	beq	2f;					\
+	mfspr	r10,SPRN_##_H##SRR1;			\
+	rldicl	r10,r10,48,1; /* clear MSR_EE */	\
+	rotldi	r10,r10,16;				\
+	mtspr	SPRN_##_H##SRR1,r10;			\
+2:	mtcrf	0x80,r9;				\
+	ld	r9,PACA_EXGEN+EX_R9(r13);		\
+	ld	r10,PACA_EXGEN+EX_R10(r13);		\
+	ld	r11,PACA_EXGEN+EX_R11(r13);		\
+	GET_SCRATCH0(r13);				\
+	##_H##rfid;					\
+	b	.
+
+	MASKED_INTERRUPT()
+	MASKED_INTERRUPT(H)
+
+/*
+ * Code from here down to __end_handlers is invoked from the
+ * exception prologs above.  Because the prologs assemble the
+ * addresses of these handlers using the LOAD_HANDLER macro,
+ * which uses an ori instruction, these handlers must be in
+ * the first 64k of the kernel image.
+ */
+
+/*** Common interrupt handlers ***/
+
+	STD_EXCEPTION_COMMON(0x100, system_reset, .system_reset_exception)
+
+	STD_EXCEPTION_COMMON_ASYNC(0x500, hardware_interrupt, do_IRQ)
+	STD_EXCEPTION_COMMON_ASYNC(0x900, decrementer, .timer_interrupt)
+	STD_EXCEPTION_COMMON(0x980, hdecrementer, .hdec_interrupt)
+#ifdef CONFIG_PPC_DOORBELL
+	STD_EXCEPTION_COMMON_ASYNC(0xa00, doorbell_super, .doorbell_exception)
+#else
+	STD_EXCEPTION_COMMON_ASYNC(0xa00, doorbell_super, .unknown_exception)
+#endif
+	STD_EXCEPTION_COMMON(0xb00, trap_0b, .unknown_exception)
+	STD_EXCEPTION_COMMON(0xd00, single_step, .single_step_exception)
+	STD_EXCEPTION_COMMON(0xe00, trap_0e, .unknown_exception)
+	STD_EXCEPTION_COMMON(0xe40, emulation_assist, .emulation_assist_interrupt)
+	STD_EXCEPTION_COMMON(0xe60, hmi_exception, .unknown_exception)
+#ifdef CONFIG_PPC_DOORBELL
+	STD_EXCEPTION_COMMON_ASYNC(0xe80, h_doorbell, .doorbell_exception)
+#else
+	STD_EXCEPTION_COMMON_ASYNC(0xe80, h_doorbell, .unknown_exception)
+#endif
+	STD_EXCEPTION_COMMON_ASYNC(0xf00, performance_monitor, .performance_monitor_exception)
+	STD_EXCEPTION_COMMON(0x1300, instruction_breakpoint, .instruction_breakpoint_exception)
+	STD_EXCEPTION_COMMON(0x1502, denorm, .unknown_exception)
+#ifdef CONFIG_ALTIVEC
+	STD_EXCEPTION_COMMON(0x1700, altivec_assist, .altivec_assist_exception)
+#else
+	STD_EXCEPTION_COMMON(0x1700, altivec_assist, .unknown_exception)
+#endif
+#ifdef CONFIG_CBE_RAS
+	STD_EXCEPTION_COMMON(0x1200, cbe_system_error, .cbe_system_error_exception)
+	STD_EXCEPTION_COMMON(0x1600, cbe_maintenance, .cbe_maintenance_exception)
+	STD_EXCEPTION_COMMON(0x1800, cbe_thermal, .cbe_thermal_exception)
+#endif /* CONFIG_CBE_RAS */
+
+	/*
+	 * Here r13 points to the paca, r9 contains the saved CR,
+	 * SRR0 and SRR1 are saved in r11 and r12,
+	 * r9 - r13 are saved in paca->exgen.
+	 */
 	.align	7
 	.globl data_access_common
 data_access_common:

@@ -1075,69 +1113,6 @@ instruction_access_common:
 
 	STD_EXCEPTION_COMMON(0xe20, h_instr_storage, .unknown_exception)
 
-/*
- * Here is the common SLB miss user that is used when going to virtual
- * mode for SLB misses, that is currently not used
- */
-#ifdef __DISABLED__
-	.align	7
-	.globl	slb_miss_user_common
-slb_miss_user_common:
-	mflr	r10
-	std	r3,PACA_EXGEN+EX_DAR(r13)
-	stw	r9,PACA_EXGEN+EX_CCR(r13)
-	std	r10,PACA_EXGEN+EX_LR(r13)
-	std	r11,PACA_EXGEN+EX_SRR0(r13)
-	bl	.slb_allocate_user
-
-	ld	r10,PACA_EXGEN+EX_LR(r13)
-	ld	r3,PACA_EXGEN+EX_R3(r13)
-	lwz	r9,PACA_EXGEN+EX_CCR(r13)
-	ld	r11,PACA_EXGEN+EX_SRR0(r13)
-	mtlr	r10
-	beq-	slb_miss_fault
-
-	andi.	r10,r12,MSR_RI		/* check for unrecoverable exception */
-	beq-	unrecov_user_slb
-	mfmsr	r10
-
-.machine push
-.machine "power4"
-	mtcrf	0x80,r9
-.machine pop
-
-	clrrdi	r10,r10,2		/* clear RI before setting SRR0/1 */
-	mtmsrd	r10,1
-
-	mtspr	SRR0,r11
-	mtspr	SRR1,r12
-
-	ld	r9,PACA_EXGEN+EX_R9(r13)
-	ld	r10,PACA_EXGEN+EX_R10(r13)
-	ld	r11,PACA_EXGEN+EX_R11(r13)
-	ld	r12,PACA_EXGEN+EX_R12(r13)
-	ld	r13,PACA_EXGEN+EX_R13(r13)
-	rfid
-	b	.
-
-slb_miss_fault:
-	EXCEPTION_PROLOG_COMMON(0x380, PACA_EXGEN)
-	ld	r4,PACA_EXGEN+EX_DAR(r13)
-	li	r5,0
-	std	r4,_DAR(r1)
-	std	r5,_DSISR(r1)
-	b	handle_page_fault
-
-unrecov_user_slb:
-	EXCEPTION_PROLOG_COMMON(0x4200, PACA_EXGEN)
-	DISABLE_INTS
-	bl	.save_nvgprs
-1:	addi	r3,r1,STACK_FRAME_OVERHEAD
-	bl	.unrecoverable_exception
-	b	1b
-
-#endif /* __DISABLED__ */
-
 
 	/*
 	 * Machine check is different because we use a different

@@ -1297,30 +1272,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
 	.globl	__end_handlers
 __end_handlers:
 
-	/* Equivalents to the above handlers for relocation-on interrupt vectors */
-	STD_RELON_EXCEPTION_HV_OOL(0xe40, emulation_assist)
-	MASKABLE_RELON_EXCEPTION_HV_OOL(0xe80, h_doorbell)
-
-	STD_RELON_EXCEPTION_PSERIES_OOL(0xf00, performance_monitor)
-	STD_RELON_EXCEPTION_PSERIES_OOL(0xf20, altivec_unavailable)
-	STD_RELON_EXCEPTION_PSERIES_OOL(0xf40, vsx_unavailable)
-	STD_RELON_EXCEPTION_PSERIES_OOL(0xf60, facility_unavailable)
-	STD_RELON_EXCEPTION_HV_OOL(0xf80, hv_facility_unavailable)
-
-#if defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV)
-/*
- * Data area reserved for FWNMI option.
- * This address (0x7000) is fixed by the RPA.
- */
-	.= 0x7000
-	.globl fwnmi_data_area
-fwnmi_data_area:
-
-	/* pseries and powernv need to keep the whole page from
-	 * 0x7000 to 0x8000 free for use by the firmware
-	 */
-	. = 0x8000
-#endif /* defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV) */
 
 /* Space for CPU0's segment table */
 	.balign 4096
#1 lore raw
Quoted 21 lines · Benjamin Herrenschmidt

This shuffles code around in exceptions-64s.S in order to allow an allmodconfig build to succeed.

The main problems were:

- We have a fixed hole from 0x7000 to 0x8000 for use by FW,
under some circumstances the code before that would grow too big and hit the . = 0x7000

- The various attempts at making space in there would trigger
cases where short conditional branches from assembly would no longer be able to reach their target. This is especially nasty when these branches reside in alternate feature sections which are appended at the end of each .o file

This fixes it by essentially moving all the "second level" exception handlers to after the hole and moving a couple of functions near the hole itself so they sit at reachable distance of both the first level handlers (before the hole) and the alternate feature sections (end of file).

Quoted 9 lines

In the long run, if we start hitting this again, we'll probably have to split the file in two, probably at the hole location, to keep the alt sections used by the first level handlers close to them, and move everything else further away.

But for now, this will do.

Signed-off-by Benjamin Herrenschmidt <[email protected]>

Ben,

After applying this patch, I get

arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range (0x000000000000814c is not between 0xffffffffffff8000 and 0x0000000000007ffc) arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range (0x000000000000814c is not between 0xffffffffffff8000 and 0x0000000000007ffc)

with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and powerpc:maple_defconfig.

This is on top of v3.15-rc5. Any idea what is going on ?

Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1).

Thanks,
Guenter

author
#2 lore raw
Quoted 7 lines · Guenter Roeck

After applying this patch, I get

arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range (0x000000000000814c is not between 0xffffffffffff8000 and 0x0000000000007ffc) arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range (0x000000000000814c is not between 0xffffffffffff8000 and 0x0000000000007ffc)

Quoted 6 lines

with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and powerpc:maple_defconfig.

This is on top of v3.15-rc5. Any idea what is going on ?

Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1).

Interesting... works with all my test configs using 4.7.3...

I don't have my tree at hand right now, I'll check what that means tomorrow see if I can find a workaround.

Cheers,
Ben.

#3 lore raw
Quoted 12 lines · Benjamin Herrenschmidt
Quoted 10 lines · Guenter Roeck

After applying this patch, I get

arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range (0x000000000000814c is not between 0xffffffffffff8000 and 0x0000000000007ffc) arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range (0x000000000000814c is not between 0xffffffffffff8000 and 0x0000000000007ffc)

with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and powerpc:maple_defconfig.

Quoted 9 lines
Quoted 3 lines

This is on top of v3.15-rc5. Any idea what is going on ?

Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1).

Interesting... works with all my test configs using 4.7.3...

I don't have my tree at hand right now, I'll check what that means tomorrow see if I can find a workaround.

Maybe something is wrong with my toolchain. I'll try to find a more recent one.

Guenter

#4 lore raw
In reply to Benjamin Herrenschmidt
Quoted 12 lines · Benjamin Herrenschmidt
Quoted 10 lines · Guenter Roeck

After applying this patch, I get

arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range (0x000000000000814c is not between 0xffffffffffff8000 and 0x0000000000007ffc) arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range (0x000000000000814c is not between 0xffffffffffff8000 and 0x0000000000007ffc)

with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and powerpc:maple_defconfig.

Quoted 9 lines
Quoted 3 lines

This is on top of v3.15-rc5. Any idea what is going on ?

Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1).

Interesting... works with all my test configs using 4.7.3...

I don't have my tree at hand right now, I'll check what that means tomorrow see if I can find a workaround.

It works for me with gcc 4.8.2 (build from yocto 1.6.0).

Is asking people to use gcc 4.7.3 or later acceptable ?

Guenter

#5 lore raw

Hi Guenter,

Quoted 18 lines · On Tue, 13 May 2014 10:17:49 -0700 Guenter Roeck <[email protected]> wrote:
Quoted 16 lines · Benjamin Herrenschmidt
Quoted 13 lines · Guenter Roeck

After applying this patch, I get

arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range (0x000000000000814c is not between 0xffffffffffff8000 and 0x0000000000007ffc) arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range (0x000000000000814c is not between 0xffffffffffff8000 and 0x0000000000007ffc)

with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and powerpc:maple_defconfig.

This is on top of v3.15-rc5. Any idea what is going on ?

Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1).

Quoted 8 lines
Quoted 5 lines

Interesting... works with all my test configs using 4.7.3...

I don't have my tree at hand right now, I'll check what that means tomorrow see if I can find a workaround.

It works for me with gcc 4.8.2 (build from yocto 1.6.0).

Is asking people to use gcc 4.7.3 or later acceptable ?

OK, this appears to be an assembler bug.

$ cat test.s
	.text
x:
	.pushsection	b, "a"
	beq y
	.popsection
	.=0x80000
y:
$ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version
GNU assembler (GNU Binutils) 2.22
This assembler was configured for a target of `powerpc64-linux'.
$ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o test.o test.s 
test.s: Assembler messages:
test.s:4: Error: operand out of range (0x0000000000080000 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
$ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version
GNU assembler (GNU Binutils) 2.23.52.20130512
This assembler was configured for a target of `powerpc64-linux'.
$ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o test.o test.s 
(no error)

Alan, can you shed light on when it was fixed?

Signature · 2 lines
Cheers,
Stephen Rothwell                    [email protected]
#6 lore raw
Quoted 52 lines · Stephen Rothwell

Hi Guenter,

Quoted 18 lines · On Tue, 13 May 2014 10:17:49 -0700 Guenter Roeck <[email protected]> wrote:
Quoted 16 lines · Benjamin Herrenschmidt
Quoted 13 lines · Guenter Roeck

After applying this patch, I get

arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range (0x000000000000814c is not between 0xffffffffffff8000 and 0x0000000000007ffc) arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range (0x000000000000814c is not between 0xffffffffffff8000 and 0x0000000000007ffc)

with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and powerpc:maple_defconfig.

This is on top of v3.15-rc5. Any idea what is going on ?

Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1).

Quoted 8 lines
Quoted 5 lines

Interesting... works with all my test configs using 4.7.3...

I don't have my tree at hand right now, I'll check what that means tomorrow see if I can find a workaround.

It works for me with gcc 4.8.2 (build from yocto 1.6.0).

Is asking people to use gcc 4.7.3 or later acceptable ?

OK, this appears to be an assembler bug.

$ cat test.s
	.text
x:
	.pushsection	b, "a"
	beq y
	.popsection
	.=0x80000
y:
$ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version
GNU assembler (GNU Binutils) 2.22
This assembler was configured for a target of `powerpc64-linux'.
$ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o test.o test.s
test.s: Assembler messages:
test.s:4: Error: operand out of range (0x0000000000080000 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
$ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version
GNU assembler (GNU Binutils) 2.23.52.20130512
This assembler was configured for a target of `powerpc64-linux'.
$ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o test.o test.s
(no error)
Quoted 2 lines

Alan, can you shed light on when it was fixed?

Hi Stephen,

any idea what might cause this one, by any chance ?

arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
(.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function exc_debug_crit_book3e':
(.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function exc_debug_debug_book3e':

I see this if I try to build powerpc:ppc64e_defconfig or powerpc:chroma_defconfig with gcc 4.8.2 and binutils 2.24.

Thanks,
Guenter

#7 lore raw
Quoted 10 lines · Guenter Roeck

any idea what might cause this one, by any chance ?

arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
(.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function exc_debug_crit_book3e':
(.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function exc_debug_debug_book3e':

I see this if I try to build powerpc:ppc64e_defconfig or powerpc:chroma_defconfig with gcc 4.8.2 and binutils 2.24.

Blame me. I changed the ABI, something that had to be done but unfortunately happens to break the booke kernel code. When building up a 64-bit value with lis, ori, shl, oris, ori or similar sequences, you now should use @high and @higha in place of @h and @ha. @h and @ha (and their associated relocs R_PPC64_ADDR16_HI and R_PPC64_ADDR16_HA) now report overflow if the value is out of 32-bit signed range. ie. @h and @ha assume you're building a 32-bit value. This is needed to report out-of-range -mcmodel=medium toc pointer offsets in @toc@h and @toc@ha expressions, and for consistency I did the same for all other @h and @ha relocs.

Signature · 2 lines
Alan Modra
Australia Development Lab, IBM
#8 lore raw
Quoted 12 lines · Alan Modra
Quoted 10 lines · Guenter Roeck

any idea what might cause this one, by any chance ?

arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
(.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function exc_debug_crit_book3e':
(.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function exc_debug_debug_book3e':

I see this if I try to build powerpc:ppc64e_defconfig or powerpc:chroma_defconfig with gcc 4.8.2 and binutils 2.24.

Quoted 11 lines

Blame me. I changed the ABI, something that had to be done but unfortunately happens to break the booke kernel code. When building up a 64-bit value with lis, ori, shl, oris, ori or similar sequences, you now should use @high and @higha in place of @h and @ha. @h and @ha (and their associated relocs R_PPC64_ADDR16_HI and R_PPC64_ADDR16_HA) now report overflow if the value is out of 32-bit signed range. ie. @h and @ha assume you're building a 32-bit value. This is needed to report out-of-range -mcmodel=medium toc pointer offsets in @toc@h and @toc@ha expressions, and for consistency I did the same for all other @h and @ha relocs.

Bummer. Confirmed, if I replace "@h" with "@high" in just one place, the builds pass with binutils 2.24. Unfortunately the same builds then fails with binutils 2.23.

Any idea how to get it to compile with both old and new versions ? Is there some predefined constant which I could possibly use for something like

.if as_version_below_2.24_

	oris    reg,reg,(expr)@h;
.else
	oris    reg,reg,(expr)@high;

.endif

Thanks,
Guenter

#9 lore raw
Quoted 5 lines · Guenter Roeck

Bummer. Confirmed, if I replace "@h" with "@high" in just one place, the builds pass with binutils 2.24. Unfortunately the same builds then fails with binutils 2.23.

Any idea how to get it to compile with both old and new versions ?

The standard way with GNU software would be to write a configure test, that checks for @high support in the assembler, and defines a macro if the assembler passes the check. I'm not that familiar with the linux kernel these days, but a little grepping around says that something like

ashigh := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1) KBUILD_AFLAGS += $(ashigh)

might work.

Quoted 11 lines

Is there some predefined constant which I could possibly use for something like

.if as_version_below_2.24_

	oris    reg,reg,(expr)@h;
.else
	oris    reg,reg,(expr)@high;

.endif

Thanks,
Guenter

Signature · 2 lines
Alan Modra
Australia Development Lab, IBM
#10 lore raw
Quoted 13 lines · Alan Modra
Quoted 5 lines · Guenter Roeck

Bummer. Confirmed, if I replace "@h" with "@high" in just one place, the builds pass with binutils 2.24. Unfortunately the same builds then fails with binutils 2.23.

Any idea how to get it to compile with both old and new versions ?

The standard way with GNU software would be to write a configure test, that checks for @high support in the assembler, and defines a macro if the assembler passes the check. I'm not that familiar with the linux kernel these days, but a little grepping around says that something like

Quoted 5 lines

ashigh := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1) KBUILD_AFLAGS += $(ashigh)

might work.

Yes, it does.

Thanks!

Guenter

author
#11 lore raw
Quoted 14 lines · Guenter Roeck
Quoted 13 lines · Alan Modra
Quoted 5 lines · Guenter Roeck

Bummer. Confirmed, if I replace "@h" with "@high" in just one place, the builds pass with binutils 2.24. Unfortunately the same builds then fails with binutils 2.23.

Any idea how to get it to compile with both old and new versions ?

The standard way with GNU software would be to write a configure test, that checks for @high support in the assembler, and defines a macro if the assembler passes the check. I'm not that familiar with the linux kernel these days, but a little grepping around says that something like

Quoted 7 lines
Quoted 5 lines

ashigh := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1) KBUILD_AFLAGS += $(ashigh)

might work.

Yes, it does.

Care to send a patch ? :-)

Cheers,
Ben.

#12 lore raw
Quoted 18 lines · Benjamin Herrenschmidt
Quoted 17 lines · Guenter Roeck
Quoted 16 lines · Alan Modra
Quoted 5 lines · Guenter Roeck

Bummer. Confirmed, if I replace "@h" with "@high" in just one place, the builds pass with binutils 2.24. Unfortunately the same builds then fails with binutils 2.23.

Any idea how to get it to compile with both old and new versions ?

The standard way with GNU software would be to write a configure test, that checks for @high support in the assembler, and defines a macro if the assembler passes the check. I'm not that familiar with the linux kernel these days, but a little grepping around says that something like

ashigh := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1) KBUILD_AFLAGS += $(ashigh)

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

might work.

Yes, it does.

Care to send a patch ? :-)

Yes, working on it.

Thanks,
Guenter

#13 lore raw
In reply to Stephen Rothwell
Quoted 1 line · Stephen Rothwell

OK, this appears to be an assembler bug.

Agreed. Upgrade binutils!

Quoted 20 lines
$ cat test.s
	.text
x:
	.pushsection	b, "a"
	beq y
	.popsection
	.=0x80000
y:
$ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version
GNU assembler (GNU Binutils) 2.22
This assembler was configured for a target of `powerpc64-linux'.
$ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o test.o test.s 
test.s: Assembler messages:
test.s:4: Error: operand out of range (0x0000000000080000 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
$ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version
GNU assembler (GNU Binutils) 2.23.52.20130512
This assembler was configured for a target of `powerpc64-linux'.
$ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o test.o test.s 
(no error)
Quoted 1 line

Alan, can you shed light on when it was fixed?

2012-11-05
https://sourceware.org/ml/binutils/2012-11/msg00043.html
git show 3b8b57a9495016b2b02fbc2612dd1607d4b6f9ba

The part that actually fixes this problem is "Leave insn field zero...".

Signature · 2 lines
Alan Modra
Australia Development Lab, IBM
#14 lore raw
In reply to Benjamin Herrenschmidt
Quoted 12 lines · Benjamin Herrenschmidt
Quoted 10 lines · Guenter Roeck

After applying this patch, I get

arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range (0x000000000000814c is not between 0xffffffffffff8000 and 0x0000000000007ffc) arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range (0x000000000000814c is not between 0xffffffffffff8000 and 0x0000000000007ffc)

with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and powerpc:maple_defconfig.

Quoted 9 lines
Quoted 3 lines

This is on top of v3.15-rc5. Any idea what is going on ?

Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1).

Interesting... works with all my test configs using 4.7.3...

I don't have my tree at hand right now, I'll check what that means tomorrow see if I can find a workaround.

Drives me crazy. With gcc 4.8.2, powerpc:allmodconfig builds, but now I get failures with ppc64e_defconfig and chroma_defconfig:

arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
(.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o
arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
(.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o
arch/powerpc/kernel/built-in.o: In function `exc_debug_debug_book3e':
(.text+0x1679e): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o
arch/powerpc/kernel/built-in.o: In function `exc_debug_debug_book3e':
(.text+0x167b2): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o
arch/powerpc/kernel/built-in.o: In function `skpinv':
arch/powerpc/kernel/exceptions-64e.o:(.text+0x178c6): relocation truncated to
fit: R_PPC64_ADDR16_HI against .text'+178e0 arch/powerpc/kernel/built-in.o: In function a2_tlbinit_after_linear_map':
(.text+0x17966): relocation truncated to fit: R_PPC64_ADDR16_HI against `.text'+17974
arch/powerpc/kernel/built-in.o: In function `.init_core_book3e':
arch/powerpc/kernel/exceptions-64e.o:(.text+0x17a7e): relocation truncated to
fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o

Worse, that happens even without your patch applied, and the patch does not make a difference :-(.

Guenter

#15 lore raw
In reply to Benjamin Herrenschmidt
Quoted 21 lines · Benjamin Herrenschmidt

This shuffles code around in exceptions-64s.S in order to allow an allmodconfig build to succeed.

The main problems were:

- We have a fixed hole from 0x7000 to 0x8000 for use by FW,
under some circumstances the code before that would grow too big and hit the . = 0x7000

- The various attempts at making space in there would trigger
cases where short conditional branches from assembly would no longer be able to reach their target. This is especially nasty when these branches reside in alternate feature sections which are appended at the end of each .o file

This fixes it by essentially moving all the "second level" exception handlers to after the hole and moving a couple of functions near the hole itself so they sit at reachable distance of both the first level handlers (before the hole) and the alternate feature sections (end of file).

Quoted 9 lines

In the long run, if we start hitting this again, we'll probably have to split the file in two, probably at the hole location, to keep the alt sections used by the first level handlers close to them, and move everything else further away.

But for now, this will do.

Signed-off-by Benjamin Herrenschmidt <[email protected]>

Hi Ben,

what happened with this patch ?

Thanks,
Guenter

author
#16 lore raw
Quoted 1 line · Guenter Roeck

what happened with this patch ?

Well it breaks with that binutils version of yours ... I'm trying to fix it in a better way but it's a mess... still working on it.

Cheers,
Ben.

#17 lore raw
Quoted 6 lines · Benjamin Herrenschmidt
Quoted 1 line · Guenter Roeck

what happened with this patch ?

Well it breaks with that binutils version of yours ... I'm trying to fix it in a better way but it's a mess... still working on it.

I updated my binutils since then, though, and the other problem I encountered (with the changed ABI) has been fixed. As it is, I'd prefer to have the patch applied, but I can understand if you don't want to apply it in case others hit the problem I had.

Guenter