Kernel Module - GCC Requires memmove

Garrett Cooper yanefbsd at gmail.com
Wed Jan 21 15:26:11 PST 2009


On Wed, Jan 21, 2009 at 4:12 AM, Andrew Brampton
<brampton+freebsd-hackers at gmail.com> wrote:
> Hi,
> I'm doing the unusual task of converting some c++ code into a FreeBSD
> kernel module. Now all has been going great, and thus far I've been
> able to debug quite a bit of it using printfs. However, I decided to
> start using a kernel debugger, and to make this easier I passed g++
> the –O0 flag, to make it compile without optimisations.
>
> Bang, I hit a problem. All of a sudden when using the –O0 my module
> wouldn't load because it was missing an undefined reference to
> memmove. I found the specific object file which was using memmove. I
> did that by doing objdump –t *.o and finding which file had an
> undefined symbol memmove. Once I found the object file I grepped the
> associated source and I was sure I was not using memmove. I then got
> gcc to output both the post-processed source, as well as the asm.
>
> The .ii file (post-processed source) did NOT mention memmove at all.
> So I found it very odd that an undefined symbol existed in the object
> file.  So then I looked in the .s file (asm), and it was clearing
> making a single call to memmove.
>
> So after a few hours of pulling my hair out I found this in the gcc manual:
> "-nostdlib .... The compiler may generate calls to memcmp, memset,
> memcpy and memmove. These entries are usually resolved by entries in
> libc. These entry points should be supplied through some other
> mechanism when this option is specified."
>
> So it appears that gcc may add calls to those four functions even if
> you don't use them yourself? I assume this has not been a problem for
> anyone yet due to only crazy people trying to use c++ in the kernel,
> and the specific set of gcc options I'm using.
>
> For the moment I have fixed this problem now by defining my own memmove like so:
>
> extern "C" void * memmove(void * dst, const void * src, size_t len) {
>        bcopy(src, dst, len);
>        return dst;
> }
>
> But I was wondering if those four functions should be defined in the
> kernel? I notice that memcpy and memset are already defined by the
> kernel somewhere, so perhaps memmove and memcmp should join them?
>
> Oh I should mention this was happening with the default gcc under FreeBSD 7.1.
>
> Thanks
> Andrew

And you #include'd string.h?
-Garrett


More information about the freebsd-hackers mailing list