diff options
Diffstat (limited to 'open_issues')
| -rw-r--r-- | open_issues/gccgo.mdwn | 8 | ||||
| -rw-r--r-- | open_issues/glibc.mdwn | 52 | ||||
| -rw-r--r-- | open_issues/glibc/t/tls-threadvar.mdwn | 66 |
3 files changed, 75 insertions, 51 deletions
diff --git a/open_issues/gccgo.mdwn b/open_issues/gccgo.mdwn index 0ecc1228..e9fbf0f1 100644 --- a/open_issues/gccgo.mdwn +++ b/open_issues/gccgo.mdwn @@ -30,6 +30,14 @@ First, make the language functional, have its test suite pass without errors. [[!inline pages=community/gsoc/project_ideas/gccgo feeds=no]] + +## 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]]. + + --- diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index 0df40ae5..33a1a071 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -259,54 +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` - - Needed for [[gccgo]]. - - 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. + * [[`getcontext`/`setcontext`|t/tls-threadvar]] * `futimesat` @@ -1321,7 +1274,8 @@ Failures, mostly in order of appearance: getcontext failed, errno: 1073741902. - Is not implemented; see above. In 8958805c11c741d9211e20612c86271d906c9a0b + [[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. diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn index 4afd8a1a..5f1345c6 100644 --- a/open_issues/glibc/t/tls-threadvar.mdwn +++ b/open_issues/glibc/t/tls-threadvar.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] +[[!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 @@ -14,7 +15,10 @@ 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. -IRC, freenode, #hurd, 2011-10-23: +[[!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: @@ -58,3 +62,61 @@ dropped altogether, and `__thread` directly be used in glibc. 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"]]. + + +# `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. |