undefined reference to `memset'
Vinod Kashyap
vkashyap at amcc.com
Thu Mar 24 19:02:21 PST 2005
> -----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.
More information about the freebsd-amd64
mailing list