This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 0/2] inprove vfork compat

> Was there a particular reason you eschewed gcc's ifunc support?
> Is it too new or something?  It certainly seems better than having
> to mark the function "used", and knowing how the target handles "set".

I looked and saw that we didn't have any precedent for using it.  I decided
to follow the existing models for IFUNC cases rather than figure out if the
history of GCC versions (back to our minimum version for building libc from
install.texi, 4.4) for all targets with binutils IFUNC support necessarily
include the attribute support (maybe including the possibility of a GCC
built with a binutils that didn't support IFUNC and so disabled the support
but now you're building with a newer binutils that passes our IFUNC
configure check).  I also decided against adding a separate GCC feature
check in configure on the principle that building libc should either
exploit IFUNC or not and we should not permit builds where some of the
IFUNC-based implementation features are selected and others are not.

If we grow any more casual uses of IFUNC like this one, then we should
consider cleaning up how we do it.  That could mean using the attribute
support and serving the principle I just defined by simply making configure
disable IFUNC entirely if binutils supports it but the compiler doesn't.
Some research on what ranges of GCC versions for what targets have the
support would inform the decision on whether this is a reasonable course.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]