On September 17, 2015 12:09:17 AM GMT+02:00, Vineet Gupta <vineet.gup...@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.gup...@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.brod...@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, _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc