Peter Mazinger wrote: > Hi all, > Hi Peter, happy to hear from you, >> At this stage my proposal is to start *now* putting TLS/futexes/NPTL code >> into the trunk. This will not impact any architectures. >> NPTL is configurable, as well as FUTEXES (used for stdio locking). >> We should probably add a config option for enabling TLS (this is currently >> hard coded into the tls.h header by defining USE_TLS. > > My proposals: > - keep TLS and NPTL as separate options, what is now in nptl-branch does not > consider the possibility of having TLS with Linuxthreads definitively correct: it seems to me indeed that the nptl branch was not born with the idea of merging all together since the beginning > - TLS is no option for LT old, block that possibility (as well the > cancellation moving to libc wont be compatible with LT old and will either > need LT old adaption - I would not do that, or use macros as I proposed that > are noops/do somethink else for LT old) I was actually referring to these macros you proposed times ago. > - do some checks that keep out people using unproper options, like: Rules.mak > checks for gcc __thread support currently (this is though a TLS relevant > check, not NPTL only) good point > - do not allow FUTEX enabling if NR_futex is defined (it is probably not even > enough, it will need some newer futex in kernel, futex syscall was added > somewhere around 2.5.5x? iirc, but that version is not good enough, maybe it > will need at least a specific kernel version, you might know that better) > >> We could fix bugs in NPTL code (i.e. signal handling changes) directly >> working on trunk. I did not expect any changes into ld.so for TLS. > > not true, TLS support needs to go into ld.so (search for a comment I added > for sjhill long ago, saying sjhill, your TLS stuff goes before this iirc), > much of it can be guarded with the new TLS option, but there should be a > check outside of the TLS option, that does not allow the use of TLS enabled > code at runtime if the option is disabled (someone might have compiled code > with TLS enabled, after that it might disable TLS in libc) > sorry I was not clear, my fault. I meant I do not expect any other changes but those already added in ld.so in nptl branch (all of these guarded by USE_TLS).
>> We need to look carefully at cancellation handling, but this will get >> benefit from having all the code into trunk, because there are more guys >> looking at this than those using nptl branch. > > look at the cancellation implementation of the arm port, that tries not using > duplicated code in libc/libpthread, the only thing I would try to do, do not > "hardcode" the cancellation as arm-port does, use macros instead. This is wat sh4 does too (you are right about duplicattion in libc/libpthread). I raised this question to sjhill times an times ago, but nothing. FYI uclibc package I released for my company uclibc version does not contain these. Again macros would make think more readable, but I don't know if it's better changing these code before or after merging. We can decide later. > It should also be decided, which functions should be cancellable (SuSv3 > mentions only a few as mandatory, LT old already overbids this list). It > might be maybe good to have the SuSv3 optional cancellations covered by a > config option. > One more thought about cancellation: > there are 2 ways to go (after moving cancellation into libc): > a. go per default with using the non-cancellable functions within libc (this > way you have to care only for the cancellable functions, but not the rest and > fix some of them that are special, like system,daemon... to behave correctly) > b. use the cancellable functions within libc (and that care, that you do not > introduce cancellability into places where you definitely do want it) > My preference is a. (glibc went b.) (if it matters) > This is an interesting points, honestly never fully addressed into nptl branch. This is the right time to do... and I'm glad that you have reopened the debates on this... I reached the goal to have peoples again actively involved ;-) >> I've also a list of suggestions from Peter Mazinger on how to wrap >> cancellation handling commonly in NPTL and linuxthreads (yes Peter, >> I did not forget ;-) ) > > ;-) > >> The current status of the nptl branch is: >> >> - sh4: working again tested with >> - uclibc testsuite >> - LTP (running a 2.6.23.17 kernel from STLinux distribution) >> >> - arm: as you have told us, some issues using sysv hash >> but working with gnu hash (it needs investigation, but it seems >> to me not related to code merge) >> >> - mips: unknown to me. Maybe I brake while merging, even if I did >> not touch any arch specific part > > mips is broken anyway (signal handling) > >> From my side (I mean my uclibc work at ST) I'll release a stable >> 0.9.30-nptl >> based on current nptl branch early next year, but I'll not keep on merging >> trunk2branch stuff. >> I volunteer my self for starting the opposite: branch2trunk merge now. > > nptl-db can be imported as it is, but nptl uses to much duplicates within > libpthread, unnecessarily making it bigger than needed (all the reused > syscalls and much of the assembler code), this part should be better reviewed > to use code from libc as much as possible > I agree. I'd exclude them in the first import. > If you add the generic TLS code to ld.so/libdl/libc (futex is not needed), I > can provide a patch for LT (new), that will work with it (or Bernhard can do > it as well...) > yes, TLS impacts basically only ld.so, futexes (as used in nptl branch) are only used into libc for IO locking. welcome patch n linuxthreads. > Peter Thanks so much for your comments. Carmelo _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
