removing bcopy... because it's half broken

removing bcopy... because it's half broken

[Arjan van de Ven]

Hi,

Nothing in the kernel is using bcopy right know, and that is a good thing.
Why? Because a lot of the architectures implement a broken bcopy()....
the userspace standard bcopy() is basically a memmove() with a weird
parameter order, however a bunch of architectures implement a memcpy() not a
memmove(). 

Instead of fixing this inconsistency, I decided to remove it entirely,
explicit memcpy() and memmove() are prefered anyway (welcome to the 1990's)
and nothing in the kernel is using these functions, so this saves code size
as well for everyone.

Greetings,
    Arjan van de Ven


Signed-off-by: Arjan van de Ven <arjan@infradead.org>

diff -purN linux-2.6.10/arch/alpha/lib/memmove.S linux/arch/alpha/lib/memmove.S
--- linux-2.6.10/arch/alpha/lib/memmove.S	2004-12-24 22:34:45.000000000 +0100
+++ linux/arch/alpha/lib/memmove.S	2005-01-09 20:10:08.027900120 +0100
@@ -12,18 +12,6 @@
 	.text
 
 	.align 4
-	.globl bcopy
-	.ent bcopy
-bcopy:
-	ldgp $29, 0($27)
-	.prologue 1
-	mov $16,$0
-	mov $17,$16
-	mov $0,$17
-	br  $31, memmove	!samegp
-	.end bcopy
-
-	.align 4
 	.globl memmove
 	.ent memmove
 memmove:
diff -purN linux-2.6.10/arch/ia64/lib/memcpy_mck.S linux/arch/ia64/lib/memcpy_mck.S
--- linux-2.6.10/arch/ia64/lib/memcpy_mck.S	2004-12-24 22:35:50.000000000 +0100
+++ linux/arch/ia64/lib/memcpy_mck.S	2005-01-09 20:10:52.793487402 +0100
@@ -17,15 +17,6 @@
 
 #define EK(y...) EX(y)
 
-GLOBAL_ENTRY(bcopy)
-	.regstk 3,0,0,0
-	mov r8=in0
-	mov in0=in1
-	;;
-	mov in1=r8
-	;;
-END(bcopy)
-
 /* McKinley specific optimization */
 
 #define retval		r8
diff -purN linux-2.6.10/arch/ia64/lib/memcpy.S linux/arch/ia64/lib/memcpy.S
--- linux-2.6.10/arch/ia64/lib/memcpy.S	2004-12-24 22:33:48.000000000 +0100
+++ linux/arch/ia64/lib/memcpy.S	2005-01-09 20:10:35.365594731 +0100
@@ -15,22 +15,6 @@
  */
 #include <asm/asmmacro.h>
 
-GLOBAL_ENTRY(bcopy)
-	.regstk 3,0,0,0
-	mov r8=in0
-	mov in0=in1
-	;;
-	mov in1=r8
-	// gas doesn't handle control flow across procedures, so it doesn't
-	// realize that a stop bit is needed before the "alloc" instruction
-	// below
-{
-	nop.m 0
-	nop.f 0
-	nop.i 0
-}	;;
-END(bcopy)
-	// FALL THROUGH
 GLOBAL_ENTRY(memcpy)
 
 #	define MEM_LAT	21		/* latency to memory */
diff -purN linux-2.6.10/arch/parisc/lib/memcpy.c linux/arch/parisc/lib/memcpy.c
--- linux-2.6.10/arch/parisc/lib/memcpy.c	2004-12-24 22:35:39.000000000 +0100
+++ linux/arch/parisc/lib/memcpy.c	2005-01-09 20:11:30.370950807 +0100
@@ -515,16 +515,8 @@ void * memcpy(void * dst,const void *src
 	return dst;
 }
 
-void bcopy(const void * srcp, void * destp, size_t count)
-{
-	mtsp(get_kernel_space(), 1);
-	mtsp(get_kernel_space(), 2);
-	pa_memcpy(destp, srcp, count);
-}
-
 EXPORT_SYMBOL(copy_to_user);
 EXPORT_SYMBOL(copy_from_user);
 EXPORT_SYMBOL(copy_in_user);
 EXPORT_SYMBOL(memcpy);
-EXPORT_SYMBOL(bcopy);
 #endif
diff -purN linux-2.6.10/arch/ppc/boot/common/misc-common.c linux/arch/ppc/boot/common/misc-common.c
--- linux-2.6.10/arch/ppc/boot/common/misc-common.c	2004-12-24 22:34:45.000000000 +0100
+++ linux/arch/ppc/boot/common/misc-common.c	2005-01-09 20:12:20.245930722 +0100
@@ -52,7 +52,6 @@ extern char _end[];
 void puts(const char *);
 void putc(const char c);
 void puthex(unsigned long val);
-void _bcopy(char *src, char *dst, int len);
 void gunzip(void *, int, unsigned char *, int *);
 static int _cvt(unsigned long val, char *buf, long radix, char *digits);
 
diff -purN linux-2.6.10/arch/ppc/lib/string.S linux/arch/ppc/lib/string.S
--- linux-2.6.10/arch/ppc/lib/string.S	2004-12-24 22:35:00.000000000 +0100
+++ linux/arch/ppc/lib/string.S	2005-01-09 20:11:50.375536299 +0100
@@ -216,12 +216,6 @@ _GLOBAL(memset)
 	bdnz	8b
 	blr
 
-_GLOBAL(bcopy)
-	mr	r6,r3
-	mr	r3,r4
-	mr	r4,r6
-	b	memcpy
-
 /*
  * This version uses dcbz on the complete cache lines in the
  * destination area to reduce memory traffic.  This requires that
diff -purN linux-2.6.10/arch/ppc64/boot/string.S linux/arch/ppc64/boot/string.S
--- linux-2.6.10/arch/ppc64/boot/string.S	2004-12-24 22:33:48.000000000 +0100
+++ linux/arch/ppc64/boot/string.S	2005-01-09 20:14:08.556853992 +0100
@@ -96,13 +96,6 @@ memset:
 	bdnz	8b
 	blr
 
-	.globl	bcopy
-bcopy:
-	mr	r6,r3
-	mr	r3,r4
-	mr	r4,r6
-	b	memcpy
-
 	.globl	memmove
 memmove:
 	cmplw	0,r3,r4
diff -purN linux-2.6.10/arch/s390/lib/string.c linux/arch/s390/lib/string.c
--- linux-2.6.10/arch/s390/lib/string.c	2004-12-24 22:34:31.000000000 +0100
+++ linux/arch/s390/lib/string.c	2005-01-09 20:14:30.358221316 +0100
@@ -357,21 +357,6 @@ void *memcpy(void *dest, const void *src
 EXPORT_SYMBOL(memcpy);
 
 /**
- * bcopy - Copy one area of memory to another
- * @src: Where to copy from
- * @dest: Where to copy to
- * @n: The size of the area.
- *
- * Note that this is the same as memcpy(), with the arguments reversed.
- * memcpy() is the standard, bcopy() is a legacy BSD function.
- */
-void bcopy(const void *srcp, void *destp, size_t n)
-{
-	__builtin_memcpy(destp, srcp, n);
-}
-EXPORT_SYMBOL(bcopy);
-
-/**
  * memset - Fill a region of memory with the given value
  * @s: Pointer to the start of the area.
  * @c: The byte to fill the area with
diff -purN linux-2.6.10/arch/sparc/kernel/sparc_ksyms.c linux/arch/sparc/kernel/sparc_ksyms.c
--- linux-2.6.10/arch/sparc/kernel/sparc_ksyms.c	2004-12-24 22:33:52.000000000 +0100
+++ linux/arch/sparc/kernel/sparc_ksyms.c	2005-01-09 20:13:50.977976644 +0100
@@ -75,7 +75,6 @@ extern void *__memscan_generic(void *, i
 extern int __memcmp(const void *, const void *, __kernel_size_t);
 extern int __strncmp(const char *, const char *, __kernel_size_t);
 
-extern void bcopy (const char *, char *, int);
 extern int __ashrdi3(int, int);
 extern int __ashldi3(int, int);
 extern int __lshrdi3(int, int);
@@ -261,7 +260,6 @@ EXPORT_SYMBOL(__prom_getchild);
 EXPORT_SYMBOL(__prom_getsibling);
 
 /* sparc library symbols */
-EXPORT_SYMBOL(bcopy);
 EXPORT_SYMBOL(memchr);
 EXPORT_SYMBOL(memscan);
 EXPORT_SYMBOL(strlen);
diff -purN linux-2.6.10/arch/sparc/lib/memcpy.S linux/arch/sparc/lib/memcpy.S
--- linux-2.6.10/arch/sparc/lib/memcpy.S	2004-12-24 22:35:49.000000000 +0100
+++ linux/arch/sparc/lib/memcpy.S	2005-01-09 20:13:32.887160994 +0100
@@ -1,5 +1,5 @@
-/* memcpy.S: Sparc optimized memcpy, bcopy and memmove code
- * Hand optimized from GNU libc's memcpy, bcopy and memmove
+/* memcpy.S: Sparc optimized memcpy and memmove code
+ * Hand optimized from GNU libc's memcpy and memmove
  * Copyright (C) 1991,1996 Free Software Foundation
  * Copyright (C) 1995 Linus Torvalds (Linus.Torvalds@helsinki.fi)
  * Copyright (C) 1996 David S. Miller (davem@caip.rutgers.edu)
@@ -192,13 +192,6 @@ x:
 	retl
 	 nop		! Only bcopy returns here and it retuns void...
 
-FUNC(bcopy)
-	mov		%o0, %o3
-	mov		%o1, %o0
-	mov		%o3, %o1
-	tst		%o2
-	bcs		0b
-	 /* Do the cmp in the delay slot */
 #ifdef __KERNEL__
 FUNC(amemmove)
 FUNC(__memmove)
diff -purN linux-2.6.10/arch/v850/lib/memcpy.c linux/arch/v850/lib/memcpy.c
--- linux-2.6.10/arch/v850/lib/memcpy.c	2004-12-24 22:34:00.000000000 +0100
+++ linux/arch/v850/lib/memcpy.c	2005-01-09 20:12:32.512449966 +0100
@@ -60,11 +60,6 @@ void *memcpy (void *dst, const void *src
 	return dst;
 }
 
-void bcopy (const char *src, char *dst, int size)
-{
-	memcpy (dst, src, size);
-}
-
 void *memmove (void *dst, const void *src, __kernel_size_t size)
 {
 	if ((unsigned long)dst < (unsigned long)src
diff -purN linux-2.6.10/include/asm-alpha/string.h linux/include/asm-alpha/string.h
--- linux-2.6.10/include/asm-alpha/string.h	2004-12-24 22:34:31.000000000 +0100
+++ linux/include/asm-alpha/string.h	2005-01-09 20:15:53.571171144 +0100
@@ -13,7 +13,6 @@
 #define __HAVE_ARCH_MEMCPY
 extern void * memcpy(void *, const void *, size_t);
 #define __HAVE_ARCH_MEMMOVE
-#define __HAVE_ARCH_BCOPY
 extern void * memmove(void *, const void *, size_t);
 
 /* For backward compatibility with modules.  Unused otherwise.  */
diff -purN linux-2.6.10/include/asm-arm/string.h linux/include/asm-arm/string.h
--- linux-2.6.10/include/asm-arm/string.h	2004-12-24 22:34:57.000000000 +0100
+++ linux/include/asm-arm/string.h	2005-01-09 20:15:57.529692986 +0100
@@ -25,8 +25,6 @@ extern void * memchr(const void *, int, 
 #define __HAVE_ARCH_MEMSET
 extern void * memset(void *, int, __kernel_size_t);
 
-#define __HAVE_ARCH_BCOPY
-
 extern void __memzero(void *ptr, __kernel_size_t n);
 
 #define memset(p,v,n)							\
diff -purN linux-2.6.10/include/asm-ia64/string.h linux/include/asm-ia64/string.h
--- linux-2.6.10/include/asm-ia64/string.h	2004-12-24 22:35:27.000000000 +0100
+++ linux/include/asm-ia64/string.h	2005-01-09 20:16:04.466855017 +0100
@@ -14,7 +14,6 @@
 #define __HAVE_ARCH_STRLEN	1 /* see arch/ia64/lib/strlen.S */
 #define __HAVE_ARCH_MEMSET	1 /* see arch/ia64/lib/memset.S */
 #define __HAVE_ARCH_MEMCPY	1 /* see arch/ia64/lib/memcpy.S */
-#define __HAVE_ARCH_BCOPY	1 /* see arch/ia64/lib/memcpy.S */
 
 extern __kernel_size_t strlen (const char *);
 extern void *memcpy (void *, const void *, __kernel_size_t);
diff -purN linux-2.6.10/include/asm-mips/string.h linux/include/asm-mips/string.h
--- linux-2.6.10/include/asm-mips/string.h	2004-12-24 22:33:48.000000000 +0100
+++ linux/include/asm-mips/string.h	2005-01-09 20:16:13.267791892 +0100
@@ -137,9 +137,6 @@ extern void *memcpy(void *__to, __const_
 #define __HAVE_ARCH_MEMMOVE
 extern void *memmove(void *__dest, __const__ void *__src, size_t __n);
 
-/* Don't build bcopy at all ...  */
-#define __HAVE_ARCH_BCOPY
-
 #ifdef CONFIG_MIPS32
 #define __HAVE_ARCH_MEMSCAN
 static __inline__ void *memscan(void *__addr, int __c, size_t __size)
diff -purN linux-2.6.10/include/asm-parisc/string.h linux/include/asm-parisc/string.h
--- linux-2.6.10/include/asm-parisc/string.h	2004-12-24 22:35:18.000000000 +0100
+++ linux/include/asm-parisc/string.h	2005-01-09 20:15:19.211321312 +0100
@@ -7,7 +7,4 @@ extern void * memset(void *, int, size_t
 #define __HAVE_ARCH_MEMCPY
 void * memcpy(void * dest,const void *src,size_t count);
 
-#define __HAVE_ARCH_BCOPY
-void bcopy(const void * srcp, void * destp, size_t count);
-
 #endif
diff -purN linux-2.6.10/include/asm-ppc/string.h linux/include/asm-ppc/string.h
--- linux-2.6.10/include/asm-ppc/string.h	2004-12-24 22:35:23.000000000 +0100
+++ linux/include/asm-ppc/string.h	2005-01-09 20:16:42.961204809 +0100
@@ -9,7 +9,6 @@
 #define __HAVE_ARCH_STRCMP
 #define __HAVE_ARCH_STRCAT
 #define __HAVE_ARCH_MEMSET
-#define __HAVE_ARCH_BCOPY
 #define __HAVE_ARCH_MEMCPY
 #define __HAVE_ARCH_MEMMOVE
 #define __HAVE_ARCH_MEMCMP
diff -purN linux-2.6.10/include/asm-ppc64/string.h linux/include/asm-ppc64/string.h
--- linux-2.6.10/include/asm-ppc64/string.h	2004-12-24 22:35:01.000000000 +0100
+++ linux/include/asm-ppc64/string.h	2005-01-09 20:16:17.374295829 +0100
@@ -14,7 +14,6 @@
 #define __HAVE_ARCH_STRCMP
 #define __HAVE_ARCH_STRCAT
 #define __HAVE_ARCH_MEMSET
-#define __HAVE_ARCH_BCOPY
 #define __HAVE_ARCH_MEMCPY
 #define __HAVE_ARCH_MEMMOVE
 #define __HAVE_ARCH_MEMCMP
diff -purN linux-2.6.10/include/asm-s390/string.h linux/include/asm-s390/string.h
--- linux-2.6.10/include/asm-s390/string.h	2004-12-24 22:35:50.000000000 +0100
+++ linux/include/asm-s390/string.h	2005-01-09 20:16:20.728890591 +0100
@@ -15,7 +15,6 @@
 #include <linux/types.h>
 #endif
 
-#define __HAVE_ARCH_BCOPY	/* arch function */
 #define __HAVE_ARCH_MEMCHR	/* inline & arch function */
 #define __HAVE_ARCH_MEMCMP	/* arch function */
 #define __HAVE_ARCH_MEMCPY	/* gcc builtin & arch function */
diff -purN linux-2.6.10/include/asm-sh/string.h linux/include/asm-sh/string.h
--- linux-2.6.10/include/asm-sh/string.h	2004-12-24 22:35:25.000000000 +0100
+++ linux/include/asm-sh/string.h	2005-01-09 20:15:27.574311224 +0100
@@ -124,7 +124,4 @@ extern void *memchr(const void *__s, int
 #define __HAVE_ARCH_STRLEN
 extern size_t strlen(const char *);
 
-/* Don't build bcopy at all ...  */
-#define __HAVE_ARCH_BCOPY
-
 #endif /* __ASM_SH_STRING_H */
diff -purN linux-2.6.10/include/asm-sparc/string.h linux/include/asm-sparc/string.h
--- linux-2.6.10/include/asm-sparc/string.h	2005-01-09 14:51:10.270104409 +0100
+++ linux/include/asm-sparc/string.h	2005-01-09 20:16:25.412324821 +0100
@@ -22,7 +22,6 @@ extern __kernel_size_t __memset(void *,i
 #ifndef EXPORT_SYMTAB_STROPS
 
 /* First the mem*() things. */
-#define __HAVE_ARCH_BCOPY
 #define __HAVE_ARCH_MEMMOVE
 #undef memmove
 #define memmove(_to, _from, _n) \
diff -purN linux-2.6.10/include/asm-v850/string.h linux/include/asm-v850/string.h
--- linux-2.6.10/include/asm-v850/string.h	2004-12-24 22:35:50.000000000 +0100
+++ linux/include/asm-v850/string.h	2005-01-09 20:15:34.961418983 +0100
@@ -14,13 +14,11 @@
 #ifndef __V850_STRING_H__
 #define __V850_STRING_H__
 
-#define __HAVE_ARCH_BCOPY
 #define __HAVE_ARCH_MEMCPY
 #define __HAVE_ARCH_MEMSET
 #define __HAVE_ARCH_MEMMOVE
 
 extern void *memcpy (void *, const void *, __kernel_size_t);
-extern void bcopy (const char *, char *, int);
 extern void *memset (void *, int, __kernel_size_t);
 extern void *memmove (void *, const void *, __kernel_size_t);
 
diff -purN linux-2.6.10/lib/string.c linux/lib/string.c
--- linux-2.6.10/lib/string.c	2005-01-09 14:51:10.378091142 +0100
+++ linux/lib/string.c	2005-01-09 20:09:38.031526681 +0100
@@ -454,30 +454,6 @@ void * memset(void * s,int c,size_t coun
 EXPORT_SYMBOL(memset);
 #endif
 
-#ifndef __HAVE_ARCH_BCOPY
-/**
- * bcopy - Copy one area of memory to another
- * @srcp: Where to copy from
- * @destp: Where to copy to
- * @count: The size of the area.
- *
- * Note that this is the same as memcpy(), with the arguments reversed.
- * memcpy() is the standard, bcopy() is a legacy BSD function.
- *
- * You should not use this function to access IO space, use memcpy_toio()
- * or memcpy_fromio() instead.
- */
-void bcopy(const void * srcp, void * destp, size_t count)
-{
-	const char *src = srcp;
-	char *dest = destp;
-
-	while (count--)
-		*dest++ = *src++;
-}
-EXPORT_SYMBOL(bcopy);
-#endif
-
 #ifndef __HAVE_ARCH_MEMCPY
 /**
  * memcpy - Copy one area of memory to another

Re: removing bcopy... because it's half broken

[Ralf Baechle]

On Sun, Jan 09, 2005 at 07:23:05PM +0000, Arjan van de Ven wrote:

For a long time MIPS has defined __HAVE_ARCH_BCOPY without actually
implementing bcopy, so any kernel use did result in a build error.  As
far as I can recall all that it has caught were a few missconfigured
gccs, so yes, away with it.

  Ralf

Re: removing bcopy... because it's half broken

[Russell King]

On Sun, Jan 09, 2005 at 07:23:05PM +0000, Arjan van de Ven wrote:
> Nothing in the kernel is using bcopy right know, and that is a good thing.
> Why? Because a lot of the architectures implement a broken bcopy()....
> the userspace standard bcopy() is basically a memmove() with a weird
> parameter order, however a bunch of architectures implement a memcpy() not a
> memmove(). 

ARM doesn't implement bcopy() but does define __HAVE_ARCH_BCOPY - so
any users would error.  Removing bcopy() is therefore no problem
afaics, and I'll lend my support by trying to will it to be gone. 8)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: removing bcopy... because it's half broken

[Linus Torvalds]

On Sun, 9 Jan 2005, Arjan van de Ven wrote:
>
> Instead of fixing this inconsistency, I decided to remove it entirely,
> explicit memcpy() and memmove() are prefered anyway (welcome to the 1990's)
> and nothing in the kernel is using these functions, so this saves code size
> as well for everyone.

The problem is that at least some gcc versions would historically generate
calls to "bcopy" on alpha for structure assignments. Maybe it doesn't any
more, and no such old gcc versions exist any more, but who knows?

That's also why "bcopy" just acts like a memcpy() in many cases: it's 
simply not worth it to do the complex case, because the only valid use was 
a compiler that would never validly do overlapping ranges anyway.

Gcc _used_ to have a target-specific "do I use bcopy or memcpy" setting,
and I just don't know if that is still true. I also don't know if it
affected any other platforms than alpha (I would assume that it matched
"target has BSD heritage", and that would likely mean HP-UX too)

Richard? You know both gcc and alpha, what's the word?

		Linus

Re: removing bcopy... because it's half broken

[Arjan van de Ven]

On Sun, 2005-01-09 at 12:19 -0800, Linus Torvalds wrote:
> 
> On Sun, 9 Jan 2005, Arjan van de Ven wrote:
> >
> > Instead of fixing this inconsistency, I decided to remove it entirely,
> > explicit memcpy() and memmove() are prefered anyway (welcome to the 1990's)
> > and nothing in the kernel is using these functions, so this saves code size
> > as well for everyone.
> 

> Gcc _used_ to have a target-specific "do I use bcopy or memcpy" setting,
> and I just don't know if that is still true. I also don't know if it
> affected any other platforms than alpha (I would assume that it matched
> "target has BSD heritage", and that would likely mean HP-UX too)

actually I think that is called -ffreestanding, and 
ChangeSet 1.2088, 2005/01/04 21:29:33-08:00, bunk@stusta.de
added that to the compiler flags in your tree ....

Re: removing bcopy... because it's half broken

[Christoph Hellwig]

On Sun, Jan 09, 2005 at 12:19:09PM -0800, Linus Torvalds wrote:
> The problem is that at least some gcc versions would historically generate
> calls to "bcopy" on alpha for structure assignments. Maybe it doesn't any
> more, and no such old gcc versions exist any more, but who knows?

We're building with -ffreestanding now, so gcc isn't allowed to emit
any calls to standard library functions.

Re: removing bcopy... because it's half broken

[Linus Torvalds]

On Sun, 9 Jan 2005, Christoph Hellwig wrote:
> 
> We're building with -ffreestanding now, so gcc isn't allowed to emit
> any calls to standard library functions.

Bzzt. It still emits calls to libgcc. 

It cannot _not_ do so. There are simply operations that gcc doesn't 
generate native code for, ie divides on certain architectures etc.

And that very much includes bcopy/memcpy on most architectures.

		Linus

Re: removing bcopy... because it's half broken

[Richard Henderson]

On Sun, Jan 09, 2005 at 12:19:09PM -0800, Linus Torvalds wrote:
> Gcc _used_ to have a target-specific "do I use bcopy or memcpy" setting,
> and I just don't know if that is still true.

Yes, TARGET_MEM_FUNCTIONS.  It's never not set for Linux targets.
Or for OSF/1 for that matter...  Indeed, it would take me some time
to figure out which targets it's *not* set for.

(Yet another thing that ought to get cleaned up -- either invert the
default value or simply require the target to either provide the libc
entry point or add a version to libgcc.)

I'm not sure how far back you'd have to go to find an Alpha compiler
that needs this.  Prolly back to at least gcc 2.6, but I don't have
sources that old handy to check.



r~

Re: removing bcopy... because it's half broken

[Adrian Bunk]

On Sun, Jan 09, 2005 at 12:19:09PM -0800, Linus Torvalds wrote:
> 
> 
> On Sun, 9 Jan 2005, Arjan van de Ven wrote:
> >
> > Instead of fixing this inconsistency, I decided to remove it entirely,
> > explicit memcpy() and memmove() are prefered anyway (welcome to the 1990's)
> > and nothing in the kernel is using these functions, so this saves code size
> > as well for everyone.
> 
> The problem is that at least some gcc versions would historically generate
> calls to "bcopy" on alpha for structure assignments. Maybe it doesn't any
> more, and no such old gcc versions exist any more, but who knows?
>...

include/asm-alpha/string.h says:

  /*
   * GCC of any recent vintage doesn't do stupid things with bcopy.
   * EGCS 1.1 knows all about expanding memcpy inline, others don't.
   *
   * Similarly for a memset with data = 0.
   */


And Arjan's patch is pretty low-risk:

If it breaks on any architecture with any supported compiler (>= 2.95), 
it will break at compile time and there will pretty fast be reports of 
this breakage in which case it would be easy to revert his patch.


> 		Linus

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

Re: removing bcopy... because it's half broken

[Matthias-Christian Ott]

Adrian Bunk wrote:

>On Sun, Jan 09, 2005 at 12:19:09PM -0800, Linus Torvalds wrote:
>  
>
>>On Sun, 9 Jan 2005, Arjan van de Ven wrote:
>>    
>>
>>>Instead of fixing this inconsistency, I decided to remove it entirely,
>>>explicit memcpy() and memmove() are prefered anyway (welcome to the 1990's)
>>>and nothing in the kernel is using these functions, so this saves code size
>>>as well for everyone.
>>>      
>>>
>>The problem is that at least some gcc versions would historically generate
>>calls to "bcopy" on alpha for structure assignments. Maybe it doesn't any
>>more, and no such old gcc versions exist any more, but who knows?
>>...
>>    
>>
>
>include/asm-alpha/string.h says:
>
>  /*
>   * GCC of any recent vintage doesn't do stupid things with bcopy.
>   * EGCS 1.1 knows all about expanding memcpy inline, others don't.
>   *
>   * Similarly for a memset with data = 0.
>   */
>
>
>And Arjan's patch is pretty low-risk:
>
>If it breaks on any architecture with any supported compiler (>= 2.95), 
>it will break at compile time and there will pretty fast be reports of 
>this breakage in which case it would be easy to revert his patch.
>
>
>  
>
>>		Linus
>>    
>>
>
>cu
>Adrian
>
>  
>
Jep and most people are using a newer gcc and newer glibc. Linux has to 
stay up2date, so I think it's the best choise to create a modern and 
clean (without broken functions) OS.

Matthias-Christian Ott

Re: removing bcopy... because it's half broken

[Bastian Blank]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

On Sun, Jan 09, 2005 at 12:42:42PM -0800, Linus Torvalds wrote:
> On Sun, 9 Jan 2005, Christoph Hellwig wrote:
> > We're building with -ffreestanding now, so gcc isn't allowed to emit
> > any calls to standard library functions.
> Bzzt. It still emits calls to libgcc. 

Yes. This means IMHO that the image and every module needs to link
against libgcc to include the required symbols. It is rather annoying to
see modules asking for libgcc symbols.

Bastian

-- 
It would be illogical to assume that all conditions remain stable.
		-- Spock, "The Enterprise Incident", stardate 5027.3

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: removing bcopy... because it's half broken

[Arjan van de Ven]

On Tue, 2005-01-11 at 11:10 +0100, Bastian Blank wrote:
> On Sun, Jan 09, 2005 at 12:42:42PM -0800, Linus Torvalds wrote:
> > On Sun, 9 Jan 2005, Christoph Hellwig wrote:
> > > We're building with -ffreestanding now, so gcc isn't allowed to emit
> > > any calls to standard library functions.
> > Bzzt. It still emits calls to libgcc. 
> 
> Yes. This means IMHO that the image and every module needs to link
> against libgcc to include the required symbols. It is rather annoying to
> see modules asking for libgcc symbols.

I disagree with your first sentence: The kernel provides the required
symbols (bcopy is special here, it no longer gets emitted by gcc since
like gcc version 2.6); the ones the kernel does NOT provide are
generally undesirable in kernel spec, eg floating point and 64 bit
divisions...

Re: removing bcopy... because it's half broken

[Linus Torvalds]

On Tue, 11 Jan 2005, Bastian Blank wrote:
> 
> Yes. This means IMHO that the image and every module needs to link
> against libgcc to include the required symbols. It is rather annoying to
> see modules asking for libgcc symbols.

Some architectures do that. Not all. My argument has always been that we
don't _want_ any code that gcc cannot generate.

The kernel very much on purpose does not trust gcc. There have been some 
total braindamages over time, like having exception handling turned on by 
default by gcc by default in plain C, and one of the reasons we noticed 
was that the link wouldn't work - libgcc has the exception support, and 
the kernel simply doesn't WANT that kind of crap.

It's also been useful (although at times a bit painful) to find cases
where people did stuff that simply shouldn't be done in the kernel. Things
like FP conversions, or - more commonly - 64-bit divides on hardware where
that is very slow.

It does mean that we have to know about some gcc internals ourselves, and
have our own libgcc versions for the stuff we _do_ want.

			Linus