open_issues/glibc: This kind of TLS access via gs is fine.

2 files changed, 67 insertions, 9 deletions

diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn
index b559a351..d62abc20 100644
--- a/open_issues/glibc.mdwn
+++ b/open_issues/glibc.mdwn
@@ -62,11 +62,7 @@ Last reviewed up to the [[Git mirror's 9d65ea3a9b83ac3961229ba296a7caf90abce68d
 
         $ git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -p -C --cc -S__ASSUME_ top-bases/t/kernel-features.h_includes..baseline
 
-  * t/tls
-
-      * Discuss d2431f633e6139a62e1575ec18830f7e81160cf0 with Samuel.
-
-      * `TLS_INIT_TP_EXPENSIVE` is unused; Hurd def. can be removed.
+  * [[t/tls]]
 
   * [[t/tls-threadvar]]
 
@@ -391,10 +387,6 @@ Last reviewed up to the [[Git mirror's 9d65ea3a9b83ac3961229ba296a7caf90abce68d
         edc5984d4d18296d7aa3d8f4ed8f7336a743170e +
         57769839788e2c62b68d9dfbf4b35052321278ba.
         <http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Function-Attributes.html>.
-      * `optimized strcasecmp and strncasecmp for x86-32` (multiarch),
-        76e3966e9efc3808a9e7ad09121c5dfc1211c20b +
-        6abf346582ba678f4850a88b4a5950593841df1d +
-        5583a0862cf94f71cbcde91c4043a20af65facca.  `gs` access.
 
 
 # Build
diff --git a/open_issues/glibc/t/t-tls.mdwn b/open_issues/glibc/t/t-tls.mdwn
new file mode 100644
index 00000000..14ef36e4
--- /dev/null
+++ b/open_issues/glibc/t/t-tls.mdwn
@@ -0,0 +1,66 @@
+[[!meta copyright="Copyright © 2011 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).
+        <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 :)