| Message ID | 537F7E5E.2030500@twiddle.net |
|---|---|
| State | New |
| Headers | show |
> +/* 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.
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~
> 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.
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)
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~