PowerPC64 future proof kernel toc, revised

PowerPC64 future proof kernel toc, revised

[Alan Modra]

This patch future-proofs the kernel against linker changes that might
put the toc pointer at some location other than .got+0x8000, by
replacing __toc_start+0x8000 with __toc_ptr throughout.  __toc_ptr
is set from the symbol .TOC. emitted by ld on a final link, falling
back to .got+0x8000 for older ld that doesn't provide .TOC.  If the
kernel's idea of the toc pointer doesn't agree with the linker, bad
things happen.

prom_init.c code relocating its toc is also changed so that a symbolic
__prom_init_toc_start toc-pointer relative address is calculated
rather than assuming that it is always at toc-pointer - 0x8000.  The
length calculations loading values from the toc are also avoided.
It's a little incestuous to do that with unreloc_toc picking up
adjusted values (which is fine in practice, they both adjust by the
same amount if all goes well).

I've also changed the way .got is aligned in vmlinux.lds and
zImage.lds, mostly so that dumping out section info by objdump or
readelf plainly shows the alignment is 256.  This linker script
feature was added 2005-09-27, available in FSF binutils releases from
2.17 onwards.  Should be safe to use in the kernel, I think.

Finally, put *(.got) before the prom_init.o entry which only needs
*(.toc), so that the GOT header goes in the correct place.  I don't
believe this makes any difference for the kernel as it would for
dynamic objects being loaded by ld.so.  That change is just to stop
lusers who blindly copy kernel scripts being led astray.  Of course,
this change needs the prom_init.c changes.

Some notes on .toc and .got.

.toc is a compiler generated section of addresses.  .got is a linker
generated section of addresses, generally built when the linker sees
R_*_*GOT* relocations.  In the case of powerpc64 ld.bfd, there are
multiple generated .got sections, one per input object file.  So you
can somewhat reasonably write in a linker script an input section
statement like *prom_init.o(.got .toc) to mean "the .got and .toc
section for files matching *prom_init.o".  On other architectures that
doesn't make sense, because the linker generally has just one .got
section.  Even on powerpc64, note well that the GOT entries for
prom_init.o may be merged with GOT entries from other objects.  That
means that if prom_init.o references, say, _end via some GOT
relocation, and some other object also references _end via a GOT
relocation, the GOT entry for _end may be in the range
__prom_init_toc_start to __prom_init_toc_end and if the kernel does
something special to GOT/TOC entries in that range then the value of
_end as seen by objects other than prom_init.o will be affected.  On
the other hand the GOT entry for _end may not be in the range
__prom_init_toc_start to __prom_init_toc_end.  Which way it turns out
is deterministic but a detail of linker operation that should not be
relied on.

A feature of ld.bfd is that input .toc (and .got) sections matching
one linker input section statement may be sorted, to put entries used
by small-model code first, near the toc base.  This is why scripts for
powerpc64 normally use *(.got .toc) rather than *(.got) *(.toc), since
the first form allows more freedom to sort.

Another feature of ld.bfd is that indirect addressing sequences using
the GOT/TOC may be edited by the linker to relative addressing.  In
many cases relative addressing would be emitted by gcc for
-mcmodel=medium if you appropriately decorate variable declarations
with non-default visibility.


diff --git a/arch/powerpc/boot/crt0.S b/arch/powerpc/boot/crt0.S
index 1d83966f5ef6..8397af058650 100644
--- a/arch/powerpc/boot/crt0.S
+++ b/arch/powerpc/boot/crt0.S
@@ -28,7 +28,7 @@ p_etext:	.8byte	_etext
 p_bss_start:	.8byte	__bss_start
 p_end:		.8byte	_end
 
-p_toc:		.8byte	__toc_start + 0x8000 - p_base
+p_toc:		.8byte	__toc_ptr - p_base
 p_dyn:		.8byte	__dynamic_start - p_base
 p_rela:		.8byte	__rela_dyn_start - p_base
 p_prom:		.8byte	0
diff --git a/arch/powerpc/boot/zImage.lds.S b/arch/powerpc/boot/zImage.lds.S
index d6f072865627..35654cbcd294 100644
--- a/arch/powerpc/boot/zImage.lds.S
+++ b/arch/powerpc/boot/zImage.lds.S
@@ -36,13 +36,11 @@ SECTIONS
   }
 
 #ifdef CONFIG_PPC64_BOOT_WRAPPER
-  . = ALIGN(256);
-  .got :
+  .got : ALIGN(256)
   {
-    __toc_start = .;
-    *(.got)
-    *(.toc)
+    *(.got .toc)
   }
+  __toc_ptr = DEFINED (.TOC.) ? .TOC. : ADDR (.got) + 0x8000;
 #endif
 
   .hash : { *(.hash) }
diff --git a/arch/powerpc/include/asm/sections.h b/arch/powerpc/include/asm/sections.h
index 324d7b298ec3..4c3e84a2a073 100644
--- a/arch/powerpc/include/asm/sections.h
+++ b/arch/powerpc/include/asm/sections.h
@@ -49,13 +49,13 @@ static inline int in_kernel_text(unsigned long addr)
 static inline unsigned long kernel_toc_addr(void)
 {
 	/* Defined by the linker, see vmlinux.lds.S */
-	extern unsigned long __toc_start;
+	extern unsigned long __toc_ptr;
 
 	/*
 	 * The TOC register (r2) points 32kB into the TOC, so that 64kB of
 	 * the TOC can be addressed using a single machine instruction.
 	 */
-	return (unsigned long)(&__toc_start) + 0x8000UL;
+	return (unsigned long)&__toc_ptr;
 }
 
 static inline int overlaps_interrupt_vector_text(unsigned long start,
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index ece7f97bafff..1cae5b0943be 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -899,7 +899,7 @@ _GLOBAL(relative_toc)
 	blr
 
 .balign 8
-p_toc:	.8byte	__toc_start + 0x8000 - 0b
+p_toc:	.8byte	__toc_ptr - 0b
 
 /*
  * This is where the main kernel code starts.
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index ccf77b985c8f..d309a7787652 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -3220,27 +3220,26 @@ static void unreloc_toc(void)
 {
 }
 #else
-static void __reloc_toc(unsigned long offset, unsigned long nr_entries)
+static void __reloc_toc(unsigned long offset)
 {
-	unsigned long i;
 	unsigned long *toc_entry;
+	unsigned long *toc_start, *toc_end;
 
-	/* Get the start of the TOC by using r2 directly. */
-	asm volatile("addi %0,2,-0x8000" : "=b" (toc_entry));
+	asm("addis %0,2,__prom_init_toc_start@toc@ha\n\t"
+	    "addi %0,%0,__prom_init_toc_start@toc@l" : "=b" (toc_start));
+	asm("addis %0,2,__prom_init_toc_end@toc@ha\n\t"
+	    "addi %0,%0,__prom_init_toc_end@toc@l" : "=b" (toc_end));
 
-	for (i = 0; i < nr_entries; i++) {
-		*toc_entry = *toc_entry + offset;
-		toc_entry++;
+	for (toc_entry = toc_start; toc_entry != toc_end; toc_entry++) {
+		*toc_entry += offset;
 	}
 }
 
 static void reloc_toc(void)
 {
 	unsigned long offset = reloc_offset();
-	unsigned long nr_entries =
-		(__prom_init_toc_end - __prom_init_toc_start) / sizeof(long);
 
-	__reloc_toc(offset, nr_entries);
+	__reloc_toc(offset);
 
 	mb();
 }
@@ -3248,12 +3247,10 @@ static void reloc_toc(void)
 static void unreloc_toc(void)
 {
 	unsigned long offset = reloc_offset();
-	unsigned long nr_entries =
-		(__prom_init_toc_end - __prom_init_toc_start) / sizeof(long);
 
 	mb();
 
-	__reloc_toc(-offset, nr_entries);
+	__reloc_toc(-offset);
 }
 #endif
 #endif
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 72fa3c00229a..343579080dd5 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -326,17 +326,16 @@ SECTIONS
 		__end_opd = .;
 	}
 
-	. = ALIGN(256);
-	.got : AT(ADDR(.got) - LOAD_OFFSET) {
-		__toc_start = .;
+	.got : AT(ADDR(.got) - LOAD_OFFSET) ALIGN(256) {
+		*(.got)
 #ifndef CONFIG_RELOCATABLE
 		__prom_init_toc_start = .;
-		arch/powerpc/kernel/prom_init.o*(.toc .got)
+		arch/powerpc/kernel/prom_init.o*(.toc)
 		__prom_init_toc_end = .;
 #endif
-		*(.got)
 		*(.toc)
 	}
+	__toc_ptr = DEFINED (.TOC.) ? .TOC. : ADDR (.got) + 0x8000;
 #endif
 
 	/* The initial task and kernel stack */

-- 
Alan Modra
Australia Development Lab, IBM

Re: PowerPC64 future proof kernel toc, revised for lld

[Alan Modra]

This patch future-proofs the kernel against linker changes that might
put the toc pointer at some location other than .got+0x8000, by
replacing __toc_start+0x8000 with .TOC. throughout.  If the kernel's
idea of the toc pointer doesn't agree with the linker, bad things
happen.

prom_init.c code relocating its toc is also changed so that a symbolic
__prom_init_toc_start toc-pointer relative address is calculated
rather than assuming that it is always at toc-pointer - 0x8000.  The
length calculations loading values from the toc are also avoided.
It's a little incestuous to do that with unreloc_toc picking up
adjusted values (which is fine in practice, they both adjust by the
same amount if all goes well).

I've also changed the way .got is aligned in vmlinux.lds and
zImage.lds, mostly so that dumping out section info by objdump or
readelf plainly shows the alignment is 256.  This linker script
feature was added 2005-09-27, available in FSF binutils releases from
2.17 onwards.  Should be safe to use in the kernel, I think.

Finally, put *(.got) before the prom_init.o entry which only needs
*(.toc), so that the GOT header goes in the correct place.  I don't
believe this makes any difference for the kernel as it would for
dynamic objects being loaded by ld.so.  That change is just to stop
lusers who blindly copy kernel scripts being led astray.  Of course,
this change needs the prom_init.c changes.

Some notes on .toc and .got.

.toc is a compiler generated section of addresses.  .got is a linker
generated section of addresses, generally built when the linker sees
R_*_*GOT* relocations.  In the case of powerpc64 ld.bfd, there are
multiple generated .got sections, one per input object file.  So you
can somewhat reasonably write in a linker script an input section
statement like *prom_init.o(.got .toc) to mean "the .got and .toc
section for files matching *prom_init.o".  On other architectures that
doesn't make sense, because the linker generally has just one .got
section.  Even on powerpc64, note well that the GOT entries for
prom_init.o may be merged with GOT entries from other objects.  That
means that if prom_init.o references, say, _end via some GOT
relocation, and some other object also references _end via a GOT
relocation, the GOT entry for _end may be in the range
__prom_init_toc_start to __prom_init_toc_end and if the kernel does
something special to GOT/TOC entries in that range then the value of
_end as seen by objects other than prom_init.o will be affected.  On
the other hand the GOT entry for _end may not be in the range
__prom_init_toc_start to __prom_init_toc_end.  Which way it turns out
is deterministic but a detail of linker operation that should not be
relied on.

A feature of ld.bfd is that input .toc (and .got) sections matching
one linker input section statement may be sorted, to put entries used
by small-model code first, near the toc base.  This is why scripts for
powerpc64 normally use *(.got .toc) rather than *(.got) *(.toc), since
the first form allows more freedom to sort.

Another feature of ld.bfd is that indirect addressing sequences using
the GOT/TOC may be edited by the linker to relative addressing.  In
many cases relative addressing would be emitted by gcc for
-mcmodel=medium if you appropriately decorate variable declarations
with non-default visibility.

Signed-off-by: Alan Modra <amodra@au1.ibm.com>

diff --git a/arch/powerpc/boot/crt0.S b/arch/powerpc/boot/crt0.S
index 1d83966f5ef6..e45907fe468f 100644
--- a/arch/powerpc/boot/crt0.S
+++ b/arch/powerpc/boot/crt0.S
@@ -28,7 +28,7 @@ p_etext:	.8byte	_etext
 p_bss_start:	.8byte	__bss_start
 p_end:		.8byte	_end
 
-p_toc:		.8byte	__toc_start + 0x8000 - p_base
+p_toc:		.8byte	.TOC. - p_base
 p_dyn:		.8byte	__dynamic_start - p_base
 p_rela:		.8byte	__rela_dyn_start - p_base
 p_prom:		.8byte	0
diff --git a/arch/powerpc/boot/zImage.lds.S b/arch/powerpc/boot/zImage.lds.S
index d6f072865627..d65cd55a6f38 100644
--- a/arch/powerpc/boot/zImage.lds.S
+++ b/arch/powerpc/boot/zImage.lds.S
@@ -36,12 +36,9 @@ SECTIONS
   }
 
 #ifdef CONFIG_PPC64_BOOT_WRAPPER
-  . = ALIGN(256);
-  .got :
+  .got : ALIGN(256)
   {
-    __toc_start = .;
-    *(.got)
-    *(.toc)
+    *(.got .toc)
   }
 #endif
 
diff --git a/arch/powerpc/include/asm/sections.h b/arch/powerpc/include/asm/sections.h
index 324d7b298ec3..e5a1eae11ed5 100644
--- a/arch/powerpc/include/asm/sections.h
+++ b/arch/powerpc/include/asm/sections.h
@@ -48,14 +48,18 @@ static inline int in_kernel_text(unsigned long addr)
 
 static inline unsigned long kernel_toc_addr(void)
 {
-	/* Defined by the linker, see vmlinux.lds.S */
-	extern unsigned long __toc_start;
-
-	/*
-	 * The TOC register (r2) points 32kB into the TOC, so that 64kB of
-	 * the TOC can be addressed using a single machine instruction.
-	 */
-	return (unsigned long)(&__toc_start) + 0x8000UL;
+#if 0
+	/* This version is appropriate if the kernel is never compiled
+	   -mcmodel=small or the total .toc is always less than 64k.  */
+	register unsigned long toc_ptr asm ("r2");
+	return toc_ptr;
+#else
+	/* Otherwise linker automatic multiple toc sections might be
+	   required, and in that case r2 may be adjusted by a linker
+	   stub.  */
+	extern unsigned long __attribute__((visibility("hidden"))) toc asm (".TOC.");
+	return (unsigned long)&toc;
+#endif
 }
 
 static inline int overlaps_interrupt_vector_text(unsigned long start,
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index ece7f97bafff..9542d03b2efe 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -899,7 +899,7 @@ _GLOBAL(relative_toc)
 	blr
 
 .balign 8
-p_toc:	.8byte	__toc_start + 0x8000 - 0b
+p_toc:	.8byte	.TOC. - 0b
 
 /*
  * This is where the main kernel code starts.
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index ccf77b985c8f..d309a7787652 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -3220,27 +3220,26 @@ static void unreloc_toc(void)
 {
 }
 #else
-static void __reloc_toc(unsigned long offset, unsigned long nr_entries)
+static void __reloc_toc(unsigned long offset)
 {
-	unsigned long i;
 	unsigned long *toc_entry;
+	unsigned long *toc_start, *toc_end;
 
-	/* Get the start of the TOC by using r2 directly. */
-	asm volatile("addi %0,2,-0x8000" : "=b" (toc_entry));
+	asm("addis %0,2,__prom_init_toc_start@toc@ha\n\t"
+	    "addi %0,%0,__prom_init_toc_start@toc@l" : "=b" (toc_start));
+	asm("addis %0,2,__prom_init_toc_end@toc@ha\n\t"
+	    "addi %0,%0,__prom_init_toc_end@toc@l" : "=b" (toc_end));
 
-	for (i = 0; i < nr_entries; i++) {
-		*toc_entry = *toc_entry + offset;
-		toc_entry++;
+	for (toc_entry = toc_start; toc_entry != toc_end; toc_entry++) {
+		*toc_entry += offset;
 	}
 }
 
 static void reloc_toc(void)
 {
 	unsigned long offset = reloc_offset();
-	unsigned long nr_entries =
-		(__prom_init_toc_end - __prom_init_toc_start) / sizeof(long);
 
-	__reloc_toc(offset, nr_entries);
+	__reloc_toc(offset);
 
 	mb();
 }
@@ -3248,12 +3247,10 @@ static void reloc_toc(void)
 static void unreloc_toc(void)
 {
 	unsigned long offset = reloc_offset();
-	unsigned long nr_entries =
-		(__prom_init_toc_end - __prom_init_toc_start) / sizeof(long);
 
 	mb();
 
-	__reloc_toc(-offset, nr_entries);
+	__reloc_toc(-offset);
 }
 #endif
 #endif
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 72fa3c00229a..3d2e6e2b81b5 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -326,15 +326,13 @@ SECTIONS
 		__end_opd = .;
 	}
 
-	. = ALIGN(256);
-	.got : AT(ADDR(.got) - LOAD_OFFSET) {
-		__toc_start = .;
+	.got : AT(ADDR(.got) - LOAD_OFFSET) ALIGN(256) {
+		*(.got)
 #ifndef CONFIG_RELOCATABLE
 		__prom_init_toc_start = .;
-		arch/powerpc/kernel/prom_init.o*(.toc .got)
+		arch/powerpc/kernel/prom_init.o*(.toc)
 		__prom_init_toc_end = .;
 #endif
-		*(.got)
 		*(.toc)
 	}
 #endif

-- 
Alan Modra
Australia Development Lab, IBM

Re: PowerPC64 future proof kernel toc, revised for lld

[Alexey Kardashevskiy]

On 10/03/2021 14:48, Alan Modra wrote:
> This patch future-proofs the kernel against linker changes that might
> put the toc pointer at some location other than .got+0x8000, by
> replacing __toc_start+0x8000 with .TOC. throughout.  If the kernel's
> idea of the toc pointer doesn't agree with the linker, bad things
> happen.


Works great with gcc (v8, v10), ld (2.23), clang-11, lld-11.


> 
> prom_init.c code relocating its toc is also changed so that a symbolic
> __prom_init_toc_start toc-pointer relative address is calculated
> rather than assuming that it is always at toc-pointer - 0x8000.  The
> length calculations loading values from the toc are also avoided.
> It's a little incestuous to do that with unreloc_toc picking up
> adjusted values (which is fine in practice, they both adjust by the
> same amount if all goes well).
> 
> I've also changed the way .got is aligned in vmlinux.lds and
> zImage.lds, mostly so that dumping out section info by objdump or
> readelf plainly shows the alignment is 256.  This linker script
> feature was added 2005-09-27, available in FSF binutils releases from
> 2.17 onwards.  Should be safe to use in the kernel, I think.
> 
> Finally, put *(.got) before the prom_init.o entry which only needs
> *(.toc), so that the GOT header goes in the correct place.  I don't
> believe this makes any difference for the kernel as it would for
> dynamic objects being loaded by ld.so.  That change is just to stop
> lusers who blindly copy kernel scripts being led astray.  Of course,
> this change needs the prom_init.c changes.
> 
> Some notes on .toc and .got.
> 
> .toc is a compiler generated section of addresses.  .got is a linker
> generated section of addresses, generally built when the linker sees
> R_*_*GOT* relocations.  In the case of powerpc64 ld.bfd, there are
> multiple generated .got sections, one per input object file.  So you
> can somewhat reasonably write in a linker script an input section
> statement like *prom_init.o(.got .toc) to mean "the .got and .toc
> section for files matching *prom_init.o".


For my own education, is .got for prom_init.o still generated by ld or gcc?

In other words, should "objdump -D -s -j .got" ever dump .got for any .o 
file, like below?

===
objdump -D -s -j .got 
~/pbuild/kernel-llvm-ld/arch/powerpc/kernel/prom_init.o 

 

/home/aik/pbuild/kernel-llvm-ld/arch/powerpc/kernel/prom_init.o: 
file format elf64-powerpcle 

 

objdump: section '.got' mentioned in a -j option, but not found in any 
input file
===



-- 
Alexey Kardashevskiy
IBM OzLabs, LTC Team

e-mail: aik@linux.ibm.com

Re: PowerPC64 future proof kernel toc, revised for lld

[Alan Modra]

On Wed, Mar 10, 2021 at 03:44:44PM +1100, Alexey Kardashevskiy wrote:
> For my own education, is .got for prom_init.o still generated by ld or gcc?

.got is generated by ld.

> In other words, should "objdump -D -s -j .got" ever dump .got for any .o
> file, like below?

No.  "objdump -r prom_init.o | grep GOT" will tell you whether
prom_init.o *may* cause ld to generate .got entries.  (Linker
optimisations or --gc-sections might remove the need for those .got
entries.)

> objdump: section '.got' mentioned in a -j option, but not found in any input
> file

Right, expected.

-- 
Alan Modra
Australia Development Lab, IBM

Re: PowerPC64 future proof kernel toc, revised for lld

[Alexey Kardashevskiy]

One more question - the older version had a construct "DEFINED (.TOC.) ? 
.TOC. : ..." in case .TOC. is not defined (too old ld? too old gcc?) but 
the newer patch seems assuming it is always defined, when was it added? 
I have the same check in SLOF, for example, do I still need it?




On 10/03/2021 16:07, Alan Modra wrote:
> On Wed, Mar 10, 2021 at 03:44:44PM +1100, Alexey Kardashevskiy wrote:
>> For my own education, is .got for prom_init.o still generated by ld or gcc?
> 
> .got is generated by ld.
> 
>> In other words, should "objdump -D -s -j .got" ever dump .got for any .o
>> file, like below?
> 
> No.  "objdump -r prom_init.o | grep GOT" will tell you whether
> prom_init.o *may* cause ld to generate .got entries.  (Linker
> optimisations or --gc-sections might remove the need for those .got
> entries.)
> 
>> objdump: section '.got' mentioned in a -j option, but not found in any input
>> file
> 
> Right, expected.
> 

-- 
Alexey Kardashevskiy
IBM OzLabs, LTC Team

e-mail: aik@linux.ibm.com

Re: PowerPC64 future proof kernel toc, revised for lld

[Alan Modra]

On Wed, Mar 10, 2021 at 08:33:37PM +1100, Alexey Kardashevskiy wrote:
> One more question - the older version had a construct "DEFINED (.TOC.) ?
> .TOC. : ..." in case .TOC. is not defined (too old ld? too old gcc?) but the
> newer patch seems assuming it is always defined, when was it added? I have
> the same check in SLOF, for example, do I still need it?

.TOC. symbol support was first added 2012-11-06, so you need
binutils-2.24 or later to use .TOC. as a symbol.

-- 
Alan Modra
Australia Development Lab, IBM

Re: PowerPC64 future proof kernel toc, revised for lld

[Christophe Leroy]

Le 10/03/2021 à 13:25, Alan Modra a écrit :
> On Wed, Mar 10, 2021 at 08:33:37PM +1100, Alexey Kardashevskiy wrote:
>> One more question - the older version had a construct "DEFINED (.TOC.) ?
>> .TOC. : ..." in case .TOC. is not defined (too old ld? too old gcc?) but the
>> newer patch seems assuming it is always defined, when was it added? I have
>> the same check in SLOF, for example, do I still need it?
> 
> .TOC. symbol support was first added 2012-11-06, so you need
> binutils-2.24 or later to use .TOC. as a symbol.
> 

As of today, minimum requirement to build kernel is binutils 2.23, see 
https://www.kernel.org/doc/html/latest/process/changes.html#current-minimal-requirements

Christophe

Re: PowerPC64 future proof kernel toc, revised for lld

[Segher Boessenkool]

On Wed, Mar 10, 2021 at 01:44:57PM +0100, Christophe Leroy wrote:
> 
> 
> Le 10/03/2021 à 13:25, Alan Modra a écrit :
> >On Wed, Mar 10, 2021 at 08:33:37PM +1100, Alexey Kardashevskiy wrote:
> >>One more question - the older version had a construct "DEFINED (.TOC.) ?
> >>.TOC. : ..." in case .TOC. is not defined (too old ld? too old gcc?) but 
> >>the
> >>newer patch seems assuming it is always defined, when was it added? I have
> >>the same check in SLOF, for example, do I still need it?
> >
> >.TOC. symbol support was first added 2012-11-06, so you need
> >binutils-2.24 or later to use .TOC. as a symbol.
> >
> 
> As of today, minimum requirement to build kernel is binutils 2.23, see 
> https://www.kernel.org/doc/html/latest/process/changes.html#current-minimal-requirements

The minimum GCC version required is 4.9, released April 2014, so it
would make sense to require binutils 2.24 at least as well: that was the
last binutils release before the GCC 4.9 release (it was end of 2013).

Generally you should make sure to always have a binutils at least as new
as your GCC (and newer almost always works just fine).


Segher

Re: PowerPC64 future proof kernel toc, revised for lld

[Alan Modra]

On Wed, Mar 10, 2021 at 01:44:57PM +0100, Christophe Leroy wrote:
> 
> 
> Le 10/03/2021 à 13:25, Alan Modra a écrit :
> > On Wed, Mar 10, 2021 at 08:33:37PM +1100, Alexey Kardashevskiy wrote:
> > > One more question - the older version had a construct "DEFINED (.TOC.) ?
> > > .TOC. : ..." in case .TOC. is not defined (too old ld? too old gcc?) but the
> > > newer patch seems assuming it is always defined, when was it added? I have
> > > the same check in SLOF, for example, do I still need it?
> > 
> > .TOC. symbol support was first added 2012-11-06, so you need
> > binutils-2.24 or later to use .TOC. as a symbol.
> > 
> 
> As of today, minimum requirement to build kernel is binutils 2.23, see https://www.kernel.org/doc/html/latest/process/changes.html#current-minimal-requirements

Yes, and arch/powerpc/Makefile complains about 2.24.  So for powerpc
that means you need to go to at least 2.25.  Oh the horror of needing
such new tools!

-- 
Alan Modra
Australia Development Lab, IBM

Re: PowerPC64 future proof kernel toc, revised for lld

[Michael Ellerman]

Alan Modra <amodra@gmail.com> writes:
> On Wed, Mar 10, 2021 at 01:44:57PM +0100, Christophe Leroy wrote:
>> 
>> Le 10/03/2021 à 13:25, Alan Modra a écrit :
>> > On Wed, Mar 10, 2021 at 08:33:37PM +1100, Alexey Kardashevskiy wrote:
>> > > One more question - the older version had a construct "DEFINED (.TOC.) ?
>> > > .TOC. : ..." in case .TOC. is not defined (too old ld? too old gcc?) but the
>> > > newer patch seems assuming it is always defined, when was it added? I have
>> > > the same check in SLOF, for example, do I still need it?
>> > 
>> > .TOC. symbol support was first added 2012-11-06, so you need
>> > binutils-2.24 or later to use .TOC. as a symbol.
>> > 
>> 
>> As of today, minimum requirement to build kernel is binutils 2.23, see https://urldefense.proofpoint.com/v2/url?u=https-3A__www.kernel.org_doc_html_latest_process_changes.html-23current-2Dminimal-2Drequirements&d=DwIDAw&c=jf_iaSHvJObTbx-siA1ZOg&r=uzpscot8Q8p-51o1Gp1vnzKV94bfny2qmUdVe821lv0&m=SYi605mn0I1hf1QoHuvHXtS_Z-R6JJHbzS34cEtV2Tk&s=47ckf3yxVcP6RwRb8D9viYOQSWpf6rXrnWj4YM4OTJ0&e= 
>
> Yes, and arch/powerpc/Makefile complains about 2.24.  So for powerpc
> that means you need to go to at least 2.25.  

Not quite. It only complains for little endian builds, and only if you
have stock 2.24, it will allow a 2.24.<something>.

I do most of my builds with 2.34, so I have no issue with newer
binutils. But we try not to increase the minimum version too rapidly to
accommodate folks using older and/or "Enterprise" distros that are stuck
on old toolchains.

I think we are within our rights to increase the minimum requirement for
powerpc builds, if it brings advantages we can identify.

The way to do that would be to add a new check in our arch Makefile that
rejects the older versions.

cheers

Re: PowerPC64 future proof kernel toc, revised for lld

[Alexey Kardashevskiy]

On 12/03/2021 10:32, Michael Ellerman wrote:
> Alan Modra <amodra@gmail.com> writes:
>> On Wed, Mar 10, 2021 at 01:44:57PM +0100, Christophe Leroy wrote:
>>>
>>> Le 10/03/2021 à 13:25, Alan Modra a écrit :
>>>> On Wed, Mar 10, 2021 at 08:33:37PM +1100, Alexey Kardashevskiy wrote:
>>>>> One more question - the older version had a construct "DEFINED (.TOC.) ?
>>>>> .TOC. : ..." in case .TOC. is not defined (too old ld? too old gcc?) but the
>>>>> newer patch seems assuming it is always defined, when was it added? I have
>>>>> the same check in SLOF, for example, do I still need it?
>>>>
>>>> .TOC. symbol support was first added 2012-11-06, so you need
>>>> binutils-2.24 or later to use .TOC. as a symbol.
>>>>
>>>
>>> As of today, minimum requirement to build kernel is binutils 2.23, see https://urldefense.proofpoint.com/v2/url?u=https-3A__www.kernel.org_doc_html_latest_process_changes.html-23current-2Dminimal-2Drequirements&d=DwIDAw&c=jf_iaSHvJObTbx-siA1ZOg&r=uzpscot8Q8p-51o1Gp1vnzKV94bfny2qmUdVe821lv0&m=SYi605mn0I1hf1QoHuvHXtS_Z-R6JJHbzS34cEtV2Tk&s=47ckf3yxVcP6RwRb8D9viYOQSWpf6rXrnWj4YM4OTJ0&e=
>>
>> Yes, and arch/powerpc/Makefile complains about 2.24.  So for powerpc
>> that means you need to go to at least 2.25.
> 
> Not quite. It only complains for little endian builds, and only if you
> have stock 2.24, it will allow a 2.24.<something>.
> 
> I do most of my builds with 2.34, so I have no issue with newer
> binutils. But we try not to increase the minimum version too rapidly to
> accommodate folks using older and/or "Enterprise" distros that are stuck
> on old toolchains.
> 
> I think we are within our rights to increase the minimum requirement for
> powerpc builds, if it brings advantages we can identify.
> 
> The way to do that would be to add a new check in our arch Makefile that
> rejects the older versions.

The upstream llvm just learnt to handle the .TOC. symbol in linker 
scripts so we may delay the future for a bit longer :) @dja wanted 
upstream llvm anyway and the currently supported llvm 10.xx is not much 
value for our experiments.

https://github.com/llvm/llvm-project/commit/e4f385d89448393b4d213339bbbbbbaa42b49489



-- 
Alexey