From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 24 20:04:19 2005 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 595C616A4CE; Thu, 24 Mar 2005 20:04:19 +0000 (GMT) Received: from hadar.amcc.com (hadar.amcc.com [192.195.69.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA36D43D2F; Thu, 24 Mar 2005 20:04:18 +0000 (GMT) (envelope-from vkashyap@amcc.com) Received: from mailhost01.amcc.com ([192.195.69.30]) by hadar.amcc.com (Netscape Messaging Server 4.15) with SMTP id IDVH3802.ESF; Thu, 24 Mar 2005 12:04:20 -0800 Received: (from vkashyap-pc [10.66.6.61]) by mailhost01.amcc.com (SMSSMTP 4.0.0.59) with SMTP id M2005032412073715466 ; Thu, 24 Mar 2005 12:07:37 -0800 From: "Vinod Kashyap" To: Bruce Evans Date: Thu, 24 Mar 2005 12:03:19 -0800 X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4 51114 (9.0.6627) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: cc: freebsd-stable@freebsd.org cc: freebsd-amd64@freebsd.org Subject: RE: undefined reference to `memset' X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2005 20:04:19 -0000 > 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.