From 78d2510a84a791479ff0bad78e21aca6c4ce78fa Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 21 May 2013 14:27:40 +0200 Subject: open_issues/glibc: bab06390aca40703514099a7022dac4ae4aac76b (2013-05-20; fbeafedeea37e0af1984a6511018d159f5ceed6a (2012-11-03)) --- open_issues/gccgo.mdwn | 6 ++-- open_issues/glibc.mdwn | 36 ++++++++++++++-------- open_issues/glibc/t/tls-threadvar.mdwn | 56 ---------------------------------- open_issues/libpthread.mdwn | 3 ++ toolchain/logs | 2 +- 5 files changed, 31 insertions(+), 72 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 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 no, linux is more permissive (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 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. 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 - - How much work/knowledge is needed to implement - getcontext/setcontext? - Any already implemented alternatives available? - x86 registers knowledge, as well as unix signal masks - there's the linux implementation that can be taken as an - exxample, but the signal part has to be rewritten - Well, it's a pity they are not implemented. That's the - remaining hurdle to get gccgo working :-( - uh :/ - Everything builds, but the testsuite fails due to these - missing functions. - Regarding getcontext/setcontext they seem to be written - in assembly for linux but the code is not very long. - How much effort would it be to write something similar - for Hurd? Anybody fluent in asm? - And registers and signals. - gnu_srs: Signals is the key thing -- everything else we - can probably just copy. I have never/not yet looked at it, - though. - For kfreebsd it is written in C: kern_context.c, 3/4 in - one file: getcontext, setcontext, swapcontext, not makecontext. - Dunno how much assembly calls used though. - Hi, any preferences about implementing get/setcontext in - C or Asm? - gnu_srs: I think these will have to be implemented in - assembly. Based on the Linux x86 variants. - - -### IRC, freenode, #hurd, 2012-04-20 - - 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? - At least the getcontext test works, the other get a - SIGILL. - others - _hurd_threadvars issue is just guessing. - tschwinge: yes, threadvars are on the stack - threadvars is not much code, it should just work, but care - has to be taken on the libpthread/libthread side, which does some - initialization - 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. Mhm, I see. so for now, i'm using this approach as a hack only I'm working on phasing out threadvars, but we're not there yet. + +[[glibc/t/tls-threadvar]]. + Yes, that's fine for the moment. tschwinge: a simple definition wouldn't work tschwinge: i resorted to a weak symbol, and see how it goes diff --git a/toolchain/logs b/toolchain/logs index a264dc20..27227e62 160000 --- a/toolchain/logs +++ b/toolchain/logs @@ -1 +1 @@ -Subproject commit a264dc206a1ebd541f01d3f3c496a80b3b8d978b +Subproject commit 27227e6223c3e45f2a4486cb032b8e0fd860f16a -- cgit v1.2.3