undefined reference to `memset'

Vinod Kashyap vkashyap at amcc.com
Thu Mar 24 12:04:19 PST 2005

> This version makes the pessimizations and potential bugs clear:
> - clearing 100 bytes on every entry to the function is 
> wasteful.  C90's
>    auto initializers hide pessimizations like this.  They should be
>    used very rarely, especially in kernels.  But they are 
> often misused,
>    even in kernels, even for read-only data that should be 
> static.  gcc
>    doesn't optimize even "auto const x[100] = { 0 };" to a static
>    initialization -- the programmer must declare the object 
> as static to
>    prevent gcc laboriously clearing it on every entry to the function.
> - 100 bytes may be too much to put on the kernel stack.  Objects just
>    a little larger than this must be dynamically allocated unless they
>    can be read-only.

A statement like this (auto and not static) is necessary if you
are dealing with re-entrancy.  Whatever the issues with wastage or
bad performance, a programmer should definitely be able to do it,
if he so desires.  Also, the line I mentioned earlier was only
an example.  Something like this also fails (your response already
explains this):
struct x_type x = {0};

> > Adding CFLAGS+=-fbuiltin, or CFLAGS+=-fno-builtin to 
> /sys/conf/Makefile.amd64
> > does not help.
> -fno-builtin is already in CFLAGS, and if it has any effect 
> on this then
> it should be to cause gcc to generate a call to memset() 
> instead of doing
> the memory clearing inline.  I think gcc has a builtin 
> memset() which is
> turned off by -fno-builtin, but -fno-builtin doesn't affect 
> cases where
> memset() is not referenced in the source code.
> -ffreestanding should prevent gcc generating calls to library 
> functions
> like memset().  However, -ffreestanding is already in CFLAGS too, and
> there is a problem: certain initializations like the one in 
> your example
> need to use an interface like memset(), and struct copies 
> need to use and
> interface like memcpy(), so what is gcc to do when 
> -fno-builtin tells it
> to turn off its builtins and -ffreestanding tells it that the relevant
> interfaces might not exist in the library?
> > Anyone knows what's happening?
> gcc is expecting that memset() is in the library, but the 
> FreeBSD kernel
> is freestanding and happens not to have memset() in its library.

How is it then, that an explicit call to memset (like in my example) works?

As about other questions in the thread:
1. Yes, the example code is within a function,
2. I should have mentioned that I don't see the problem if I am
   building only the kernel module.  It happens only when I am building
   the kernel integrating the module containing the example code.

More information about the freebsd-stable mailing list