> -----Original Message----- > From: Peter Jeremy [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 24, 2005 2:46 PM > To: Vinod Kashyap > Cc: freebsd-stable@freebsd.org; [EMAIL PROTECTED] > Subject: Re: undefined reference to `memset' > > > 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. >
It is "char x[100] = {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 = 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] = {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 "<some_address> 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. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"