https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81193
Michael Meissner <meissner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-06-26
Ever confirmed|0 |1
--- Comment #4 from Michael Meissner <meissner at gcc dot gnu.org> ---
I have no problems with restricting use of __builtin_cpu_<xxx> and target_clone
to GLIBC 2.19 or newer (or whatever the release version is). Now that I think
of it, yeah, we don't want to run ifunc resolvers if it has relocations. I
don't know whether the linker should warn about problematic code (it probably
should, or at least we need to document it somewhere). I was just surprised
that the compiler silently sets the test to 0.
Alternatively, we would need to do two passes. On the first pass resolve all
of the normal functions and data locations, setting the location of ifunc
functions in the TOC to be an error function. The second pass would resolve
the ifunc functions. If an ifunc function calls another ifunc function that
hasn't been resolved yet, it would go to the error function.
I think for the problem of using __builtin_cpu_<xxx>, we should issue a warning
(not a fatal error) if the configured GLIBC is too old saying you need to link
against a newer library, but generate the same code that we normally do. Given
there is a reference to an external provided with the new glibc, it should be
safe, because you would get a linker error if you actually tried to use it with
an old library. It would allow creation of libraries with functions using
__builtin_cpu_* and target_clone with an old compiler, providing the library is
linked appropriately.
It would also allow the tests for target_clone to work. Though I probably will
switch my builds to use --with-advance-toolchain to always get the new library
(now that works with bootstrap).
