From owner-freebsd-amd64@FreeBSD.ORG Fri Mar 25 03:02:20 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 D0D7916A4CE; Fri, 25 Mar 2005 03:02:20 +0000 (GMT) Received: from hadar.amcc.com (hadar.amcc.com [192.195.69.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0118343D2D; Fri, 25 Mar 2005 03:02:19 +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 IDW0FY04.5SV; Thu, 24 Mar 2005 19:02:22 -0800 Received: (from vkashyap-pc [10.66.6.61]) by mailhost01.amcc.com (SMSSMTP 4.0.0.59) with SMTP id M2005032419051019735 ; Thu, 24 Mar 2005 19:05:11 -0800 From: "Vinod Kashyap" To: Peter Jeremy Date: Thu, 24 Mar 2005 19:01:17 -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: Fri, 25 Mar 2005 03:02:21 -0000 > -----Original Message----- > From: Peter Jeremy [mailto:PeterJeremy@optushome.com.au] > Sent: Thursday, March 24, 2005 2:46 PM > To: Vinod Kashyap > Cc: freebsd-stable@freebsd.org; freebsd-amd64@freebsd.org > Subject: Re: undefined reference to `memset' > = > = > On Thu, 2005-Mar-24 12:03:19 -0800, Vinod Kashyap wrote: > [ char x[100] =3D { 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. > = It is "char x[100] =3D {0};" and that's it. Doesn't it make it auto? Isn't auto the default? > > is necessary if you > >are dealing with re-entrancy. > = > This isn't completely true. The preferred approach is: > char *x; > x =3D malloc(100, MEM_POOL_xxx, M_ZERO | M_WAITOK); > (with a matching free() later). > = Well, I am in a function that is OS-independent, and cannot assume malloc (or a wrapper to it) is available. > > 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. > = Whatever that may be, I don't think the compiler should be stopping me from doing standard C stuff. I could be having this statement in my module with full knowledge that it would not cause a kernel stack overflow.= > >How is it then, that an explicit call to memset (like in my = > example) works? > = > The code > auto char x[100] =3D {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 = > = No, it's not. This is what I wrote in my first e-mail: "building of the GENERIC kernel on FreeBSD 5 -STABLE for amd64". I just forgot to mention that the problem did not occur when I build only the module. This is possibly due to different gcc flags being used in the 2 cases. > 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. > = Just like the problem is not seen when I build only the module, it's not seen if I simply write a foo.c (with the example code) and compile it. That's the reason I posted the patch to /sys/dev/twa/twa.c, which would cause the problem if applied, and then followed with a kernel build. I can send the result of running nm on twa.o tomorrow.