[PATCH roland/nptl-sh] SH: Consolidate NPTL/non versions of vfork

[Kaz Kojima]

Roland McGrath <roland@hack.frob.com> wrote:
> I haven't tried to compile this or anything.  It should result in no
> changes to the object code.  The only change should be in libpthread.so's
> symbol table, where the {__,}vfork@@GLIBC_x.y symbols become just
> @GLIBC_x.y.  It might be ideal to avoid the copy of the vfork code in
> libpthread, as I've done for other machines.  That would need the
> __libc_vfork alias added to vfork.S and then either an assembly
> implementation of a tail call to the __libc_vfork PLT entry or testimony
> that a C tail call will definitely get compiled into a proper tail call.
> I'll leave that further cleanup to Kaz.
> 
> 
> Thanks,
> Roland
> 
> 
> 2014-05-29  Roland McGrath  <roland@hack.frob.com>
> 
> 	* nptl/sysdeps/unix/sysv/linux/sh/vfork.S: Moved ...
> 	* sysdeps/unix/sysv/linux/sh/vfork.S: ... here.
> 	* sysdeps/unix/sysv/linux/sh/pt-vfork.S: New file.
> 	* nptl/sysdeps/unix/sysv/linux/sh/pt-vfork.S: File removed.

vfork.S part works as expected in my environment.

> --- /dev/null
> +++ b/sysdeps/unix/sysv/linux/sh/pt-vfork.S
[snip]
> +#if SHLIB_COMPAT (libc, GLIBC_2_0, GLIBC_2_20)
> +# include <vfork.S>
> +
> +compat_symbol (__vfork, __vfork, GLIBC_2_0)
> +compat_symbol (vfork, vfork, GLIBC_2_0)
> +#endif

I thought that pt-vfork.S is for libpthread.so and
it would be

#if SHLIB_COMPAT (libpthread, GLIBC_2_0, GLIBC_2_20)
# include <vfork.S>

compat_symbol (libpthread, __vfork, __vfork, GLIBC_2_0)
compat_symbol (libpthread, vfork, vfork, GLIBC_2_0)
#endif

Am I missing something here?

Regards,
	kaz