From 65351e6ce5ca902e210ec10b2abbc6dd5e48041a Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 7 Apr 2013 20:23:11 +0200 Subject: open_issues/glibc/t/tls-threadvar: getcontext/setcontext. --- open_issues/glibc/t/tls-threadvar.mdwn | 66 ++++++++++++++++++++++++++++++++-- 1 file changed, 64 insertions(+), 2 deletions(-) (limited to 'open_issues/glibc/t/tls-threadvar.mdwn') 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 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? 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. -- cgit v1.2.3