diff options
| -rw-r--r-- | open_issues/gccgo.mdwn | 6 | ||||
| -rw-r--r-- | open_issues/glibc.mdwn | 36 | ||||
| -rw-r--r-- | open_issues/glibc/t/tls-threadvar.mdwn | 56 | ||||
| -rw-r--r-- | open_issues/libpthread.mdwn | 3 | ||||
| m--------- | toolchain/logs | 10 |
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 |