> 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. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"