* Brent M. Smith (smitten@nextreality.net) [20000310 03:23]:
> kernel/kernel.o: In function `check_free_space':
> kernel/kernel.o(.text+0xb394): undefined reference to `memset'
> make: *** [vmlinux] Error 1
> [root@smitten]:/usr/src/linux#
Let me guess: you're using a CVS version of gcc, right? Current CVS gcc has
lowered the limit where it will stop creating inlined memcpy and start
creating libcalls. All of the places I've found to date were either doing
direct struct copying (via a = b) or passing structs by value.
To identify the places where this happens, call gcc with '-g -save-temps'
added to the compiler flags (best done via a 'CFLAGS := -g -save-temps' in
the subdir Makefile) and then do an 'as -alh' on the resulting assembly
file. This will get you a combined C/assembly listing which rather easily
lets you identify the place where gcc generated the memcpy() libcall.
Now as to why we don't have a non inlined memcpy() like Alpha has I'll have
to let others answer.
The real question here is how to fix these places.
Passing larger structs by value (64 bytes in one case) is IMO a bug in itself.
For the struct copying the fix isn't that clear, as struct_cpy() is *only*
defined in asm-i386.h (which calls memcpy after a compile time size check).
So IMHO struct_cpy() either should be defined for all archs, or i386 should
define a non inlined memcpy() and I'd favour the latter. Not doing either
makes the code depend on gcc's way of handling it which may (and in this
case did) change.
I fixed the places I found so far by directly using memcpy() which I find
the cleanest solution given the current situation, but I'd really like
comments on how to really fix this matter.
Philipp
-- Philipp Thomas <pthomas@suse.de> SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany#define NINODE 50 /* number of in core inodes */ #define NPROC 30 /* max number of processes */ -- Version 7 UNIX fuer PDP 11, /usr/include/sys/param.h
- 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 : Wed Mar 15 2000 - 21:00:22 EST