Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Mar 2005 12:03:19 -0800
From:      "Vinod Kashyap" <vkashyap@amcc.com>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        freebsd-amd64@freebsd.org
Subject:   RE: undefined reference to `memset'
Message-ID:  <IDVH3802.ESF@hadar.amcc.com>

next in thread | raw e-mail | index | archive | help
> 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] =3D { 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 =3D {0};
-----

> > Adding CFLAGS+=3D-fbuiltin, or CFLAGS+=3D-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.






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?IDVH3802.ESF>