Content-Length: 788

Lines: 30
Whether we sidestep it in init/main.c or not, such situations

will arise again; compiler does generate calls of strcat()

on optimizations, so we really ought to have an out-of-line

version...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

---

 arch/m68k/lib/string.c |    6 ++++++

 1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/m68k/lib/string.c b/arch/m68k/lib/string.c

index 891e134..4253f87 100644

--- a/arch/m68k/lib/string.c

+++ b/arch/m68k/lib/string.c

@@ -15,6 +15,12 @@ char *strcpy(char *dest, const char *src)

 }

 EXPORT_SYMBOL(strcpy);
+char *strcat(char *dest, const char *src)

+{

+	return __kernel_strcpy(dest + __kernel_strlen(dest), src);

+}

+EXPORT_SYMBOL(strcat);

+

 void *memset(void *s, int c, size_t count)

 {

 	void *xs = s;

--

1.5.3.GIT
--

Can we try to get this sorted out properly instead of constantly

fiddling with it?
Currently we use -ffreestanding on some architectures and fix breakages

on the other architectures when they arise.
The options I see for getting this fixed properly are:

- use -ffreestanding on all architectures or

- don't use -ffreestanding on any architecture and move the string

  functions (and perhaps other functions if required) out-of-line
I'd prefer the first option, but I know that not everyone agrees with me.
No matter which option we choose, if we get an agreement on this one

I can send patches for it.
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
--

Hi,
This won't help completely unless you also clean up all archs to use the

same mappings to the builtin functions.
The main problem I had with -ffreestanding is that it's awkward to map a

library function to the builtin function and also provide the fallback

from lib/string.c.

If you look at asm-m68k/string.h I once tried this with the mem* functions

and I still have the duplicated memcmp in arch/m68k/lib/string.c.

(You could argue that it would be easier to just remove the define for

memcmp in this specific case, but I'm interested in the general case.)
bye, Roman

--

Hi,
It actually was strlen that was generated and not strcat.
bye, Roman

--

Here it replaced strncat() with call of strcat() (gcc 4.0.1, FWIW).

And yes, I can show you init/main.s with

	jbsr strcat	|

in it generated on kernel in b0rken range...

--

Hi,
Please use a more recent compiler, 4.0 created too many problems on m68k,

which we only got under control with 4.1, so at least on m68k 4.0 is not

really supported.
bye, Roman

--

Then it's worth mentioning in Documentation/Changes, IMO...  Anyway,

updating m68k toolchain is not a problem; I'll get around to it tonight.

I still think that out-of-line implementation is a good idea, if nothing

else it would prevent future crap of the same kind if some later version

decides that strlen(a) + strlen(b) can be proven to be less than size

argument of strncat(), etc.
Technically we _are_ in nasal daemon country with redefining str*, unless

we pass -ffreestanding; m68k doesn't, so we can't guarantee that new stuff

of that kind won't crop up.  IOW, it might be a good policy to have fallback

implementations of potentially affected primitives...

--