From 49a086299e047b18280457b654790ef4a2e5abfa Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Wed, 18 Feb 2015 00:58:35 +0100 Subject: Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn" This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1. --- open_issues/glibc/debian.mdwn | 168 ++++++++++++++ open_issues/glibc/debian/experimental.mdwn | 338 +++++++++++++++++++++++++++++ open_issues/glibc/mremap.mdwn | 70 ++++++ open_issues/glibc/octave.mdwn | 35 +++ open_issues/glibc/t/tls-threadvar.mdwn | 155 +++++++++++++ open_issues/glibc/t/tls.mdwn | 81 +++++++ 6 files changed, 847 insertions(+) create mode 100644 open_issues/glibc/debian.mdwn create mode 100644 open_issues/glibc/debian/experimental.mdwn create mode 100644 open_issues/glibc/mremap.mdwn create mode 100644 open_issues/glibc/octave.mdwn create mode 100644 open_issues/glibc/t/tls-threadvar.mdwn create mode 100644 open_issues/glibc/t/tls.mdwn (limited to 'open_issues/glibc') diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn new file mode 100644 index 00000000..2ef2c474 --- /dev/null +++ b/open_issues/glibc/debian.mdwn @@ -0,0 +1,168 @@ +[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + +# Open Issues + +`threads = yes` is set in `debian/sysdeps/linux.mk` and +`debian/sysdeps/kfreebsd.mk`, `debian/sysdeps/hurd.mk` set to `no`. But this +is only read in `debian/rules` for deciding some `nscd` package issue? + +`debian/sysdeps/hurd.mk`'s `libc_extra_install` for `ld.so`: check with GCC +configuration. + +Could add a toggle to `$(stamp)build_%` in `debian/rules.d/build.mk` to skip +locale stuff. + +`--disable-compatible-utmp`? + + +## IRC, freenode, #hurd, 2013-08-28 + + uh, the i686 profiles have much more progression than i386 + it seems they don't actually run these + youpi: what do you mean with "we don't run those"? + iirc there are three build profiles done, but there are 4 + regression test files + yes, but some failing tests are not run in the three build profiles + even if they are built for all of them + not even run? which ones? + see for instance test-ifloat.out + test-ifloat is built in all profiles, but only run in the libc one + don't have a glibc built tree around atm, sorry :/ + perhaps because glibc thinks it's not useful to run it again if it + fails on i386 + you can check the logs + do you think glibc's build system is that smart? :) + all the builds are done in separate builddirs, so theorically + they should not touch each other... + yes + that's why I'm surprised + could it be they get not run in optimized/particular builds? + what about linux/kfreebsd i386? + I don't see what makes them not run + or at least be treated particularly by th eMakefile + not run on kfreebsd either + pinotree: also, most of the tests now working have been marked as + failing by your patches for 2.17, would it be possible to retry them on + the box you used at that time? + that's the vm on my machine + which kind of vm? + kvm? + y + they are working here + with kvm + + +# Building + +Run `debian/rules patch` to apply patches (instead of having it done during the +build). Then you can edit files manually. + +Several passes: `libc`, `i686`, `xen`; `EGLIBC_PASSES='libc i686'`, etc. + +If building with `EGLIBC_PASSES=libc` (more specifically, without `xen`), the +`libc0.3-dev_extra_pkg_install` rule in `debian/sysdeps/hurd-i386.mk` will +fail. (Same for `libc6-dev_extra_pkg_install` in `debian/sysdeps/i386.mk`, for +example.) Why is this special handling only done for `xen`, but not for +`i686`? + +> Samuel: Historically because it's done that way in linux-i386. I don't know +> the real reason. + +Do `export LC_ALL=C` before building, otherwise the testsuite/make error +messages will be different from those stored in the +`debian/testsuite-checking/expected-results-*` files, resulting in a spurious +build failure. + +Run `debian/rules build-arch DEB_BUILD_OPTIONS=parallel=2 [EGLIBC_PASSES=...]` +to build (or `build` instead of `build-arch` to build the arch-independent +stuff, too). Can interrupt with `C-c` during locale stuff or testsuite if only +interested in the build tree. + +Run `fakeroot debian/rules binary DEB_BUILD_OPTIONS=parallel=2 +[EGLIBC_PASSES=...]` to build Debian packages or `binary-arch` for just the +architecture-dependent ones. + +The latter two steps can also be combined as `dpkg-buildpackage -R'debian/rules +EGLIBC_PASSES=libc' -nc -b -uc`. `-nc` will prevent the *clean step* which +would first try to un-patch, which may conflict if you have done any edits +apter applying patches. + +If the Debian symbol versioning file is not up to date and the build of Debian +packages fails due to this, putting `DPKG_GENSYMBOLS_CHECK_LEVEL=0` in the +environment \`\`helps''; see `man dpkg-gensymbols`. + + +# IRC, freenode, #hurd, 2013-07-01 + + something seems to have changed with regard to patch handling in + eglibc 2.17 + pinotree: when i add a patch to series and use dpkg-buildpackage, + i'm told there are local modifications and the build stops :/ + any idea what i'm doing wrong ? + which steps do you do? + i extract the sources, copy the patch to debian/patches/hurd-i386, + add the appropriate line to debian/patches/series, call dch -i, then + dpkg-buildpackage + eglibc is a "3.0 (quilt)" format source package + this means its default patches are in a quilt-style system, and + they are applied on extraction + ok + and it can't detect new patches ? + so if you add a new patch to the global serie, you have to push + it manually + i have to revert them all ? + ok + how do i do that ? + quilt push -a + ok + thanks + remember to do that before starting the build, since the rest + assumes the quilt-style patches are fully applied + No push applies them, quilt pop -a reverts them + yeah, and he has to push the new over the dpkg-applied ones + Oh, aye + does quilt change series ? + no + ok + i mean, some commands do that + so i do everything i did, with an additional push, right ? + ok, screw me, i didn't get your question above :P + does that change your answer ? + does quilt change series ? + yes + if you import or create a new patch, it changes series indeed + ok + push or pop of patches does not + i'm doing it wron + g + btw, in a quilt patch stack you can easily import a new patch + using the import command + so for example you could do + apt-get source eglibc # or get it somehow else + cd eglibc-* + quilt import /location/of/my/patch + quilt push # now your patch is applied + ah thanks + dpkg-buildpackage as usual + that's what i was looking for + quilt new adds a new entry in series + y + or import, aye + braunr: if you want to learn quilt, a very good doc is its own, + eg /usr/share/doc/quilt/quilt.txt.gz + * bddebian has never actually used import + ok + it is basically a simple stack of patches + + braunr: yes, patch handling is a bit different + the arch-independant patches are applied by dpkg-source -x + and the arch-dependent patches are applied during build diff --git a/open_issues/glibc/debian/experimental.mdwn b/open_issues/glibc/debian/experimental.mdwn new file mode 100644 index 00000000..4ae9807b --- /dev/null +++ b/open_issues/glibc/debian/experimental.mdwn @@ -0,0 +1,338 @@ +[[!meta copyright="Copyright © 2013, 2014 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +Issues with the current 2.17 version of glibc/EGLIBC in Debian experimental. +Now in unstable. + + +# IRC, OFTC, #debian-hurd, 2013-03-14 + + I have a strange tcp via localhost question: + The other side closes the connection, but I haven't read + all data, yet. I should still be able to read the pending data, no? + At least it seems to work that way on Linux, but not on + Hurd. + Got a simple repro with nc, if you're interested... + markus_wanner: yes, we're interested + youpi: okay, here we go: + session 1: nc -l -p 7777 localhost + session 2: nc 127.0.0.1 7777 + session 2: a b c + session 1: [ pause with Ctrl-Z ] + session 2: [ send more data ] d e f + session 2: [ quit with Ctrl-C ] + session 1: [ resume with 'fg' ] + The server on session 1 doesn't get the data sent after it + paused and before the client closed the connection. + I'm not sure if that's a valid TCP thing. However, on + Linux, the server still gets the data. On hurd it doesn't. + I'm working on a C-code test case, ATM. + markus_wanner: on which box are you seeing this behavior? + exodar does not have it + i.e. I do get the d e f + a private VM (I'm not a DD) + ..updated to latest experimental stuff. + GNU lematur 0.3 GNU-Mach 1.3.99-486/Hurd-0.3 i686-AT386 GNU + ok, I can't reproduce it on my vm either + maybe the C program will help + Hm.. cannot corrently reproduce that in C. (Netcat still + shows the issue, though). + I'll try to strace netcat... + ..Meh. strace not available on Hurd? + no, but there is rpctrace to show the various rpc + Cool, looks helpful. + Thx + Uh.. that introduces another error: + rpctrace: ../../utils/rpctrace.c:1287: trace_and_forward: + Assertion `reply_type == 18' failed. + +[[hurd/debugging/rpctrace]]. + + I'm checking on a box without ipv6 configuration + maybe that's the difference between you and me + I guess your /etc/alternatives/nc is /bin/nc.traditional ? + Yup, nc.traditional. + Looks like that box only has IPv4 configured. + Something very strange is going on here. No matter how hard + I try, I cannot reproduce this with netcat, anymore. + not even after a reboot? + Woo.. here, it happened, again! This is driving me crazy! + Now, nc seemingly connects, but is unable to send data + between the two. Netcat would somehow complain, if it failed to connect, + no? + No it worked. + So this seems to be an intermittent issue. So far, I could + only ever repro it as a normal user, not as root. May be coincidental, + though. + Now, 'a' and 'b' made it through, but not the 'c' sent + manually just after that. Something with that TCP/IP stack is definitely + fishy. + Anything I can try to investigate? Or shall I simply + restart and see if the problem persists? + maybe restart, yes + did you restart since the upgrade ? + Yes, I restarted after that. + Hm.. okay, restarted. Some problem persists. + I currently have two netcat processes connected, the + listening one got some first two messages and seems stuck now. + With the client, I tried to send more data, but the server + doesn't get it, anymore. + Any idea on what I can do to analyze the situation? + for the netcat issue, I haven't experienced this + are you running in kvm or virtualbox or something else? + I'm currently puzzled about what "experimental" actually + ships. + On kvm. + My libc0.3 used to be 2.13-39+hurd.3. + But packages.d.o already shows 2.17.0experimental2. + experimental ships experimental versions, which you aren't supposed + to use + unless you know what you are doing + iirc 2.17 is known to be quite broken for now + Okay. So I guess I'll try to "downgrade" to unstable, then. + Phew, okay, successfully downgraded to unstable. + Hopefully monotone's test suite runs through fine, now. + Yup, WORKING! Looks like some experimental packages caused + the problem. The netcat test as well as that one failing monotone test + work fine, now. + + +## IRC, OFTC, #debian-hurd, 2013-03-19 + + pinotree, youpi: Is there anything from that markus_wanner + discussion about pfinet/netcat/signals that needs to be filed? I guess + we don't know what exactly he changed so that everything workedd fine + eventually? (Some experimental package(s), but which?) + that was libc0.3 packages + which are indeed known to break the network + + +# IRC, freenode, #hurd, 2013-06-18 + + root@darnassus:~# dpkg-reconfigure locales + Generating locales (this might take a + while)... en_US.UTF-8...Segmentation fault + is it known ? + uh, no + + +## IRC, OFTC, #debian-hurd, 2013-06-19 + + btw i saw too the segmentation fault when generating locales + + +## IRC, freenode, #hurd, 2014-02-04 + + hello + I just updated + Setting up locales (2.17-98~0) ... + Generating locales (this might take a while)... + en_US.UTF-8...Segmentation fault + done + bu^: That's known, it still seems to work, though. If you have + the time please debug. I've tried but not found the solution yet:-( + ok, just wanted to notify + + +## IRC, freenode, #hurd, 2014-02-19 + + for info, the localedef segfault has been fixed upstream + or rather, upstream has been written in a way that won't trigger + the segfault + it is caused by the locale archive code that maps the locale + archive file in the address space, enlarging the mapping as needed, but + unmaps the complete reserved size of 512M on close + munmap is implemented through vm_deallocate, but it looks like the + latter doesn't allow deallocating unmapped regions of the address space + (to be confirmed) + upstream code tracks the mapping size so vm_deallocate won't whine + i expect we'll have that in eglibc 2.18 + hm actually, posix says munmap must refer to memory obtained with + mmap :) + (or actually, that the behaviour is undefined, which most unix + systems allow anyway, but not us) + + also, before i leave, i have partially traced the localedef + segfault + ah, cool + localedef maps the locale archive, and enlarges the mapping as + needed + but munmaps the complete 512m reserved area + and i strongly suspect it unmaps something it shouldn't on the + hurd + since linux mmap has different boundaries depending on the mapping + use + while our glibc will happily maps stacks below text + the good news is that it looks fixed upstream + ah :) + + https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=17db6e8d6b12f55e312fcab46faf5d332c806fb6 + see the change about close_archive + i haven't tested it though + + +## IRC, freenode, #hurd, 2014-02-21 + + just upgraded to 2.18, locales still segfaults + ok + + +## IRC, freenode, #hurd, 2014-02-23 + + ok, as expected, the localdef bug is because of some mmap issue + +[[glibc/mmap]]. + + looks like our mmap doesn't like mapping files with PROT_NONE + shouldn't be too hard to fix + gg0: i should have a fix ready soon for localedef + + youpi: i have a patch for glibc about the localedef segfault + is that the backport we talked about, or something else? + something else + in short + mmap() PROT_NONE on files return 0 + ok + seems like fixable indeed + nothing is mapped, and the localdef code doesn't consider this an + error + my current fix is to handle PROT_NONE like PROT_READ + doesn't vm_protect allow to map something without giving read + right? + it probably does + the problem is in glibc + ok + when i say like PROT_READ, i mean a memory object gets a reference + on the read port returned by io_map + since it's not accessible anyway, it shouldn't make a difference + but i preferred to have the memory object referenced anyway to + match what i expect is done by other systems + + +## IRC, freenode, #hurd, 2014-02-24 + + braunr: ah ok + + ok that mmap fix looks fine, i'll add comments and commit it soon + + +## IRC, freenode, #hurd, 2014-03-03 + + braunr: did you test whether + https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=17db6e8d6b12f55e312fcab46faf5d332c806fb6 + does indeed fix locale generation? + youpi: it doesn't, which is why i applied + http://git.sceen.net/hurd/glibc.git/commitdiff/da2d6e677ade278bf34afaa35c6ed4ff2489e7d8?hp=9a079e270a9bec7e1fe28aeda63e07c1bb808d44 + + +# IRC, OFTC, #debian-hurd, 2013-06-20 + + damn + hang at ext2fs boot + static linking issue, clearly + + +## IRC, freenode, #hurd, 2013-06-30 + + Mmm + __access ("/etc/ld.so.nohwcap", F_OK) at startup of ext2fs + deemed to fail.... + when does that happen? + at hwcap initialization + at least that's were ext2fs.static linked against libc 2.17 hangs + at startup + and this is indeed a very good culprit :) + ah, a debian patch + does anybody know a quick way to know whether one is the / ext2fs ? + :) + isn't the root fs given a special port? + I was thinking about something like this, yes + ok, boots + I'll build a 8~0 that includes the fix + so people can easily build the hurd package + Mmm, no, the bootstrap port is also NULL for normally-started + processes :/ + I don't understand why + ah, only translators get a bootstrap port :/ + perhaps CRDIR then + (which makes a lot of sense) + + +## IRC, freenode, #hurd, 2013-07-01 + + youpi: what is local-no-bootstrap-fs-access.diff supposed to fix ? + ext2fs.static linked againt debian glibc 2.17 + well, as long as you don't build & use ext2fs.static with it... + that's thing, i want to :) + +the + I'd warmly welcome a way to detect whether being the / translator + process btw + it seems far from trivial + + +# glibc 2.18 vs. GCC 4.8 + +## IRC, freenode, #hurd, 2013-11-25 + + grmbl, installing a glibc 2.18 rebuilt with gcc-4.8 brings an + unbootable system + + +## IRC, freenode, #hurd, 2013-11-29 + + so, what do I do? rebuild the glibc 2.18 package with gcc4.8 and + see what breaks ? + when I boot a system with that libc that is ? + I wish youpi would have been more specific, I've never built the + libc before... + debian/rules build in the debian package + ctrl-c when you see gcc invocations + cd buildir; make lib others + although hm + what breaks is at boot time right ? + yes + heh .. + then dpkg-buildpackage + DEB_BUILD_OPTIONS=nocheck speeds things up + just answer on the mailing list and ask him + he usually answers quickly + + +## IRC, freenode, #hurd, 2013-12-18 + + teythoon: k!, any luck with eglibc-2.18? + tbh i didn't look into this after two unsuccessful attempts at + building the libc package + there was a post over at the libc-alpha list that sounded + familiar + http://www.cygwin.com/ml/libc-alpha/2013-12/msg00281.html + wow + ? + this looks tricky + and why ia64 only + indeed + it's rare to see aurel32 ask such questions + + +## IRC, freenode, #hurd, 2014-01-22 + + btw, did anybody investigate the glibc-built-with-gcc-4.8 issue? + oddly enough, a subhurd boots completely fine with it + i didn't + no, sorry + I was wondering whether the bogus deallocation at boot might have + something to do + which one ? + ah + yes + maybe + quoted earlier here diff --git a/open_issues/glibc/mremap.mdwn b/open_issues/glibc/mremap.mdwn new file mode 100644 index 00000000..c17506d7 --- /dev/null +++ b/open_issues/glibc/mremap.mdwn @@ -0,0 +1,70 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +The Hurd does not currently support the `mremap` function. + +For the `MREMAP_MAYMOVE` case it is easy to work around; see +`[binutils]/gold/mremap.c`, for example. + +Also see the discussion of [[glibc/mmap]]. + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-01-12 + + maybe it would be easiest actually to implement mremap()?... + antrik: i'm nto sure + antrik: implementing mremap could be relatively easy to do + actually + antrik: IIRC, vm_map() supports overlapping + braunr: yes, I think so too + braunr: haven't checked, but I have a vague recollection that the + fundamentals are pretty much there + +[[!taglink open_issue_glibc]]: check if it is possible to implement `mremap`. +[[I|tschwinge]] remember some discussion about this, but have not yet worked on +locating it. [[Talk to me|tschwinge]] if you'd like to have a look at this. + + +# IRC, OFTC, #debian-hurd, 2012-06-19 + + OK, how the heck do you get an undefined reference to mremap? + simply because we don't have it + mremap exists only on linux + It's in sys/mman.h + on linux? + No, on GNU/Hurd + /usr/include/i386-gnu/sys/mman.h + that's just the common file with linux + containing just the prototype + that doesn't mean there's an implementation behind + youpi: hm no, linux has an own version + uh + Ah, aye, I didn't look at the implementation.. :( + it's then odd that it was added to the generic sys/mman.h :) + Just another stub? + ah, only few linux archs have own versions + for the macro values I guess + http://paste.debian.net/175173/ on glibc/master + Hmm, so where is MREMAP_MAYMOVE coming in from? + rgrep on a linux box ;) + + but that's again linuxish + Aye but with us having that in the header it is causing some + code to be run which utilizes mremap. If that wasn't defined we wouldn't + be calling it. + ah + we could try to remove it indeed + Should I change the code to #ifdef MREMAP_MAYMOVE & !defined + __GNU__? + no, I said we could remove the definition of MREMAP_MAYMOVE itself diff --git a/open_issues/glibc/octave.mdwn b/open_issues/glibc/octave.mdwn new file mode 100644 index 00000000..b12b7558 --- /dev/null +++ b/open_issues/glibc/octave.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + + +# IRC, OFTC, #debian-hurd, 2012-04-23 + + diffing the octave i386 vs hurd-i386 build logs gives + interesting surprises + checking whether this system has an arbitrary file name length + limit... no | checking whether this system has an arbitrary + file name length limit... yes + ? + not only that + checking whether getcwd handles long file names properly... yes + | checking whether getcwd handles long file names properly... no, but it + is partly worki+ + ? + -checking whether fdopendir works... yes + +checking whether fdopendir works... no + (- is i386, + is hurd-i386) + -checking whether getlogin_r works with small buffers... yes + +checking whether getlogin_r works with small buffers... no + -checking for working mkstemp... yes + +checking for working mkstemp... no + +checking for working nanosleep... no (mishandles large + arguments) diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn new file mode 100644 index 00000000..40d1463e --- /dev/null +++ b/open_issues/glibc/t/tls-threadvar.mdwn @@ -0,0 +1,155 @@ +[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_libpthread]] + +This basically means to get rid of `sysdeps/mach/hurd/bits/libc-tsd.h` (and +thus the `_HURD_THREADVAR_*`/`_hurd_threadvar_location` interface), and +directly use `__thread` instead. + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-10-23 + + youpi: If we want to replace threadvars with TLS, there is one + problem: the threadvars interface is publically exported: + /usr/include/hurd/threadvar.h. + youpi: But I am somewhat inclined to say that the only user of + this is libthreads/libpthread. Do you think differently? + tschwinge: that's very probable + so I think we can just drop it + (people should use TLS anyway) + +[[libpthread_set_stack_size]]. + +After this has been done, probably the whole `__libc_tsd_*` stuff can be +dropped altogether, and `__thread` directly be used in glibc. + + +# IRC, freenode, #hurd, 2012-08-07 + + r5219: Update libpthread patch to replace threadvar with tls + for pthread_self + r5224: revert r5219 too, it's not ready either + as the changelog says, the __thread revertal is because it posed + problems + and I just didn't have any time to check them while the freeze was + so close + OK. What kind of problems? Should it be reverted upstream, + too? + I don't remember exactly + it should just be fixed + we can revert it upstream, but it'd be good that we manage to + progress, at some point... + Of course -- however as long as we don't know what kind of + problem, it is a bit difficult. ;-) + since I didn't left a note, it was most probably a mere glibc run, + or boot with the patched libpthread + *testsuite run + OK. + The libpthread testsuite doesn't show any issues with that + patch applied, though. But I didn'T test anything else. + youpi: Also, you have probably seen my glibc __thread errno + email -- rmcgrath wanted to find some time this week to comment/help, and + I take it you don't have any immediate comments to that issue? + I saw the mails, but didn't investigate at all + +[[!message-id "878vdyqht3.fsf@kepler.schwinge.homeip.net"]]. + + +# IRC, freenode, #hurd, 2013-07-08 + + tschwinge: apparently there were a lot of changes missing in the + threadvars branch I had commited long time ago + I'm gathering things + youpi: t/tls-threadvar you mean? + yes + tschwinge: yes, there were a lot other occurences of threadvars + stuff in various places + I'm building libc again, and will see what issue would remain + + +## IRC, freenode, #hurd, 2013-07-12 + + braunr: about the per-thread ports, there is also the mig reply + port + (stored in _HURD_THREADVAR_MIG_REPLY) + + +## IRC, freenode, #hurd, 2013-07-15 + + and with the branch youpi pushed where he removes threadvars, it + shouldn't get "too" hard + (save for the tricky bugs you may encounter) + well, that branch is not working yet + + +## IRC, OFTC, #debian-hurd, 2013-09-22 + + I'm currently tracking bugs with my threadvars changes + some of them seem fine, others, not + of course the most complex ones are the most probable culprits for + the issues I'm getting + fortunately they're after the process bootstrap + so basically that works + just a few dozen tests fail + mostly about loading .so or raising signals + dlopen("bug-dlsym1-lib1.so"): bug-dlsym1-lib1.so: cannot open + shared object file: Function not implemented + after having changed errno a bit + doesn't that look odd ? :) + good, I found an issue with the sigstate + now running testsuite again, to see whether there are other issues + with it :) + s/sigstate/reply_port/ actually + + +## IRC, OFTC, #debian-hurd, 2013-09-23 + + yay, errno threadvar conversion success + + +## IRC, OFTC, #debian-hurd, 2013-10-05 + + youpi: any ETA for tls? + gg0_: one can't have an ETA for bugfixing + i don't call them bugs if there's something missing to implement btw + no, here it's bugs + the implementation is already in the glibc branches in our + repository + it just makes some important regressions + + +## IRC, OFTC, #debian-hurd, 2013-10-07 + + about tls, I've made some "progress": now I'm wondering how raise() + has ever been working before :) + + +## IRC, OFTC, #debian-hurd, 2013-10-15 + + good, reply_port tls is now ok + last but not least, sigstate + + +## IRC, OFTC, #debian-hurd, 2013-10-21 + + started testsuite with threadvars dropped completely + so far so good + + +## IRC, OFTC, #debian-hurd, 2013-10-24 + + ok, hurd boots with full-tls libc, no threadvars at all any more + \o/ + good bye threadvars bugs, welcome tls ones ;) + now I need to check that threads can really use another stack :) diff --git a/open_issues/glibc/t/tls.mdwn b/open_issues/glibc/t/tls.mdwn new file mode 100644 index 00000000..b10703fd --- /dev/null +++ b/open_issues/glibc/t/tls.mdwn @@ -0,0 +1,81 @@ +[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_libpthread]] + +# To Do + + * Discuss d2431f633e6139a62e1575ec18830f7e81160cf0 with Samuel. + + * Validate our implementation against + . + + +# Documentation + +[[!taglink open_issue_documentation]] + + * IRC, freenode, #hurd, 2011-11-26 + + In glibc multiarch support (strcasecmp for i686 SSE3, etc.) + there is access to memory via gs: -- this will need to be changed for + us, right? + depends on the access + * `optimized strcasecmp and strncasecmp for x86-32` + (multiarch), + 76e3966e9efc3808a9e7ad09121c5dfc1211c20b + + 6abf346582ba678f4850a88b4a5950593841df1d + + 5583a0862cf94f71cbcde91c4043a20af65facca. `gs` + access. + + movl __libc_tsd_LOCALE@GOTNTPOFF(%ebx), %eax + that's handled by the linker fine + it's only the things held in the tcb_t structure which can pose + problem + tcbhead_t? + I'm looking at this. + So, at gs:0, there is the TCB. + And we have the same layout as NPTL/Linux, just that we + don't have as much data there as they have. + We're missing multiple_threads, sysinfo, sttack_guard, + pointer_guard, gscope_flag, private_futex, __private_tm[5]. + So, if one of these is referenced (be it my name or by + numeric offset), this is invalid for us. + Anything else should work equivalently. + yes + usually the only numeric offset being used is 0 + so it would simply not build + And the other offsers are generated via tcb-offsets.sym. + glibc's elf/stackguard-macros.h is wrong for us (but not + used anywhere apart from elf/tst-stackguard1.c, I think). + +After commit a9538892adfbb9f092e0bb14ff3a1703973968af, it's +`sysdeps/i386/stackguard-macros.h`; problem remains. + + __thread __locale_t __libc_tsd_LOCALE = &_nl_global_locale; + -- this means that a __libc_tsd_LOCALE values will be in the TLS + segment, and this is what is being accessed from the assembler code + with %gs:__libc_tsd_LOCALE@NTPOFF, and the linker will resolve this. + yes + see in the nm output, the libc_tsd symbols + these provide the offsets + youpi: Thank you, I'm now understanding this part of TLS + much better. + have you had a look at the tls.pdf from Uli ? + all the gory details are there :) + +Commit c61b4d41c9647a54a329aa021341c0eb032b793e, [[!sourceware_PR 15754]], adds +`sysdeps/i386/stackguard-macros.h:POINTER_CHK_GUARD`, which is not correct for +us (at the moment), but it also shouldn't cause any harm, as this file is only +used in `elf/tst-ptrguard1.c` and `elf/tst-stackguard1.c`, which now will fail +to build for us, as we don't have a `pointer_guard` member in +`sysdeps/mach/hurd/tls.h:tcbhead_t`. + +We don't define `THREAD_SET_POINTER_GUARD`. -- cgit v1.3.1