[cfe-dev] FreeBSD kernel - linking

[Roman Divacky]

On Thu, Feb 12, 2009 at 04:17:39PM -0800, Eli Friedman wrote:
> 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.

I'll introduce memmove into the FreeBSD kernel, thanks for your great
arguments that will come to a good use :)