From owner-freebsd-stable@FreeBSD.ORG Thu Mar 24 22:46:09 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28BA016A4CE; Thu, 24 Mar 2005 22:46:09 +0000 (GMT) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CE4043D54; Thu, 24 Mar 2005 22:46:08 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j2OMk3vV006966 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 25 Mar 2005 09:46:04 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j2OMk27l048346; Fri, 25 Mar 2005 09:46:03 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j2OMk2np048345; Fri, 25 Mar 2005 09:46:02 +1100 (EST) (envelope-from pjeremy) Date: Fri, 25 Mar 2005 09:46:02 +1100 From: Peter Jeremy To: Vinod Kashyap Message-ID: <20050324224602.GC43123@cirb503493.alcatel.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i cc: freebsd-stable@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: undefined reference to `memset' X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2005 22:46:09 -0000 On Thu, 2005-Mar-24 12:03:19 -0800, Vinod Kashyap wrote: [ char x[100] = { 0 }; ] >A statement like this (auto and not static) I'd point out that this is the first time that you've mentioned that the variable is auto. Leaving out critical information will not encourage people to help you. > is necessary if you >are dealing with re-entrancy. This isn't completely true. The preferred approach is: char *x; x = malloc(100, MEM_POOL_xxx, M_ZERO | M_WAITOK); (with a matching free() later). > Whatever the issues with wastage or >bad performance, a programmer should definitely be able to do it, >if he so desires. Again, untrue. The FreeBSD kernel is not a standard C environment. Kernel stack is a relatively small, fixed size and using excessive kernel stack will lead to panics. Increasing the kernel stack size is undesirable because it's expensive in RAM consumption. >How is it then, that an explicit call to memset (like in my example) works? The code auto char x[100] = {0}; is equivalent to auto char x[100]; memset(x, 0, sizeof(x)); but memset only exists as a static inline function (defined in libkern.h). If an explicit call to memset works then the problem would appear to be that the compiler's implicit expansion is failing to detect the static inline definition, and generating an external reference which can't be satisfied. This would seem to be a gcc bug. >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. This is the opposite of what you implied previously. There are some differences in how kernel modules are built so this How about posting a (short) compilable piece of C code that shows the problem. I would expect that an "nm" of the resultant object would show "U memset" when the code was compiled for linking into the kernel and " t memset" or not reference memset at all when compiled as a module. -- Peter Jeremy