[cfe-dev] FreeBSD kernel - linking

[Eli Friedman]

On Thu, Feb 12, 2009 at 12:55 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Feb 12, 2009, at 12:35 PM, Roman Divacky wrote:
>
>> On Thu, Feb 12, 2009 at 11:23:16AM -0800, Mike Stump wrote:
>>> On Feb 12, 2009, at 10:53 AM, Chris Lattner wrote:
>>>> that won't help, clang generates these for structure copies.
>>>
>>> There are only a couple of options.  One, clang is documented to
>>> require memmove, and we require the kernel to have one.  Two, clang
>>> is
>>> documented as not requiring it, and we generate inline code, or calls
>>> to a runtime library that is linked against.  Three, we generate
>>> calls
>>> to a clang internal routine, and emit it linkonce (comdat) in every
>>> translation unit that references it.  Now, the canonical solution
>>> _is_
>>> -fno-builtin-memmove, if implemented, it would do something
>>> indistinguishable from the last.  Why do you say it won't help?
>
> GCC probably "happens to work" because it optimizes out the memmoves
> in cases that clang isn't yet.  It is definitely unportable to assume
> that the compiler won't emit those.

gcc will generate memmoves in certain cases, for example
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16172.  It definitely
reserves the right to generate them.  So FreeBSD is just lucky that
they haven't hit this with gcc yet.

Probably worth quoting again
(http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Standards.html): "Most of
the compiler support routines used by GCC are present in libgcc, but
there are a few exceptions. GCC requires the freestanding environment
provide memcpy, memmove, memset and memcmp."

Note that the reason you're seening memcpy in places gcc doesn't
generate it is that gcc normally uses memcpy instead of memmove for
struct copies.  The standard makes some allowance for this (C99
6.5.16.1):

"If the value being stored in an object is read from another object
that overlaps in any way
the storage of the first object, then the overlap shall be exact and
the two objects shall
have qualified or unqualified versions of a compatible type;
otherwise, the behavior is
undefined."

That said, we decided to make clang generate memmove of memcpy instead
for a couple of reasons: one, it's  safer (it's quite easy to arrange
such an illegal assignment with unions), and two, calling memcpy is
technically incorrect for the case of assigning a struct to itself.

If the FreeBSD developers want compiler-generated memory moves to call
some function other than memmove, that can probably be arranged with a
command-line option.

-Eli