Re: glibc 2.18 freeze!

[Roland McGrath <roland at hack dot frob dot com>]

> Pushed as 6a97b62a5b4f18aea849d6f4d8de58d1469d2521. I'll fill a GCC bug
> about this issue. I can think some possible solutions:
> 
> * Add a option like -f tree-loop-distribute-patterns-prepend=XXX where GLIBC
> can add "__GI_";
> 
> * Add a algorithm to check if symbol's name is memset/memove and then
> not generate the recursive call.
> 
> Any other possible solution to add on the bug report?

Those two suggestions address two different issues that should not be
conflated.  Please be sure that each GCC bug you file is about one issue
and is clear on what it is in fact about.

The second suggestion goes to the specific problem of
-ftree-loop-distribute-patterns applying to implementations of functions
like memset.  I'm not sure we need any GCC changes to rectify that.
Putting __attribute__ ((optimize ("no-tree-loop-distribute-patterns")))
on our implementations seems sufficient.  Does anyone think that we need
some compiler assistance beyond that?

The first suggestion goes to the general problem of compiler-emitted
calls that might have name space issues.  There are two reasons this can
be a problem.

One is the name space issue per se, where the symbol name the compiler
thinks is a library function whose semantics it knows could actually be
a symbol defined by the user application; an example of this is calling
__builtin_mempcpy and getting a call to mempcpy generated--the source of
the function doesn't call a symbol named "mempcpy", only some symbols
starting with __, but now the generated code refers to "mempcpy", which
the program might define to be something wholly unrelated.  For that
particular situation there is a kludgy workaround available (for each
__builtin_foo you use, you can redeclare foo with asm ("__foo") or
whatever other name).  But I consider this to be the same case as any
other reason the compiler decides to emit a call that was not in the
program a literal call to a real function (memcpy for aggregate
assignment, whatever calls -ftree-loop-distribute-patterns makes, etc.).

This problem affects user programs, not just the library implementation.
For example, a user application built without -D_GNU_SOURCE is free to
define a function or variable called mempcpy name that has nothing to do
with the libc function mempcpy.  However, strncat is implemented as a
macro that in some circumstances works by calling __mempcpy and
__mempcpy is a macro that works by calling __builtin_mempcpy.  If the
compiler decides to implement __builtin_mempcpy by generating a call to
mempcpy, then this program, whose source uses only strncat, now calls
mempcpy--and this will get the user's mempcpy rather than libc's.  This
means that requiring a special compiler switch is not a solution.
Either the non-C89 symbols must always be used with __-prefixed names as
a hard-coded behavior, or else there must be some way that code (in a
header file) can declare to the compiler that it wants different names
for particular symbols that does not affect the front-end interpretation
of the source code at all.

The second reason is our PLT avoidance scheme.  Because of the mechanics
of how we do it, this boils down to wanting to tell the compiler a
prefix to prepend to all symbol names of calls it decides to generate.
Doing that with a switch would be fine.


Thanks,
Roland