Re: __builtin_* expansion to outcalls vs name space issues

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Tue, Feb 5, 2013 at 12:35 PM, Roland McGrath <roland@hack.frob.com> wrote:
> I happened to be looking at disassembly of elf/dl-hwcaps.o and noticed
> that it had calls to mempcpy.  That set off alarm bells since this is
> deep internals code that should never be using symbols outside the C89
> implementation name space, which mempcpy is.  Looking deeper, I found
> that all that source code is in fact properly calling __mempcpy as it
> should.
>
> The issue arises because <bits/string2.h> defines __mempcpy as a macro
> using __builtin_mempcpy.  Then GCC decides not to inline these cases,
> and generates calls to mempcpy.  (Looking at the compiler, it seems like
> it might well treat mempcpy as __builtin_mempcpy too in -std=gnu99 mode.
> But it would never treat __mempcpy that way AFAIK.)
>
> What should be the expectation of responsibility here?  On the one hand,
> it seems vaguely reasonable that __builtin_foobar degenerates to calling
> foobar.  On the other hand, it is surprising to me that the compiler
> should ever generate an implicit call to a symbol outside the most
> constrained implementation name space.  If my source code uses only
> symbols in a limited name space, then the compiler should not expand the
> scope of name space my code interacts with.
>
> So, are we wrong for using __builtin_mempcpy in a place where a call to
> mempcpy is not kosher?  Or is GCC wrong for having __builtin_* ever
> generate a call to something outside the C89 implementation name space?
>
> In either case, what do we do to fix it?  In the former, we'd have to
> give up some compiler-managed optimization opportunities and enforce a
> nonobvious discipline about referring to __builtin_*.  In the latter, we
> need to teach GCC to call __mempcpy instead, but is that going to cause
> any problems?
>

If you compile glibc with -Os, there will be more unexpected entries
in elf/check-localplt.out.

-- 
H.J.