This basically means to get rid of
_hurd_threadvar_location interface), and
<tschwinge> youpi: If we want to replace threadvars with TLS, there is one problem: the threadvars interface is publically exported: /usr/include/hurd/threadvar.h. <tschwinge> youpi: But I am somewhat inclined to say that the only user of this is libthreads/libpthread. Do you think differently? <youpi> tschwinge: that's very probable <youpi> so I think we can just drop it <youpi> (people should use TLS anyway)
After this has been done, probably the whole
__libc_tsd_* stuff can be
dropped altogether, and
__thread directly be used in glibc.
<tschwinge> r5219: Update libpthread patch to replace threadvar with tls for pthread_self <tschwinge> r5224: revert r5219 too, it's not ready either <youpi> as the changelog says, the __thread revertal is because it posed problems <youpi> and I just didn't have any time to check them while the freeze was so close <tschwinge> OK. What kind of problems? Should it be reverted upstream, too? <youpi> I don't remember exactly <youpi> it should just be fixed <youpi> we can revert it upstream, but it'd be good that we manage to progress, at some point... <tschwinge> Of course -- however as long as we don't know what kind of problem, it is a bit difficult. ;-) <youpi> since I didn't left a note, it was most probably a mere glibc run, or boot with the patched libpthread <youpi> *testsuite run <tschwinge> OK. <tschwinge> The libpthread testsuite doesn't show any issues with that patch applied, though. But I didn'T test anything else. <tschwinge> youpi: Also, you have probably seen my glibc __thread errno 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
Needed for gccgo.
Instead of adding support for
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).
<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.
<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.