I got the following compile error with gcc 4.1.1 when trying to compile
kernel 2.6.18-rc4-mm2 for m68k:
<-- snip -->
...
LD .tmp_vmlinux1
arch/m68k/amiga/built-in.o: In function `amiga_get_hardware_list':
config.c:(.text+0x882): undefined reference to `strcpy'
kernel/built-in.o: In function `prof_cpu_mask_read_proc':
profile.c:(.text+0x41ac): undefined reference to `strcpy'
kernel/built-in.o: In function `sysfs_show_available_clocksources':
clocksource.c:(.text+0x1434e): undefined reference to `strcpy'
kernel/built-in.o: In function `sysfs_show_current_clocksources':
clocksource.c:(.text+0x143a4): undefined reference to `strcpy'
fs/built-in.o: In function `lock_get_status':
locks.c:(.text+0x1198a): undefined reference to `strcpy'
fs/built-in.o:locks.c:(.text+0x119ae): more undefined references to `strcpy' follow
make[1]: *** [.tmp_vmlinux1] Error 1
<-- snip -->
The Linux kernel is a freestanding environment, not a hosted one
providing a full standard C library gcc can consider being present.
The fact that -ffreestanding had already been re-added on three
architectures also reflects this fact.
If we want to use a all or subset of the gcc builtins on some or all
architectures, we should make this explicitely through #define's.
This patch therefore reverts commit
6edfba1b33c701108717f4e036320fc39abe1912 and re-adds -ffreestanding to
the CFLAGS.
Signed-off-by: Adrian Bunk <[email protected]>
---
Makefile | 3 ++-
arch/i386/Makefile | 3 ---
arch/mips/Makefile | 2 --
arch/um/Makefile-i386 | 4 ----
include/asm-x86_64/string.h | 17 ++++++++++++++---
5 files changed, 16 insertions(+), 13 deletions(-)
--- linux-2.6.18-rc4-mm2/Makefile.old 2006-08-21 20:28:30.000000000 +0200
+++ linux-2.6.18-rc4-mm2/Makefile 2006-08-21 20:40:15.000000000 +0200
@@ -308,7 +308,8 @@
CPPFLAGS := -D__KERNEL__ $(LINUXINCLUDE)
CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
- -fno-strict-aliasing -fno-common
+ -fno-strict-aliasing -fno-common \
+ -ffreestanding
# Force gcc to behave correct even for buggy distributions
CFLAGS += $(call cc-option, -fno-stack-protector)
--- linux-2.6.18-rc4-mm2/arch/i386/Makefile.old 2006-08-21 20:40:26.000000000 +0200
+++ linux-2.6.18-rc4-mm2/arch/i386/Makefile 2006-08-21 20:40:33.000000000 +0200
@@ -39,9 +39,6 @@
cflags-$(CONFIG_REGPARM) += -mregparm=3
-# temporary until string.h is fixed
-cflags-y += -ffreestanding
-
# Disable unit-at-a-time mode on pre-gcc-4.0 compilers, it makes gcc use
# a lot more stack due to the lack of sharing of stacklots:
CFLAGS += $(shell if [ $(call cc-version) -lt 0400 ] ; then echo $(call cc-option,-fno-unit-at-a-time); fi ;)
--- linux-2.6.18-rc4-mm2/arch/mips/Makefile.old 2006-08-21 20:40:40.000000000 +0200
+++ linux-2.6.18-rc4-mm2/arch/mips/Makefile 2006-08-21 20:40:48.000000000 +0200
@@ -83,8 +83,6 @@
LDFLAGS_vmlinux += -G 0 -static -n -nostdlib
MODFLAGS += -mlong-calls
-cflags-y += -ffreestanding
-
#
# We explicitly add the endianness specifier if needed, this allows
# to compile kernels with a toolchain for the other endianness. We
--- linux-2.6.18-rc4-mm2/arch/um/Makefile-i386.old 2006-08-21 20:40:56.000000000 +0200
+++ linux-2.6.18-rc4-mm2/arch/um/Makefile-i386 2006-08-21 20:41:09.000000000 +0200
@@ -33,9 +33,5 @@
# prevent gcc from keeping the stack 16 byte aligned. Taken from i386.
cflags-y += $(call cc-option,-mpreferred-stack-boundary=2)
-# Prevent sprintf in nfsd from being converted to strcpy and resulting in
-# an unresolved reference.
-cflags-y += -ffreestanding
-
CFLAGS += $(cflags-y)
USER_CFLAGS += $(cflags-y)
--- linux-2.6.18-rc4-mm2/include/asm-x86_64/string.h.old 2006-08-21 20:49:07.000000000 +0200
+++ linux-2.6.18-rc4-mm2/include/asm-x86_64/string.h 2006-08-21 20:49:22.000000000 +0200
@@ -41,15 +41,26 @@
#define __HAVE_ARCH_MEMSET
-void *memset(void *s, int c, size_t n);
+#define memset __builtin_memset
#define __HAVE_ARCH_MEMMOVE
void * memmove(void * dest,const void *src,size_t count);
+/* Use C out of line version for memcmp */
+#define memcmp __builtin_memcmp
int memcmp(const void * cs,const void * ct,size_t count);
+
+/* out of line string functions use always C versions */
+#define strlen __builtin_strlen
size_t strlen(const char * s);
-char *strcpy(char * dest,const char *src);
-char *strcat(char * dest, const char * src);
+
+#define strcpy __builtin_strcpy
+char * strcpy(char * dest,const char *src);
+
+#define strcat __builtin_strcat
+char * strcat(char * dest, const char * src);
+
+#define strcmp __builtin_strcmp
int strcmp(const char * cs,const char * ct);
#endif /* __KERNEL__ */
On Mon, 21 Aug 2006 23:21:54 +0200
Adrian Bunk <[email protected]> wrote:
> I got the following compile error with gcc 4.1.1 when trying to compile
> kernel 2.6.18-rc4-mm2 for m68k:
I object to this change. -ffreestanding shouldn't be forced on everybody
-Andi
On Mon, Aug 21, 2006 at 11:24:44PM +0200, Andi Kleen wrote:
> On Mon, 21 Aug 2006 23:21:54 +0200
> Adrian Bunk <[email protected]> wrote:
>
> > I got the following compile error with gcc 4.1.1 when trying to compile
> > kernel 2.6.18-rc4-mm2 for m68k:
>
> I object to this change. -ffreestanding shouldn't be forced on everybody
Why?
The Linux kernel is a freestanding environment.
Omitting -ffreestanding only for allowing gcc to automatically use
builtins isn't a good idea (as we have already seen).
We can easily enable as many gcc builtins as we want.
We could even do this for all platforms in include/linux/string.h
It might make sense to do this properly since it could e.g. be the gcc
builtins produce no worse code than the inlines in
include/asm-i386/string.h.
But if this should be done, let's do it right and explicitely.
> -Andi
cu
Adrian
--
Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).
There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli
On Mon, 21 Aug 2006 23:46:36 +0200
Adrian Bunk <[email protected]> wrote:
> On Mon, Aug 21, 2006 at 11:24:44PM +0200, Andi Kleen wrote:
> > On Mon, 21 Aug 2006 23:21:54 +0200
> > Adrian Bunk <[email protected]> wrote:
> >
> > > I got the following compile error with gcc 4.1.1 when trying to compile
> > > kernel 2.6.18-rc4-mm2 for m68k:
> >
> > I object to this change. -ffreestanding shouldn't be forced on everybody
>
> Why?
Because -ffreestanding does the the wrong thing(tm) for the x86-64
string implementation (which I plan to extend at some point to i386
too BTW). Don't argue with it -- what counts is not the name,
but the semantics.
-Andi
On Tue, Aug 22, 2006 at 12:09:03AM +0200, Andi Kleen wrote:
> On Mon, 21 Aug 2006 23:46:36 +0200
> Adrian Bunk <[email protected]> wrote:
>
> > On Mon, Aug 21, 2006 at 11:24:44PM +0200, Andi Kleen wrote:
> > > On Mon, 21 Aug 2006 23:21:54 +0200
> > > Adrian Bunk <[email protected]> wrote:
> > >
> > > > I got the following compile error with gcc 4.1.1 when trying to compile
> > > > kernel 2.6.18-rc4-mm2 for m68k:
> > >
> > > I object to this change. -ffreestanding shouldn't be forced on everybody
> >
> > Why?
>
> Because -ffreestanding does the the wrong thing(tm) for the x86-64
> string implementation (which I plan to extend at some point to i386
> too BTW). Don't argue with it -- what counts is not the name,
> but the semantics.
It disables the automatic usage of builtins which is OK.
Which other semantics does it have that is causing problems?
> -Andi
cu
Adrian
--
Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).
There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli
> It disables the automatic usage of builtins which is OK.
No, it's not ok -- it is the problem. We want to use the builtins.
-Andi
On Tue, Aug 22, 2006 at 12:27:28AM +0200, Andi Kleen wrote:
>
> > It disables the automatic usage of builtins which is OK.
>
> No, it's not ok -- it is the problem. We want to use the builtins.
Without -ffreestanding, the compiler is completely free to decide
whether to use a builtin or whether to not use it - and which other C
library functions to use.
Your commit 6edfba1b33c701108717f4e036320fc39abe1912 that claimed
"it was only added for x86-64, so dropping it should be safe" was not
safe, it had broken at least mips and m68k. This wrong justification
alone should warrant a revert of this commit.
What's the problem with adding -ffreestanding and stating explicitely
which functions we want to be handled be builtins, and which functions
we don't want to be handled by builtins?
This looks like the right way to go instead of breaking other
architectures here and there.
> -Andi
cu
Adrian
--
Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).
There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli
> What's the problem with adding -ffreestanding and stating explicitely
> which functions we want to be handled be builtins, and which functions
> we don't want to be handled by builtins?
Take a look at lib/string.c and think about it a bit.
-Andi
Hi,
On Tue, 22 Aug 2006, Andi Kleen wrote:
> > It disables the automatic usage of builtins which is OK.
>
> No, it's not ok -- it is the problem. We want to use the builtins.
I agree and for m68k I have a patch to fix this properly.
bye, Roman
On Aug 21, 2006, at 19:13:20, Andi Kleen wrote:
>> What's the problem with adding -ffreestanding and stating
>> explicitely which functions we want to be handled be builtins, and
>> which functions we don't want to be handled by builtins?
>
> Take a look at lib/string.c and think about it a bit.
So why can't lib/string.c explicitly say __builtin_foo() instead of
foo() where we mean the former? Here's a brief summary:
With -ffreestanding:
__builtin_foo(): Use the GCC built-in if possible, otherwise out-
of-line
foo(): Always use the out-of-line function
Without -ffreestanding:
__builtin_foo(): Use the GCC built-in if possible, otherwise out-
of-line
foo(): Use the GCC built-in if possible, otherwise out-
of-line
What's wrong with always specifying -ffreestanding and using
__builtin_foo() instead of foo() where applicable? That's what it
was designed for, according to the GCC manual:
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/C-Dialect-Options.html#C-
Dialect-Options
If you want to unconditionally force a certain function to use the
GCC built-in on a particular architecture, you could always just do
this to get exactly the same result as without -ffreestanding:
#define memcpy(dest, src, len) __builtin_strcpy((dest), (src), (len))
#define memcmp(a, b, len) __builtin_strcmp((a), (b), (len))
[...]
Just stuff those types of defines in an x86-64 specific header
somewhere and turn on -ffreestanding unconditionally; you'll fix all
of the problems with MIPS, etc, without even changing the semantics
on x86-64.
Cheers,
Kyle Moffett
On Mon, 21 Aug 2006 23:37:31 -0400
Kyle Moffett <[email protected]> wrote:
> On Aug 21, 2006, at 19:13:20, Andi Kleen wrote:
> >> What's the problem with adding -ffreestanding and stating
> >> explicitely which functions we want to be handled be builtins, and
> >> which functions we don't want to be handled by builtins?
> >
> > Take a look at lib/string.c and think about it a bit.
>
> So why can't lib/string.c explicitly say __builtin_foo() instead of
> foo() where we mean the former?
Because gcc when using builtins sometimes decides to call the
out of line version (usually when it can't figure out the alignment
and generic alignment code would be too large to inline). And it will
always call str/memfoo not __builtin_str/memfoo
-Andi
On Tue, Aug 22, 2006 at 12:37:13PM +0200, Andi Kleen wrote:
> On Mon, 21 Aug 2006 23:37:31 -0400
> Kyle Moffett <[email protected]> wrote:
>
> > On Aug 21, 2006, at 19:13:20, Andi Kleen wrote:
> > >> What's the problem with adding -ffreestanding and stating
> > >> explicitely which functions we want to be handled be builtins, and
> > >> which functions we don't want to be handled by builtins?
> > >
> > > Take a look at lib/string.c and think about it a bit.
> >
> > So why can't lib/string.c explicitly say __builtin_foo() instead of
> > foo() where we mean the former?
>
> Because gcc when using builtins sometimes decides to call the
> out of line version (usually when it can't figure out the alignment
> and generic alignment code would be too large to inline). And it will
> always call str/memfoo not __builtin_str/memfoo
IOW, we might in some cases require an out-of-line version of the
function?
I don't see in this case any problem created by using -ffreestanding and
the #define's.
> -Andi
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed