On Wed, Jan 21, 2009 at 4:12 AM, Andrew Brampton <brampton+freebsd-hack...@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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"