This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Fwd: non-ifunc pt-vfork
- From: Richard Henderson <rth at twiddle dot net>
- To: libc-alpha <libc-alpha at sourceware dot org>
- Date: Fri, 23 May 2014 09:59:10 -0700
- Subject: Fwd: non-ifunc pt-vfork
- Authentication-results: sourceware.org; auth=none
- References: <537F75A9 dot 6070503 at twiddle dot net>
Grr. Forgot libc-alpha...
r~
-------- Original Message --------
Subject: non-ifunc pt-vfork
Date: Fri, 23 May 2014 09:22:01 -0700
From: Richard Henderson <rth@twiddle.net>
To: Roland McGrath <roland@hack.frob.com>
CC: Joseph Myers <joseph@codesourcery.com>
After falling into the trap of the new nptl/pt-vfork.c on alpha,
I wonder if it's better to apply this patch
diff --git a/nptl/pt-vfork.c b/nptl/pt-vfork.c
index 81d1b71..72fc528 100644
--- a/nptl/pt-vfork.c
+++ b/nptl/pt-vfork.c
@@ -56,6 +56,9 @@ vfork_ifunc (void)
# else
+/* WARNING: If the compiler cannot turn this into a tail call,
+ then this mechanism will fail. The parent will save a return
+ address on the stack which will be clobbered by the child. */
attribute_hidden
pid_t
vfork_compat (void)
or to remove the non-ifunc portion of this file entirely. It does seem like
this sort of thing is going to have to be decided on a host-by-host basis,
and at least unavailable ifunc will error out at compile-time.
Alternately, we could drop this tail call stuff and just include vfork.os in
libpthread.so. It's not like it's a gigantic object file...
Thoughts?
r~