Date: Wed, 21 Jan 2009 15:26:09 -0800 From: Garrett Cooper <yanefbsd@gmail.com> To: Andrew Brampton <brampton+freebsd-hackers@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel Module - GCC Requires memmove Message-ID: <7d6fde3d0901211526x26e03968n658874fe7a7b85cf@mail.gmail.com> In-Reply-To: <d41814900901210412h4a1aaec6l6945dd79d07d13be@mail.gmail.com> References: <d41814900901210412h4a1aaec6l6945dd79d07d13be@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 21, 2009 at 4:12 AM, Andrew Brampton
<brampton+freebsd-hackers@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 =96O0 flag, to make it compile without optimisations.
>
> Bang, I hit a problem. All of a sudden when using the =96O0 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 =96t *.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 manua=
l:
> "-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 l=
ike 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7d6fde3d0901211526x26e03968n658874fe7a7b85cf>