Skip to contentSkip to conversation

m68k: Fix invalid .section syntax

PATCH In review Ben Hutchings 3 participants 5 messages Jun 16, 2023 – Jul 25, 2023 m68k architecture

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 m68k: Fix invalid .section syntax

From: Ben Hutchings <[email protected]>

gas supports several different forms for .section for ELF targets, including:
.section NAME [, "FLAGS"[, @TYPE[,FLAG_SPECIFIC_ARGUMENTS]]]
and:

    .section "NAME"[, #FLAGS...]

In several places we use a mix of these two forms:
.section NAME, #FLAGS...

A current development snapshot of binutils (2.40.50.20230611) treats this mixed syntax as an error.

Change to consistently use:
.section NAME, "FLAGS"
as is used elsewhere in the kernel.

References: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=m68k&ver=6.4%7Erc6-1%7Eexp1&stamp=1686907300&raw=1

---
These changes are compile-tested only.

Ben.

 arch/m68k/fpsp040/skeleton.S       | 4 ++--
 arch/m68k/ifpsp060/os.S            | 4 ++--
 arch/m68k/kernel/relocate_kernel.S | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)
arch/m68k/fpsp040/skeleton.S +2 -2
index 439395aa6fb4..081922c72daa 100644
@@ -499,13 +499,13 @@
 	dbf	%d0,morein
 	rts
 
-	.section .fixup,#alloc,#execinstr
+	.section .fixup,"ax"
 	.even
 1:
 	jbsr	fpsp040_die
 	jbra	.Lnotkern
 
-	.section __ex_table,#alloc
+	.section __ex_table,"a"
 	.align	4
 
 	.long	in_ea,1b
arch/m68k/ifpsp060/os.S +2 -2
index 7a0d6e428066..89e2ec224ab6 100644
@@ -379,11 +379,11 @@ dmwls:	move.l		%d0,(%a0)		| store super longword
 
 
 | Execption handling for movs access to illegal memory
-	.section .fixup,#alloc,#execinstr
+	.section .fixup,"ax"
 	.even
 1:	moveq		#-1,%d1
 	rts
-.section __ex_table,#alloc
+.section __ex_table,"a"
 	.align 4
 	.long	dmrbuae,1b
 	.long	dmrwuae,1b
arch/m68k/kernel/relocate_kernel.S +2 -2
index ab0f1e7d4653..f7667079e08e 100644
@@ -26,7 +26,7 @@ ENTRY(relocate_new_kernel)
 	lea %pc@(.Lcopy),%a4
 2:	addl #0x00000000,%a4		/* virt_to_phys() */
 
-	.section ".m68k_fixup","aw"
+	.section .m68k_fixup,"aw"
 	.long M68K_FIXUP_MEMOFFSET, 2b+2
 	.previous
 
@@ -49,7 +49,7 @@ ENTRY(relocate_new_kernel)
 	lea %pc@(.Lcont040),%a4
 5:	addl #0x00000000,%a4		/* virt_to_phys() */
 
-	.section ".m68k_fixup","aw"
+	.section .m68k_fixup,"aw"
 	.long M68K_FIXUP_MEMOFFSET, 5b+2
 	.previous
 
Tested-by on v1 1/1
#1 lore raw

Hi!

Quoted 11 lines · Ben Hutchings

gas supports several different forms for .section for ELF targets, including:
.section NAME [, "FLAGS"[, @TYPE[,FLAG_SPECIFIC_ARGUMENTS]]]
and:

    .section "NAME"[, #FLAGS...]

In several places we use a mix of these two forms:
.section NAME, #FLAGS...

A current development snapshot of binutils (2.40.50.20230611) treats this mixed syntax as an error.

I stepped into this as well, and think it's a bad thing to break working code along with giving a bad error message:

[mk all 2023-06-23 08:34:34] # AS arch/m68k/fpsp040/skeleton.o
[mk all 2023-06-23 08:34:34] m68k-linux-gcc -Wp,-MMD,arch/m68k/fpsp040/.skeleton.o.d -nostdinc -I./arch/m68k/include -I./arch/m68k/include/generated -I./include -I./arch/m68k/include/uapi -I./arch/m68k/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -D__KERNEL__ -fmacro-prefix-map=./= -D__ASSEMBLY__ -fno-PIE -m68040 -c -o arch/m68k/fpsp040/skeleton.o arch/m68k/fpsp040/skeleton.S
[mk all 2023-06-23 08:34:34] arch/m68k/fpsp040/skeleton.S: Assembler messages:
[mk all 2023-06-23 08:34:34] arch/m68k/fpsp040/skeleton.S:502: Error: junk at end of line, first unrecognized character is #' [mk all 2023-06-23 08:34:34] arch/m68k/fpsp040/skeleton.S:508: Error: junk at end of line, first unrecognized character is #' [mk all 2023-06-23 08:34:34] make[3]: *** [scripts/Makefile.build:374: arch/m68k/fpsp040/skeleton.o] Error 1 [mk all 2023-06-23 08:34:34] make[2]: *** [scripts/Makefile.build:494: arch/m68k/fpsp040] Error 2
[mk all 2023-06-23 08:34:34] make[1]: *** [scripts/Makefile.build:494: arch/m68k] Error 2
[mk all 2023-06-23 08:34:34] make: *** [Makefile:2026: .] Error 2

Quoted 2 lines

References: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=m68k&ver=6.4%7Erc6-1%7Eexp1&stamp=1686907300&raw=1

As per pers.comm. with Geert:

References: http://toolchain.lug-owl.de/laminar/jobs/linux-m68k-virt_defconfig/34

MfG, JBG

maintainer Reviewed-by on v1 1/1
#2 lore raw
In reply to Ben Hutchings

Hi Ben,

Quoted 14 lines · Ben Hutchings

From: Ben Hutchings <[email protected]>

gas supports several different forms for .section for ELF targets, including:
.section NAME [, "FLAGS"[, @TYPE[,FLAG_SPECIFIC_ARGUMENTS]]]
and:

    .section "NAME"[, #FLAGS...]

In several places we use a mix of these two forms:
.section NAME, #FLAGS...

A current development snapshot of binutils (2.40.50.20230611) treats this mixed syntax as an error.

Quoted 6 lines

Change to consistently use:
.section NAME, "FLAGS"
as is used elsewhere in the kernel.

References: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=m68k&ver=6.4%7Erc6-1%7Eexp1&stamp=1686907300&raw=1

Thanks for your patch! Consistency is good.

i.e. applied and queued.

Quoted 2 lines

---
These changes are compile-tested only.

I verified there is no difference in the generated object files with my current toolchain (GNU assembler version 2.38 (m68k-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.38).

Do you think it's worthwhile to fast-track this for v6.5, or is it fine to queue this for v6.6?

Thanks!

Gr{oetje,eeting}s,

Geert

Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
#3 lore raw
Quoted 16 lines · Geert Uytterhoeven

Hi Ben,

Quoted 13 lines · Ben Hutchings

From: Ben Hutchings <[email protected]>

gas supports several different forms for .section for ELF targets, including:
.section NAME [, "FLAGS"[, @TYPE[,FLAG_SPECIFIC_ARGUMENTS]]]
and:

    .section "NAME"[, #FLAGS...]

In several places we use a mix of these two forms:
.section NAME, #FLAGS...

A current development snapshot of binutils (2.40.50.20230611) treats this mixed syntax as an error.

[...]

Quoted 6 lines

I verified there is no difference in the generated object files with my current toolchain (GNU assembler version 2.38 (m68k-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.38).

Do you think it's worthwhile to fast-track this for v6.5, or is it fine to queue this for v6.6?

The new version of binutils has been in Debian unstable for over a month now. I think this should be fast-tracked.

Ben.

Signature · 2 lines
Ben Hutchings
When in doubt, use brute force. - Ken Thompson
#4 lore raw

Hi Ben,

Quoted 20 lines · Ben Hutchings
Quoted 14 lines · Geert Uytterhoeven
Quoted 13 lines · Ben Hutchings

From: Ben Hutchings <[email protected]>

gas supports several different forms for .section for ELF targets, including:
.section NAME [, "FLAGS"[, @TYPE[,FLAG_SPECIFIC_ARGUMENTS]]]
and:

    .section "NAME"[, #FLAGS...]

In several places we use a mix of these two forms:
.section NAME, #FLAGS...

A current development snapshot of binutils (2.40.50.20230611) treats this mixed syntax as an error.

[...]

Quoted 4 lines

I verified there is no difference in the generated object files with my current toolchain (GNU assembler version 2.38 (m68k-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.38).

Quoted 5 lines
Quoted 2 lines

Do you think it's worthwhile to fast-track this for v6.5, or is it fine to queue this for v6.6?

The new version of binutils has been in Debian unstable for over a month now. I think this should be fast-tracked.

OK, PR sent.
Thanks!

Gr{oetje,eeting}s,

Geert

Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds