This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: __builtin_* expansion to outcalls vs name space issues
On Wed, Feb 6, 2013 at 8:48 AM, Carlos O'Donell <carlos@systemhalted.org> wrote:
> On 02/05/2013 08:41 PM, H.J. Lu wrote:
>> 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.
>
> Please file bugs for these, we want to be able to build reliably at -Os.
http://www.sourceware.org/bugzilla/show_bug.cgi?id=15105
--
H.J.