non-ifunc pt-vfork
diff mbox

Message ID 537F7E5E.2030500@twiddle.net
State New
Headers show

Commit Message

Richard Henderson May 23, 2014, 4:59 p.m. UTC
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


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~

Comments

Roland McGrath May 23, 2014, 8:43 p.m. UTC | #1
> +/* 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.  */

Good point.  That should have occurred to me.

> 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.

That would be fine with me.

> 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...

Any individual machine is free to do that.
Richard Henderson May 23, 2014, 9 p.m. UTC | #2
On 05/23/2014 01:43 PM, Roland McGrath wrote:
>> +/* 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.  */
> 
> Good point.  That should have occurred to me.
> 
>> 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.
> 
> That would be fine with me.
> 
>> 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...
> 
> Any individual machine is free to do that.

Oh, I forgot to ask -- were you intending to make the pthread vfork
non-default, so that new programs would always link to the libc vfork?


r~
Roland McGrath May 23, 2014, 9:40 p.m. UTC | #3
> Oh, I forgot to ask -- were you intending to make the pthread vfork
> non-default, so that new programs would always link to the libc vfork?

Yes.

Patch
diff mbox

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)