diff options
Diffstat (limited to 'open_issues/glibc/t')
| -rw-r--r-- | open_issues/glibc/t/tls-threadvar.mdwn | 60 | ||||
| -rw-r--r-- | open_issues/glibc/t/tls.mdwn | 70 |
2 files changed, 130 insertions, 0 deletions
diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn new file mode 100644 index 00000000..4afd8a1a --- /dev/null +++ b/open_issues/glibc/t/tls-threadvar.mdwn @@ -0,0 +1,60 @@ +[[!meta copyright="Copyright © 2011, 2012 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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_libpthread]] + +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: + + <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) + +[[libpthread_set_stack_size]]. + +After this has been done, probably the whole `__libc_tsd_*` stuff can be +dropped altogether, and `__thread` directly be used in glibc. + + +# IRC, freenode, #hurd, 2012-08-07 + + <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 diff --git a/open_issues/glibc/t/tls.mdwn b/open_issues/glibc/t/tls.mdwn new file mode 100644 index 00000000..68db2cc1 --- /dev/null +++ b/open_issues/glibc/t/tls.mdwn @@ -0,0 +1,70 @@ +[[!meta copyright="Copyright © 2011, 2012 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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_libpthread]] + +# To Do + + * Discuss d2431f633e6139a62e1575ec18830f7e81160cf0 with Samuel. + + * `TLS_INIT_TP_EXPENSIVE` is unused; Hurd def. can be removed. + + +# Documentation + +[[!taglink open_issue_documentation]] + + * IRC, freenode, #hurd, 2011-11-26 + + <tschwinge> In glibc multiarch support (strcasecmp for i686 SSE3, etc.) + there is access to memory via gs: -- this will need to be changed for + us, right? + <youpi> depends on the access + <tschwinge> * `optimized strcasecmp and strncasecmp for x86-32` + (multiarch), + <tschwinge> 76e3966e9efc3808a9e7ad09121c5dfc1211c20b + + <tschwinge> 6abf346582ba678f4850a88b4a5950593841df1d + + <tschwinge> 5583a0862cf94f71cbcde91c4043a20af65facca. `gs` + access. + <youpi> + movl __libc_tsd_LOCALE@GOTNTPOFF(%ebx), %eax + <youpi> that's handled by the linker fine + <youpi> it's only the things held in the tcb_t structure which can pose + problem + <tschwinge> tcbhead_t? + <tschwinge> I'm looking at this. + <tschwinge> So, at gs:0, there is the TCB. + <tschwinge> And we have the same layout as NPTL/Linux, just that we + don't have as much data there as they have. + <tschwinge> We're missing multiple_threads, sysinfo, sttack_guard, + pointer_guard, gscope_flag, private_futex, __private_tm[5]. + <tschwinge> So, if one of these is referenced (be it my name or by + numeric offset), this is invalid for us. + <tschwinge> Anything else should work equivalently. + <youpi> yes + <youpi> usually the only numeric offset being used is 0 + <youpi> so it would simply not build + <tschwinge> And the other offsers are generated via tcb-offsets.sym. + <tschwinge> glibc's elf/stackguard-macros.h is wrong for us (but not + used anywhere apart from elf/tst-stackguard1.c, I think). + +After commit a9538892adfbb9f092e0bb14ff3a1703973968af, it's +`sysdeps/i386/stackguard-macros.h`; problem remains. + + <tschwinge> __thread __locale_t __libc_tsd_LOCALE = &_nl_global_locale; + -- this means that a __libc_tsd_LOCALE values will be in the TLS + segment, and this is what is being accessed from the assembler code + with %gs:__libc_tsd_LOCALE@NTPOFF, and the linker will resolve this. + <youpi> yes + <youpi> see in the nm output, the libc_tsd symbols + <youpi> these provide the offsets + <tschwinge> youpi: Thank you, I'm now understanding this part of TLS + much better. + <youpi> have you had a look at the tls.pdf from Uli ? + <youpi> all the gory details are there :) |