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

Vineet Gupta Vineet.Gupta1 at synopsys.com
Wed Sep 16 22:09:17 UTC 2015


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)
> 
> 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
> not build libc/sysdeps/linux/*/vfork.S in place for libc. But you are better off
> doing such project wide tweaks than us mere mortals.
> 
> Thx,
> -Vineet
> 

What do u think abt this ?

-Vineet





More information about the uClibc mailing list