This is the mail archive of the libc-alpha@sourceware.org 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]

Fwd: non-ifunc pt-vfork


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~



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