[PATCH v2] nptl: remove duplicate vfork() in libpthread

[Bernhard Reutner-Fischer]

On September 17, 2015 12:09:17 AM GMT+02:00, Vineet Gupta <Vineet.Gupta1 at synopsys.com> wrote:
>Hi Bernhard,
>
>
>On Tuesday 04 August 2015 01:42 AM, Vineet Gupta wrote:
>> On Friday 31 July 2015 12:23 AM, Bernhard Reutner-Fischer wrote:
>>> On July 24, 2015 9:17:27 AM GMT+02:00, Vineet Gupta
><Vineet.Gupta1 at synopsys.com> wrote:
>>>> On Friday 24 July 2015 09:26 AM, Bernhard Reutner-Fischer wrote:
>>>>> On July 22, 2015 5:05:34 PM GMT+02:00, Alexey Brodkin
>>>> <Alexey.Brodkin at synopsys.com> wrote:
>>>>>>> Hi Bernard,
>>>>>>> This patch indeed fixes problems with duplicate vfork in both
>libc
>>>> and
>>>>>>> libpthread.
>>>>>>> I'm wondering if there's a chance for this patch to be applied
>>>> still?
>>>>> Well, but it's wrong, isn't it. 
>>>> Is it ? It makes pthread also use the libc version. The only
>difference
>>>> between
>>>> them was pthread version had a small optimization which could be
>done
>>>> away
>>>> altogether with if u read thru the tread below.
>>>>
>>>> https://sourceware.org/ml/libc-alpha/2014-05/msg00238.html
>>>>
>>>>> pt-vfork.o should instead live in, say,  libpthread_nonshared.a
>and
>>>> be at the end of the libs so it is picked up by the linker when
>static
>>>> linking, no?
>>>>
>>>> Could be done that way too but not needed if above is sufficient.
>>> Above makes RESET_PID superfluous, doesn't it.
>> 
>> RESET_PID applies to clone; while{SAVE,RESTORE}_PID apply to vfork. I
>presume u
>> meant latter ? Perhaps clone can be tweaked too - but thats for
>another patch !
>> 
>> Assuming above is correct, you want those macros to be removed from
>> nptl/*/**/vfork.S as well as libc/sysdeps/linux/*/vfork.S and
>preferably replace
>> with a comment in case of latter set of files.
>> 
>> Can this be done in 2 steps, so the first patch from Waldemar be
>applied as it is
>> and then we do the cleanup to remove _PID from all the files (or is
>it too much
>> churn cross arches)

2-step is fine for me too, as you prefer.

>> 
>> After this, it would be even better if we get rid of the vfork files
>in NPTL as it
>> is confusing at best (as file building for libc resides in thread
>library). Why

Yes, the only reason was the PID handling, AFAIR.
Thanks,