diff options
Diffstat (limited to 'service_solahart_jakarta_selatan__082122541663/glibc')
6 files changed, 0 insertions, 847 deletions
diff --git a/service_solahart_jakarta_selatan__082122541663/glibc/debian.mdwn b/service_solahart_jakarta_selatan__082122541663/glibc/debian.mdwn deleted file mode 100644 index 2ef2c474..00000000 --- a/service_solahart_jakarta_selatan__082122541663/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 - - <youpi> uh, the i686 profiles have much more progression than i386 - <youpi> it seems they don't actually run these - <pinotree> youpi: what do you mean with "we don't run those"? - <pinotree> iirc there are three build profiles done, but there are 4 - regression test files - <youpi> yes, but some failing tests are not run in the three build profiles - <youpi> even if they are built for all of them - <pinotree> not even run? which ones? - <youpi> see for instance test-ifloat.out - <youpi> test-ifloat is built in all profiles, but only run in the libc one - <pinotree> don't have a glibc built tree around atm, sorry :/ - <youpi> perhaps because glibc thinks it's not useful to run it again if it - fails on i386 - <youpi> you can check the logs - <pinotree> do you think glibc's build system is that smart? :) - <pinotree> all the builds are done in separate builddirs, so theorically - they should not touch each other... - <youpi> yes - <youpi> that's why I'm surprised - <pinotree> could it be they get not run in optimized/particular builds? - <pinotree> what about linux/kfreebsd i386? - <youpi> I don't see what makes them not run - <youpi> or at least be treated particularly by th eMakefile - <youpi> not run on kfreebsd either - <youpi> 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? - <pinotree> that's the vm on my machine - <youpi> which kind of vm? - <youpi> kvm? - <pinotree> y - <youpi> they are working here - <youpi> 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 - - <braunr> something seems to have changed with regard to patch handling in - eglibc 2.17 - <braunr> pinotree: when i add a patch to series and use dpkg-buildpackage, - i'm told there are local modifications and the build stops :/ - <braunr> any idea what i'm doing wrong ? - <pinotree> which steps do you do? - <braunr> 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 - <pinotree> eglibc is a "3.0 (quilt)" format source package - <pinotree> this means its default patches are in a quilt-style system, and - they are applied on extraction - <braunr> ok - <braunr> and it can't detect new patches ? - <pinotree> so if you add a new patch to the global serie, you have to push - it manually - <braunr> i have to revert them all ? - <braunr> ok - <braunr> how do i do that ? - <pinotree> quilt push -a - <braunr> ok - <braunr> thanks - <pinotree> remember to do that before starting the build, since the rest - assumes the quilt-style patches are fully applied - <bddebian> No push applies them, quilt pop -a reverts them - <pinotree> yeah, and he has to push the new over the dpkg-applied ones - <bddebian> Oh, aye - <braunr> does quilt change series ? - <pinotree> no - <braunr> ok - <pinotree> i mean, some commands do that - <braunr> so i do everything i did, with an additional push, right ? - <pinotree> ok, screw me, i didn't get your question above :P - <braunr> does that change your answer ? - <pinotree> <braunr> does quilt change series ? - <braunr> yes - <pinotree> if you import or create a new patch, it changes series indeed - <braunr> ok - <pinotree> push or pop of patches does not - <braunr> i'm doing it wron - <braunr> g - <pinotree> btw, in a quilt patch stack you can easily import a new patch - using the import command - <pinotree> so for example you could do - <pinotree> apt-get source eglibc # or get it somehow else - <pinotree> cd eglibc-* - <pinotree> quilt import /location/of/my/patch - <pinotree> quilt push # now your patch is applied - <braunr> ah thanks - <pinotree> dpkg-buildpackage as usual - <braunr> that's what i was looking for - <bddebian> quilt new adds a new entry in series - <pinotree> y - <bddebian> or import, aye - <pinotree> 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 - <braunr> ok - <pinotree> it is basically a simple stack of patches - - <youpi> braunr: yes, patch handling is a bit different - <youpi> the arch-independant patches are applied by dpkg-source -x - <youpi> and the arch-dependent patches are applied during build diff --git a/service_solahart_jakarta_selatan__082122541663/glibc/debian/experimental.mdwn b/service_solahart_jakarta_selatan__082122541663/glibc/debian/experimental.mdwn deleted file mode 100644 index 4ae9807b..00000000 --- a/service_solahart_jakarta_selatan__082122541663/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 - - <markus_w1nner> I have a strange tcp via localhost question: - <markus_wanner> 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? - <markus_wanner> At least it seems to work that way on Linux, but not on - Hurd. - <markus_wanner> Got a simple repro with nc, if you're interested... - <youpi> markus_wanner: yes, we're interested - <markus_wanner> youpi: okay, here we go: - <markus_wanner> session 1: nc -l -p 7777 localhost - <markus_wanner> session 2: nc 127.0.0.1 7777 - <markus_wanner> session 2: a <RET> b <RET> c <RET> - <markus_wanner> session 1: [ pause with Ctrl-Z ] - <markus_wanner> session 2: [ send more data ] d <RET> e <RET> f <RET> - <markus_wanner> session 2: [ quit with Ctrl-C ] - <markus_wanner> session 1: [ resume with 'fg' ] - <markus_wanner> The server on session 1 doesn't get the data sent after it - paused and before the client closed the connection. - <markus_wanner> 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. - <markus_wanner> I'm working on a C-code test case, ATM. - <youpi> markus_wanner: on which box are you seeing this behavior? - <youpi> exodar does not have it - <youpi> i.e. I do get the d e f - <markus_wanner> a private VM (I'm not a DD) - <markus_wanner> ..updated to latest experimental stuff. - <markus_wanner> GNU lematur 0.3 GNU-Mach 1.3.99-486/Hurd-0.3 i686-AT386 GNU - <youpi> ok, I can't reproduce it on my vm either - <youpi> maybe the C program will help - <markus_wanner> Hm.. cannot corrently reproduce that in C. (Netcat still - shows the issue, though). - <markus_wanner> I'll try to strace netcat... - <markus_wanner> ..Meh. strace not available on Hurd? - <pinotree> no, but there is rpctrace to show the various rpc - <markus_wanner> Cool, looks helpful. - <markus_wanner> Thx - <markus_wanner> Uh.. that introduces another error: - <markus_wanner> rpctrace: ../../utils/rpctrace.c:1287: trace_and_forward: - Assertion `reply_type == 18' failed. - -[[hurd/debugging/rpctrace]]. - - <youpi> I'm checking on a box without ipv6 configuration - <youpi> maybe that's the difference between you and me - <youpi> I guess your /etc/alternatives/nc is /bin/nc.traditional ? - <markus_wanner> Yup, nc.traditional. - <markus_wanner> Looks like that box only has IPv4 configured. - <markus_wanner> Something very strange is going on here. No matter how hard - I try, I cannot reproduce this with netcat, anymore. - <pinotree> not even after a reboot? - <markus_wanner> Woo.. here, it happened, again! This is driving me crazy! - <markus_wanner> Now, nc seemingly connects, but is unable to send data - between the two. Netcat would somehow complain, if it failed to connect, - no? - <markus_wanner> No it worked. - <markus_wanner> 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. - <markus_wanner> 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. - <markus_wanner> Anything I can try to investigate? Or shall I simply - restart and see if the problem persists? - <youpi> maybe restart, yes - <youpi> did you restart since the upgrade ? - <markus_wanner> Yes, I restarted after that. - <markus_wanner> Hm.. okay, restarted. Some problem persists. - <markus_wanner> I currently have two netcat processes connected, the - listening one got some first two messages and seems stuck now. - <markus_wanner> With the client, I tried to send more data, but the server - doesn't get it, anymore. - <markus_wanner> Any idea on what I can do to analyze the situation? - <youpi> for the netcat issue, I haven't experienced this - <youpi> are you running in kvm or virtualbox or something else? - <markus_wanner> I'm currently puzzled about what "experimental" actually - ships. - <markus_wanner> On kvm. - <markus_wanner> My libc0.3 used to be 2.13-39+hurd.3. - <markus_wanner> But packages.d.o already shows 2.17.0experimental2. - <youpi> experimental ships experimental versions, which you aren't supposed - to use - <youpi> unless you know what you are doing - <youpi> iirc 2.17 is known to be quite broken for now - <markus_wanner> Okay. So I guess I'll try to "downgrade" to unstable, then. - <markus_wanner> Phew, okay, successfully downgraded to unstable. - <markus_wanner> Hopefully monotone's test suite runs through fine, now. - <markus_wanner> 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 - - <tschwinge> 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?) - <youpi> that was libc0.3 packages - <youpi> which are indeed known to break the network - - -# IRC, freenode, #hurd, 2013-06-18 - - <braunr> root@darnassus:~# dpkg-reconfigure locales - <braunr> Generating locales (this might take a - while)... en_US.UTF-8...Segmentation fault - <braunr> is it known ? - <youpi> uh, no - - -## IRC, OFTC, #debian-hurd, 2013-06-19 - - <pinotree> btw i saw too the segmentation fault when generating locales - - -## IRC, freenode, #hurd, 2014-02-04 - - <bu^> hello - <bu^> I just updated - <bu^> Setting up locales (2.17-98~0) ... - <bu^> Generating locales (this might take a while)... - <bu^> en_US.UTF-8...Segmentation fault - <bu^> done - <gnu_srs> 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:-( - <bu^> ok, just wanted to notify - - -## IRC, freenode, #hurd, 2014-02-19 - - <braunr> for info, the localedef segfault has been fixed upstream - <braunr> or rather, upstream has been written in a way that won't trigger - the segfault - <braunr> 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 - <braunr> munmap is implemented through vm_deallocate, but it looks like the - latter doesn't allow deallocating unmapped regions of the address space - <braunr> (to be confirmed) - <braunr> upstream code tracks the mapping size so vm_deallocate won't whine - <braunr> i expect we'll have that in eglibc 2.18 - <braunr> hm actually, posix says munmap must refer to memory obtained with - mmap :) - <braunr> (or actually, that the behaviour is undefined, which most unix - systems allow anyway, but not us) - - <braunr> also, before i leave, i have partially traced the localedef - segfault - <youpi> ah, cool - <braunr> localedef maps the locale archive, and enlarges the mapping as - needed - <braunr> but munmaps the complete 512m reserved area - <braunr> and i strongly suspect it unmaps something it shouldn't on the - hurd - <braunr> since linux mmap has different boundaries depending on the mapping - use - <braunr> while our glibc will happily maps stacks below text - <braunr> the good news is that it looks fixed upstream - <youpi> ah :) - <braunr> - https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=17db6e8d6b12f55e312fcab46faf5d332c806fb6 - <braunr> see the change about close_archive - <braunr> i haven't tested it though - - -## IRC, freenode, #hurd, 2014-02-21 - - <gg0> just upgraded to 2.18, locales still segfaults - <braunr> ok - - -## IRC, freenode, #hurd, 2014-02-23 - - <braunr> ok, as expected, the localdef bug is because of some mmap issue - -[[glibc/mmap]]. - - <braunr> looks like our mmap doesn't like mapping files with PROT_NONE - <braunr> shouldn't be too hard to fix - <braunr> gg0: i should have a fix ready soon for localedef - - <braunr> youpi: i have a patch for glibc about the localedef segfault - <youpi> is that the backport we talked about, or something else? - <braunr> something else - <braunr> in short - <braunr> mmap() PROT_NONE on files return 0 - <youpi> ok - <youpi> seems like fixable indeed - <braunr> nothing is mapped, and the localdef code doesn't consider this an - error - <braunr> my current fix is to handle PROT_NONE like PROT_READ - <youpi> doesn't vm_protect allow to map something without giving read - right? - <braunr> it probably does - <braunr> the problem is in glibc - <youpi> ok - <braunr> when i say like PROT_READ, i mean a memory object gets a reference - <braunr> on the read port returned by io_map - <braunr> since it's not accessible anyway, it shouldn't make a difference - <braunr> 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 - - <youpi> braunr: ah ok - - <braunr> ok that mmap fix looks fine, i'll add comments and commit it soon - - -## IRC, freenode, #hurd, 2014-03-03 - - <youpi> braunr: did you test whether - https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=17db6e8d6b12f55e312fcab46faf5d332c806fb6 - does indeed fix locale generation? - <braunr> 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 - - <youpi> damn - <youpi> hang at ext2fs boot - <youpi> static linking issue, clearly - - -## IRC, freenode, #hurd, 2013-06-30 - - <youpi> Mmm - <youpi> __access ("/etc/ld.so.nohwcap", F_OK) at startup of ext2fs - <youpi> deemed to fail.... - <pinotree> when does that happen? - <youpi> at hwcap initialization - <youpi> at least that's were ext2fs.static linked against libc 2.17 hangs - at startup - <youpi> and this is indeed a very good culprit :) - <pinotree> ah, a debian patch - <youpi> does anybody know a quick way to know whether one is the / ext2fs ? - :) - <pinotree> isn't the root fs given a special port? - <youpi> I was thinking about something like this, yes - <youpi> ok, boots - <youpi> I'll build a 8~0 that includes the fix - <youpi> so people can easily build the hurd package - <youpi> Mmm, no, the bootstrap port is also NULL for normally-started - processes :/ - <youpi> I don't understand why - <youpi> ah, only translators get a bootstrap port :/ - <youpi> perhaps CRDIR then - <youpi> (which makes a lot of sense) - - -## IRC, freenode, #hurd, 2013-07-01 - - <braunr> youpi: what is local-no-bootstrap-fs-access.diff supposed to fix ? - <youpi> ext2fs.static linked againt debian glibc 2.17 - <youpi> well, as long as you don't build & use ext2fs.static with it... - <braunr> that's thing, i want to :) - <braunr> +the - <youpi> I'd warmly welcome a way to detect whether being the / translator - process btw - <youpi> it seems far from trivial - - -# glibc 2.18 vs. GCC 4.8 - -## IRC, freenode, #hurd, 2013-11-25 - - <youpi> grmbl, installing a glibc 2.18 rebuilt with gcc-4.8 brings an - unbootable system - - -## IRC, freenode, #hurd, 2013-11-29 - - <teythoon> so, what do I do? rebuild the glibc 2.18 package with gcc4.8 and - see what breaks ? - <teythoon> when I boot a system with that libc that is ? - <teythoon> I wish youpi would have been more specific, I've never built the - libc before... - <braunr> debian/rules build in the debian package - <braunr> ctrl-c when you see gcc invocations - <braunr> cd buildir; make lib others - <braunr> although hm - <braunr> what breaks is at boot time right ? - <teythoon> yes - <braunr> heh .. - <braunr> then dpkg-buildpackage - <braunr> DEB_BUILD_OPTIONS=nocheck speeds things up - <braunr> just answer on the mailing list and ask him - <braunr> he usually answers quickly - - -## IRC, freenode, #hurd, 2013-12-18 - - <gnu_srs> teythoon: k!, any luck with eglibc-2.18? - <teythoon> tbh i didn't look into this after two unsuccessful attempts at - building the libc package - <teythoon> there was a post over at the libc-alpha list that sounded - familiar - <teythoon> http://www.cygwin.com/ml/libc-alpha/2013-12/msg00281.html - <braunr> wow - <teythoon> ? - <braunr> this looks tricky - <braunr> and why ia64 only - <teythoon> indeed - <braunr> it's rare to see aurel32 ask such questions - - -## IRC, freenode, #hurd, 2014-01-22 - - <youpi> btw, did anybody investigate the glibc-built-with-gcc-4.8 issue? - <youpi> oddly enough, a subhurd boots completely fine with it - <braunr> i didn't - <teythoon> no, sorry - <youpi> I was wondering whether the bogus deallocation at boot might have - something to do - <braunr> which one ? - <braunr> ah - <braunr> yes - <braunr> maybe - <youpi> quoted earlier here diff --git a/service_solahart_jakarta_selatan__082122541663/glibc/mremap.mdwn b/service_solahart_jakarta_selatan__082122541663/glibc/mremap.mdwn deleted file mode 100644 index c17506d7..00000000 --- a/service_solahart_jakarta_selatan__082122541663/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 - - <antrik> maybe it would be easiest actually to implement mremap()?... - <braunr> antrik: i'm nto sure - <braunr> antrik: implementing mremap could be relatively easy to do - actually - <braunr> antrik: IIRC, vm_map() supports overlapping - <antrik> braunr: yes, I think so too - <antrik> 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 - - <bdefreese> OK, how the heck do you get an undefined reference to mremap? - <youpi> simply because we don't have it - <pinotree> mremap exists only on linux - <bdefreese> It's in sys/mman.h - <pinotree> on linux? - <bdefreese> No, on GNU/Hurd - <bdefreese> /usr/include/i386-gnu/sys/mman.h - <youpi> that's just the common file with linux - <youpi> containing just the prototype - <youpi> that doesn't mean there's an implementation behind - <pinotree> youpi: hm no, linux has an own version - <youpi> uh - <bdefreese> Ah, aye, I didn't look at the implementation.. :( - <youpi> it's then odd that it was added to the generic sys/mman.h :) - <bdefreese> Just another stub? - <pinotree> ah, only few linux archs have own versions - <youpi> for the macro values I guess - <pinotree> http://paste.debian.net/175173/ on glibc/master - <bdefreese> Hmm, so where is MREMAP_MAYMOVE coming in from? - <youpi> rgrep on a linux box ;) - <youpi> <bits/mman.h> - <youpi> but that's again linuxish - <bdefreese> 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. - <youpi> ah - <youpi> we could try to remove it indeed - <bdefreese> Should I change the code to #ifdef MREMAP_MAYMOVE & !defined - __GNU__? - <youpi> no, I said we could remove the definition of MREMAP_MAYMOVE itself diff --git a/service_solahart_jakarta_selatan__082122541663/glibc/octave.mdwn b/service_solahart_jakarta_selatan__082122541663/glibc/octave.mdwn deleted file mode 100644 index b12b7558..00000000 --- a/service_solahart_jakarta_selatan__082122541663/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 - - <pinotree> diffing the octave i386 vs hurd-i386 build logs gives - interesting surprises - <youpi> checking whether this system has an arbitrary file name length - limit... no | checking whether this system has an arbitrary - file name length limit... yes - <youpi> ? - <pinotree> not only that - <youpi> checking whether getcwd handles long file names properly... yes - | checking whether getcwd handles long file names properly... no, but it - is partly worki+ - <youpi> ? - <pinotree> -checking whether fdopendir works... yes - <pinotree> +checking whether fdopendir works... no - <pinotree> (- is i386, + is hurd-i386) - <pinotree> -checking whether getlogin_r works with small buffers... yes - <pinotree> +checking whether getlogin_r works with small buffers... no - <pinotree> -checking for working mkstemp... yes - <pinotree> +checking for working mkstemp... no - <pinotree> +checking for working nanosleep... no (mishandles large - arguments) diff --git a/service_solahart_jakarta_selatan__082122541663/glibc/t/tls-threadvar.mdwn b/service_solahart_jakarta_selatan__082122541663/glibc/t/tls-threadvar.mdwn deleted file mode 100644 index 40d1463e..00000000 --- a/service_solahart_jakarta_selatan__082122541663/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 - - <tschwinge> youpi: If we want to replace threadvars with TLS, there is one - problem: the threadvars interface is publically exported: - /usr/include/hurd/threadvar.h. - <tschwinge> youpi: But I am somewhat inclined to say that the only user of - this is libthreads/libpthread. Do you think differently? - <youpi> tschwinge: that's very probable - <youpi> so I think we can just drop it - <youpi> (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 - - <tschwinge> r5219: Update libpthread patch to replace threadvar with tls - for pthread_self - <tschwinge> r5224: revert r5219 too, it's not ready either - <youpi> as the changelog says, the __thread revertal is because it posed - problems - <youpi> and I just didn't have any time to check them while the freeze was - so close - <tschwinge> OK. What kind of problems? Should it be reverted upstream, - too? - <youpi> I don't remember exactly - <youpi> it should just be fixed - <youpi> we can revert it upstream, but it'd be good that we manage to - progress, at some point... - <tschwinge> Of course -- however as long as we don't know what kind of - problem, it is a bit difficult. ;-) - <youpi> since I didn't left a note, it was most probably a mere glibc run, - or boot with the patched libpthread - <youpi> *testsuite run - <tschwinge> OK. - <tschwinge> The libpthread testsuite doesn't show any issues with that - patch applied, though. But I didn'T test anything else. - <tschwinge> 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? - <youpi> I saw the mails, but didn't investigate at all - -[[!message-id "878vdyqht3.fsf@kepler.schwinge.homeip.net"]]. - - -# IRC, freenode, #hurd, 2013-07-08 - - <youpi> tschwinge: apparently there were a lot of changes missing in the - threadvars branch I had commited long time ago - <youpi> I'm gathering things - <tschwinge> youpi: t/tls-threadvar you mean? - <youpi> yes - <youpi> tschwinge: yes, there were a lot other occurences of threadvars - stuff in various places - <youpi> I'm building libc again, and will see what issue would remain - - -## IRC, freenode, #hurd, 2013-07-12 - - <youpi> braunr: about the per-thread ports, there is also the mig reply - port - <youpi> (stored in _HURD_THREADVAR_MIG_REPLY) - - -## IRC, freenode, #hurd, 2013-07-15 - - <braunr> and with the branch youpi pushed where he removes threadvars, it - shouldn't get "too" hard - <braunr> (save for the tricky bugs you may encounter) - <youpi> well, that branch is not working yet - - -## IRC, OFTC, #debian-hurd, 2013-09-22 - - <youpi> I'm currently tracking bugs with my threadvars changes - <youpi> some of them seem fine, others, not - <youpi> of course the most complex ones are the most probable culprits for - the issues I'm getting - <youpi> fortunately they're after the process bootstrap - <youpi> so basically that works - <youpi> just a few dozen tests fail - <youpi> mostly about loading .so or raising signals - <youpi> dlopen("bug-dlsym1-lib1.so"): bug-dlsym1-lib1.so: cannot open - shared object file: Function not implemented - <youpi> after having changed errno a bit - <youpi> doesn't that look odd ? :) - <youpi> good, I found an issue with the sigstate - <youpi> now running testsuite again, to see whether there are other issues - with it :) - <youpi> s/sigstate/reply_port/ actually - - -## IRC, OFTC, #debian-hurd, 2013-09-23 - - <youpi> yay, errno threadvar conversion success - - -## IRC, OFTC, #debian-hurd, 2013-10-05 - - <gg0_> youpi: any ETA for tls? - <youpi> gg0_: one can't have an ETA for bugfixing - <gg0_> i don't call them bugs if there's something missing to implement btw - <youpi> no, here it's bugs - <youpi> the implementation is already in the glibc branches in our - repository - <youpi> it just makes some important regressions - - -## IRC, OFTC, #debian-hurd, 2013-10-07 - - <youpi> 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 - - <youpi> good, reply_port tls is now ok - <youpi> last but not least, sigstate - - -## IRC, OFTC, #debian-hurd, 2013-10-21 - - <youpi> started testsuite with threadvars dropped completely - <youpi> so far so good - - -## IRC, OFTC, #debian-hurd, 2013-10-24 - - <youpi> ok, hurd boots with full-tls libc, no threadvars at all any more - <gg0> \o/ - <gg0> good bye threadvars bugs, welcome tls ones ;) - <youpi> now I need to check that threads can really use another stack :) diff --git a/service_solahart_jakarta_selatan__082122541663/glibc/t/tls.mdwn b/service_solahart_jakarta_selatan__082122541663/glibc/t/tls.mdwn deleted file mode 100644 index b10703fd..00000000 --- a/service_solahart_jakarta_selatan__082122541663/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 - <https://sourceware.org/glibc/wiki/TLSandSignals>. - - -# Documentation - -[[!taglink open_issue_documentation]] - - * IRC, freenode, #hurd, 2011-11-26 - - <tschwinge> 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? - <youpi> depends on the access - <tschwinge> * `optimized strcasecmp and strncasecmp for x86-32` - (multiarch), - <tschwinge> 76e3966e9efc3808a9e7ad09121c5dfc1211c20b + - <tschwinge> 6abf346582ba678f4850a88b4a5950593841df1d + - <tschwinge> 5583a0862cf94f71cbcde91c4043a20af65facca. `gs` - access. - <youpi> + movl __libc_tsd_LOCALE@GOTNTPOFF(%ebx), %eax - <youpi> that's handled by the linker fine - <youpi> it's only the things held in the tcb_t structure which can pose - problem - <tschwinge> tcbhead_t? - <tschwinge> I'm looking at this. - <tschwinge> So, at gs:0, there is the TCB. - <tschwinge> And we have the same layout as NPTL/Linux, just that we - don't have as much data there as they have. - <tschwinge> We're missing multiple_threads, sysinfo, sttack_guard, - pointer_guard, gscope_flag, private_futex, __private_tm[5]. - <tschwinge> So, if one of these is referenced (be it my name or by - numeric offset), this is invalid for us. - <tschwinge> Anything else should work equivalently. - <youpi> yes - <youpi> usually the only numeric offset being used is 0 - <youpi> so it would simply not build - <tschwinge> And the other offsers are generated via tcb-offsets.sym. - <tschwinge> 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. - - <tschwinge> __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. - <youpi> yes - <youpi> see in the nm output, the libc_tsd symbols - <youpi> these provide the offsets - <tschwinge> youpi: Thank you, I'm now understanding this part of TLS - much better. - <youpi> have you had a look at the tls.pdf from Uli ? - <youpi> 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`. |