diff mbox

[roland/nptl] Clean up NPTL fork to be compat-only.

Message ID 20140623232544.34E462C39BA@topped-with-meat.com
State New
Headers show

Commit Message

Roland McGrath June 23, 2014, 11:25 p.m. UTC 
(This is on the branch after the big change only because the file moved and
I didn't want to futz around more.  It's actually orthogonal.)  AFAIK there
was never any reason whatsoever to have fork/__fork in the libpthread.so
ABI.  We can get rid of it for the future, and optimize it marginally for
IFUNC-capable configurations.

Tested x86_64-linux-gnu.


Thanks,
Roland


	* nptl/pt-fork.c: Rewritten.  Put everything under
	[SHLIB_COMPAT (libpthread, GLIBC_2_0, GLIBC_2_20)].
	Use IFUNC to redirect when possible.

Comments

Joseph Myers June 23, 2014, 11:32 p.m. UTC | #1 
On Mon, 23 Jun 2014, Roland McGrath wrote:

> +/* libpthread once had its own fork, though there was no apparent reason
> +   for it.  There is no use in having a separate symbol in libpthread, but
> +   the historical ABI requires it.  For static linking, there is no need to
> +   provide anything here--the libc version will be linked in.  For shared
> +   library ABI compatibility, there must be __vfork and vfork symbols in

__fork and fork not __vfork and vfork?
Roland McGrath June 25, 2014, 1:31 a.m. UTC | #2 
> On Mon, 23 Jun 2014, Roland McGrath wrote:
> 
> > +/* libpthread once had its own fork, though there was no apparent reason
> > +   for it.  There is no use in having a separate symbol in libpthread, but
> > +   the historical ABI requires it.  For static linking, there is no need to
> > +   provide anything here--the libc version will be linked in.  For shared
> > +   library ABI compatibility, there must be __vfork and vfork symbols in
> 
> __fork and fork not __vfork and vfork?

Oops!  Yes.  Fixed on the branch.


Thanks,
Roland
diff mbox

Patch

--- a/nptl/pt-fork.c
+++ b/nptl/pt-fork.c
@@ -17,11 +17,55 @@ 
    <http://www.gnu.org/licenses/>.  */
 
 #include <unistd.h>
+#include <shlib-compat.h>
 
+/* libpthread once had its own fork, though there was no apparent reason
+   for it.  There is no use in having a separate symbol in libpthread, but
+   the historical ABI requires it.  For static linking, there is no need to
+   provide anything here--the libc version will be linked in.  For shared
+   library ABI compatibility, there must be __vfork and vfork symbols in
+   libpthread.so; so we define them using IFUNC to redirect to the libc
+   function.  */
 
-pid_t
-__fork (void)
+#if SHLIB_COMPAT (libpthread, GLIBC_2_0, GLIBC_2_20)
+
+# if HAVE_IFUNC
+
+static __typeof (fork) *
+__attribute__ ((used))
+fork_resolve (void)
+{
+  return &__libc_fork;
+}
+
+#  ifdef HAVE_ASM_SET_DIRECTIVE
+#   define DEFINE_FORK(name) \
+  asm (".set " #name ", fork_resolve\n" \
+       ".globl " #name "\n" \
+       ".type " #name ", %gnu_indirect_function");
+#  else
+#   define DEFINE_FORK(name) \
+  asm (#name " = fork_resolve\n" \
+       ".globl " #name "\n" \
+       ".type " #name ", %gnu_indirect_function");
+#  endif
+
+# else  /* !HAVE_IFUNC */
+
+static pid_t __attribute__ ((used))
+fork_compat (void)
 {
   return __libc_fork ();
 }
-strong_alias (__fork, fork)
+
+# define DEFINE_FORK(name) strong_alias (fork_compat, name)
+
+# endif  /* HAVE_IFUNC */
+
+DEFINE_FORK (fork_ifunc)
+compat_symbol (libpthread, fork_ifunc, fork, GLIBC_2_0);
+
+DEFINE_FORK (__fork_ifunc)
+compat_symbol (libpthread, __fork_ifunc, __fork, GLIBC_2_1_2);
+
+#endif