undefined reference to `memset'

[Vinod Kashyap]

> 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.