| Message ID | 1365585879-5321-1-git-send-email-geert@linux-m68k.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
(Added Andi to CC) On 10.4.2013 11:24, Geert Uytterhoeven wrote: [...] > E.g. gcc turned > > strncat(name, "%d", 2); > > into a call to strlen() and a 16-bit store, causing a link failure, as > arch/m68k/include/asm/string.h provides strlen() using a macro: > > ERROR: "strlen" [net/ipv4/ip_tunnel.ko] undefined! [...] > QUESTION: Should we re-enable -ffreestanding in the main Makefile instead? > > It was removed in > > commit 6edfba1b33c701108717f4e036320fc39abe1912 > Author: Andi Kleen <ak@suse.de> > Date: Sat Mar 25 16:29:49 2006 +0100 > > [PATCH] x86_64: Don't define string functions to builtin My understanding is, that with -fnobuiltin, the compiler is not allowed to make assumptions about functions if it does not see their definition, even if they resemble standard functions. E.g. on x86_64, strlen() is out-of-line, so gcc would have to assume, that strcmp() has side effects. How about just naming the m68k inline function 'strlen'? Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Apr 10, 2013 at 12:18 PM, Michal Marek <mmarek@suse.cz> wrote: > (Added Andi to CC) > > On 10.4.2013 11:24, Geert Uytterhoeven wrote: > [...] >> E.g. gcc turned >> >> strncat(name, "%d", 2); >> >> into a call to strlen() and a 16-bit store, causing a link failure, as >> arch/m68k/include/asm/string.h provides strlen() using a macro: >> >> ERROR: "strlen" [net/ipv4/ip_tunnel.ko] undefined! > [...] >> QUESTION: Should we re-enable -ffreestanding in the main Makefile instead? >> >> It was removed in >> >> commit 6edfba1b33c701108717f4e036320fc39abe1912 >> Author: Andi Kleen <ak@suse.de> >> Date: Sat Mar 25 16:29:49 2006 +0100 >> >> [PATCH] x86_64: Don't define string functions to builtin > > My understanding is, that with -fnobuiltin, the compiler is not allowed > to make assumptions about functions if it does not see their definition, > even if they resemble standard functions. E.g. on x86_64, strlen() is > out-of-line, so gcc would have to assume, that strcmp() has side > effects. How about just naming the m68k inline function 'strlen'? Having an inline function named "strlen" is not sufficient, as it needs an (exported) symbol named "strlen" at link time or module load time. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Geert Uytterhoeven <geert@linux-m68k.org> Date: Wed, 10 Apr 2013 11:24:39 +0200 > Without -ffreestanding, gcc may replace calls to standard C library > functions by calls to other standard C library functions and/or inline > code. This may cause link errors if the replacement code calls a standard > C library function that's implemented as a macro in the kernel. I think you should instead implement the library functions that gcc might emit during a build. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> My understanding is, that with -fnobuiltin, the compiler is not allowed > to make assumptions about functions if it does not see their definition, > even if they resemble standard functions. E.g. on x86_64, strlen() is > out-of-line, so gcc would have to assume, that strcmp() has side > effects. How about just naming the m68k inline function 'strlen'? You should always supply an out of line fallback version with the standard name. The easiest way is to define the right define so that lib/string.c does it. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile index 2f02acf..8e06a38 100644 --- a/arch/m68k/Makefile +++ b/arch/m68k/Makefile @@ -58,7 +58,7 @@ cpuflags-$(CONFIG_M5206e) := $(call cc-option,-mcpu=5206e,-m5200) cpuflags-$(CONFIG_M5206) := $(call cc-option,-mcpu=5206,-m5200) KBUILD_AFLAGS += $(cpuflags-y) -KBUILD_CFLAGS += $(cpuflags-y) -pipe +KBUILD_CFLAGS += $(cpuflags-y) -pipe -ffreestanding ifdef CONFIG_MMU # without -fno-strength-reduce the 53c7xx.c driver fails ;-( KBUILD_CFLAGS += -fno-strength-reduce -ffixed-a2
Without -ffreestanding, gcc may replace calls to standard C library functions by calls to other standard C library functions and/or inline code. This may cause link errors if the replacement code calls a standard C library function that's implemented as a macro in the kernel. E.g. gcc turned strncat(name, "%d", 2); into a call to strlen() and a 16-bit store, causing a link failure, as arch/m68k/include/asm/string.h provides strlen() using a macro: ERROR: "strlen" [net/ipv4/ip_tunnel.ko] undefined! In addition, this saves ca. 64 bytes of text on a typical kernel build. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- http://kisskb.ellerman.id.au/kisskb/buildresult/8462108/ QUESTION: Should we re-enable -ffreestanding in the main Makefile instead? It was removed in commit 6edfba1b33c701108717f4e036320fc39abe1912 Author: Andi Kleen <ak@suse.de> Date: Sat Mar 25 16:29:49 2006 +0100 [PATCH] x86_64: Don't define string functions to builtin gcc should handle this anyways, and it causes problems when sprintf is turned into strcpy by gcc behind our backs and the C fallback version of strcpy is actually defining __builtin_strcpy Then drop -ffreestanding from the main Makefile because it isn't needed anymore and implies -fno-builtin, which is wrong now. (it was only added for x86-64, so dropping it should be safe) Noticed by Roman Zippel Cc: Roman Zippel <zippel@linux-m68k.org> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org> Subsequently, it got re-enabled for mips, sh, x86-32, um/x86, xtensa, and score. arch/m68k/Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)