undefined reference to `memset'

[Vinod Kashyap]

> -----Original Message-----
> From: Peter Jeremy [mailto:PeterJeremy at optushome.com.au]
> Sent: Thursday, March 24, 2005 2:46 PM
> To: Vinod Kashyap
> Cc: freebsd-stable at freebsd.org; freebsd-amd64 at freebsd.org
> 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.