From 95878586ec7611791f4001a4ee17abf943fae3c1 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/g3Ccalpj0NhN566pHbUl6i9QF0QEkrhlfPM-#b1c14" Date: Mon, 16 Feb 2015 20:08:03 +0100 Subject: rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn --- 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 deletions(-) delete mode 100644 open_issues/glibc/debian.mdwn delete mode 100644 open_issues/glibc/debian/experimental.mdwn delete mode 100644 open_issues/glibc/mremap.mdwn delete mode 100644 open_issues/glibc/octave.mdwn delete mode 100644 open_issues/glibc/t/tls-threadvar.mdwn delete 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 deleted file mode 100644 index 2ef2c474..00000000 --- a/open_issues/glibc/debian.mdwn +++ /dev/null @@ -1,168 +0,0 @@ -[[!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 deleted file mode 100644 index 4ae9807b..00000000 --- a/open_issues/glibc/debian/experimental.mdwn +++ /dev/null @@ -1,338 +0,0 @@ -[[!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 deleted file mode 100644 index c17506d7..00000000 --- a/open_issues/glibc/mremap.mdwn +++ /dev/null @@ -1,70 +0,0 @@ -[[!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 deleted file mode 100644 index b12b7558..00000000 --- a/open_issues/glibc/octave.mdwn +++ /dev/null @@ -1,35 +0,0 @@ -[[!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 deleted file mode 100644 index 40d1463e..00000000 --- a/open_issues/glibc/t/tls-threadvar.mdwn +++ /dev/null @@ -1,155 +0,0 @@ -[[!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 deleted file mode 100644 index b10703fd..00000000 --- a/open_issues/glibc/t/tls.mdwn +++ /dev/null @@ -1,81 +0,0 @@ -[[!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.2.3