open_issues/glibc: bab06390aca40703514099a7022dac4ae4aac76b (2013-05-20; fbeafedeea37e0af1984a6511018d159f5ceed6a (2012-11-03))

5 files changed, 35 insertions, 76 deletions

diff --git a/open_issues/gccgo.mdwn b/open_issues/gccgo.mdwn
index fb94cb83..9e724b95 100644
--- a/open_issues/gccgo.mdwn
+++ b/open_issues/gccgo.mdwn
@@ -34,8 +34,8 @@ First, make the language functional, have its test suite pass without errors.
 ## Svante's work
 
 Per [[!message-id "1335509732.3707.179.camel@hp.my.own.domain"]], Svante has
-been working on this, has some (unpublished) patches, and this is currently
-blocked on [[`getcontext`/`setcontext`|open_issues/glibc/t/tls-threadvar]].
+been working on this, has some (unpublished) patches, and this was blocked on
+[[`getcontext`/`makecontext`/`setcontext`/`swapcontext`|glibc]].
 
 
 ## `getcontext`/`makecontext`/`setcontext`/`swapcontext` usage analysis
@@ -53,7 +53,7 @@ The `*context` functions are used in `libgo/runtime/go-signal.c` and
 `__splitstack_makecontext`, `__splitstack_resetcontext`,
 `__splitstack_block_signals_context` are to be provided by libgcc.  However, in
 said libgo runtime files, they're used only `#ifdef USING_SPLIT_STACK`.
-[[I|ŧschwinge]] would assume that before we can enable split stacks, first
+[[I|tschwinge]] would assume that before we can enable split stacks, first
 [[open_issues/glibc/t/tls-threadvar]] needs to be fixed.
 
 In `libgo/runtime/proc.c`:`runtime_gogo`, `setcontext` is used to *switch
diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn
index 33a1a071..65352d46 100644
--- a/open_issues/glibc.mdwn
+++ b/open_issues/glibc.mdwn
@@ -259,7 +259,7 @@ Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8
             <youpi> so I'd say ignore the error for now, we'll add the
               declaration
 
-      * [[`getcontext`/`setcontext`|t/tls-threadvar]]
+      * [[t/tls-threadvar]]
 
       * `futimesat`
 
@@ -373,6 +373,22 @@ Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8
             <braunr> no, linux is more permissive
             <braunr> (at least, on this matter)
 
+      * `getcontext`/`makecontext`/`setcontext`/`swapcontext`
+
+        Support for these functions within the Hurd threadvar environment has
+        been added, but for multi-threaded applications ([[libpthread]]), it is
+        a bit clunky: as a practical requirement, a thread's stack size always
+        has to be equal to `PTHREAD_STACK_DEFAULT`, 2 MiB, and also has to be
+        naturally aligned.  The idea is still to [[get rid of Hurd threadvars
+        and replace them with TLS|t/tls-threadvar]].
+
+        Aside from [[gccgo]], the following packages might make use of these
+        functions, searching on <http://codesearch.debian.net/> for
+        `\b(get|set|make|swap)context\s*\(` on 2013-05-18: boost1.49,
+        chromium-browser, gtk-vnc, guile-1.8, iceape, icedove, iceweasel,
+        libgc, libsigsegv, luatex, mono, nspr, pth, ruby1.8, texlive-bin, uim,
+        and more.
+
     For specific packages:
 
       * [[octave]]
@@ -1102,7 +1118,7 @@ Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8
 # Build
 
 Here's a log of a glibc build run; this is from our [[Git repository's
-60f4d2f33666d77ac018cb9956675dcad04bb996 (2013-02-12;
+bab06390aca40703514099a7022dac4ae4aac76b (2013-05-20;
 fbeafedeea37e0af1984a6511018d159f5ceed6a (2012-11-03))
 sources|source_repositories/glibc]], run on coulomb.SCHWINGE.
 
@@ -1270,16 +1286,6 @@ Failures, mostly in order of appearance:
 
     SIGSEGV.  Or SIGILL.
 
-  * `stdlib/bug-getcontext.out`
-
-        getcontext failed, errno: 1073741902.
-
-    [[Not implemented|t/tls-threadvar]].
-    In 8958805c11c741d9211e20612c86271d906c9a0b
-    testing, `stdlib/bug-getcontext.out` now says: *Skipping test; no support
-    for FP exceptions.*, in cba1c83ad62a11347684a9daf349e659237a1741 testing,
-    it's back to the previous failure.
-
   * `stdlib/tst-secure-getenv.out`
 
         open (/proc/self/exe): No such file or directory
@@ -1664,6 +1670,12 @@ Earlier failures; no longer seen:
     As of 8958805c11c741d9211e20612c86271d906c9a0b, this test now passes --
     correct?
 
+  * `stdlib/bug-getcontext.out`
+
+        getcontext failed, errno: 1073741902.
+
+    Fixed, implemented in `t/context_functions`.
+
 Compared to Debian:
 
     $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/convertlog.sh log_test  > log_test.filtered
diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn
index 5f1345c6..105a07c7 100644
--- a/open_issues/glibc/t/tls-threadvar.mdwn
+++ b/open_issues/glibc/t/tls-threadvar.mdwn
@@ -64,59 +64,3 @@ dropped altogether, and `__thread` directly be used in glibc.
     <youpi> I saw the mails, but didn't investigate at all
 
 [[!message-id "878vdyqht3.fsf@kepler.schwinge.homeip.net"]].
-
-
-# `getcontext`/`setcontext`
-
-Needed for [[gccgo]].
-
-Instead of adding support for `getcontext`/`setcontext` within the Hurd
-threadvar context, which might become a bit ugly, the idea is to get rid of
-Hurd threadvars and replace them with TLS (as we want to, anyway).
-
-
-## IRC, freenode, #hurd, 2012-04-19
-
-    <gnu_srs> How much work/knowledge is needed to implement
-      getcontext/setcontext?
-    <gnu_srs> Any already implemented alternatives available?
-    <youpi> x86 registers knowledge, as well as unix signal masks
-    <youpi> there's the linux implementation that can be taken as an
-      exxample, but the signal part has to be rewritten
-    <gnu_srs> Well, it's a pity they are not implemented. That's the
-      remaining hurdle to get gccgo working :-( 
-    <youpi> uh :/
-    <gnu_srs> Everything builds, but the testsuite fails due to these
-      missing functions.
-    <gnu_srs> Regarding getcontext/setcontext they seem to be written
-      in assembly for linux but the code is not very long. 
-    <gnu_srs> How much effort would it be to write something similar
-      for Hurd? Anybody fluent in asm?
-    <gnu_srs> And registers and signals.
-    <tschwinge> gnu_srs: Signals is the key thing -- everything else we
-      can probably just copy.  I have never/not yet looked at it,
-      though.
-    <gnu_srs> For kfreebsd it is written in C: kern_context.c, 3/4 in
-      one file: getcontext, setcontext,  swapcontext, not makecontext.
-    <gnu_srs> Dunno how much assembly calls used though.
-    <gnu_srs> Hi, any preferences about implementing get/setcontext in
-      C or Asm?
-    <tschwinge> gnu_srs: I think these will have to be implemented in
-      assembly.  Based on the Linux x86 variants.
-
-
-### IRC, freenode, #hurd, 2012-04-20
-
-    <tschwinge> youpi: Your understanding of that is better than mine
-      -- the *context stuff can't be very useful at the moment, because
-      when the user changes uc_stack.ss_sp (which the glibc tests are
-      doing), we're losing access to the _hurd_threadvars.  Correct?
-    <tschwinge> At least the getcontext test works, the other get a
-      SIGILL.
-    <tschwinge> others
-    <tschwinge> _hurd_threadvars issue is just guessing.
-    <youpi> tschwinge: yes, threadvars are on the stack
-    <youpi> threadvars is not much code, it should just work, but care
-      has to be taken on the libpthread/libthread side, which does some
-      initialization
-    <tschwinge> OK, that at least matches my understanding.
diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn
index 28532320..e2fda122 100644
--- a/open_issues/libpthread.mdwn
+++ b/open_issues/libpthread.mdwn
@@ -601,6 +601,9 @@ Most of the issues raised on this page has been resolved, a few remain.
     <tschwinge> Mhm, I see.
     <braunr> so for now, i'm using this approach as a hack only
     <tschwinge> I'm working on phasing out threadvars, but we're not there yet.
+
+[[glibc/t/tls-threadvar]].
+
     <tschwinge> Yes, that's fine for the moment.
     <braunr> tschwinge: a simple definition wouldn't work
     <braunr> tschwinge: i resorted to a weak symbol, and see how it goes
diff --git a/toolchain/logs b/toolchain/logs
-Subproject a264dc206a1ebd541f01d3f3c496a80b3b8d978
+Subproject 27227e6223c3e45f2a4486cb032b8e0fd860f16