Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn"

This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1.
author: Samuel Thibault <samuel.thibault@ens-lyon.org> 2015-02-18 00:58:35 +0100
committer: Samuel Thibault <samuel.thibault@ens-lyon.org> 2015-02-18 00:58:35 +0100
commit: 49a086299e047b18280457b654790ef4a2e5abfa (patch)
tree: c2b29e0734d560ce4f58c6945390650b5cac8a1b /open_issues/glibc
parent: e2b3602ea241cd0f6bc3db88bf055bee459028b6 (diff)
6 files changed, 847 insertions, 0 deletions
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
+
+    <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/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
+
+    <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/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
+
+    <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/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
+
+    <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/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
+
+    <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/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
+    <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`.
author	Samuel Thibault <samuel.thibault@ens-lyon.org>	2015-02-18 00:58:35 +0100
committer	Samuel Thibault <samuel.thibault@ens-lyon.org>	2015-02-18 00:58:35 +0100
commit	49a086299e047b18280457b654790ef4a2e5abfa (patch)
tree	c2b29e0734d560ce4f58c6945390650b5cac8a1b /open_issues/glibc
parent	e2b3602ea241cd0f6bc3db88bf055bee459028b6 (diff)