This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 0/2] inprove vfork compat
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 23 May 2014 19:04:47 -0700 (PDT)
- Subject: Re: [PATCH 0/2] inprove vfork compat
- Authentication-results: sourceware.org; auth=none
- References: <1400886936-16338-1-git-send-email-rth at twiddle dot net>
> 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.