On Wed, Feb 23, 2000 at 11:27:42PM -0300, Horst von Brand wrote:
> Daniel.Egger@suse.de said:
>
> [...]
>
> > I'd like to append another question. The current gcc seems to have
> > problems with memcpy calls in the kernel source. When compiling a
> > kernel I get unresolved memcpy symbols for example in hisax.
> > Although memcpy is used all over the source I get these
> > unresolved symbols just in a few places.
>
> Where, exactly? Note that memcpy per se is implemented again for the kernel
> (When the compiler contains perfectly good inlined implementations of
> several of the string and memory handling functions. Beats me why), so if
> you do not include <linux/string.h>, it will end up missing.
gcc may generate memcpy/memset calls internally (common on several architectures,
quite uncommon on Intel). I've sent a test case to Jan Hubicka for a case
where gcc generates a memset call internally (it was initializing a
local structure variable, which included a char array and in the initializer
was set with a string of a shorter length, like:
struct foo {
char name[20];
};
void bar(struct foo *);
void baz(void) {
struct foo f = { "short" };
bar(&f);
}
). IMHO it is a bug in gcc because for this case the clearing does not go
through standard mechanisms which would generate ia32 builtins, and as it is
rather rare, kernel does not export memcpy/memset symbols at all on i386
(unlike some other ports).
Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj
Linux version 2.3.47 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:09 EST