Date: Thu, 24 Mar 2005 19:01:17 -0800 From: "Vinod Kashyap" <vkashyap@amcc.com> To: Peter Jeremy <PeterJeremy@optushome.com.au> Cc: freebsd-amd64@freebsd.org Subject: RE: undefined reference to `memset' Message-ID: <IDW0FY04.5SV@hadar.amcc.com>
next in thread | raw e-mail | index | archive | help
> -----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 "<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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?IDW0FY04.5SV>