diff options
Diffstat (limited to 'open_issues/glibc')
| -rw-r--r-- | open_issues/glibc/debian.mdwn | 26 | ||||
| -rw-r--r-- | open_issues/glibc/t/tls.mdwn | 66 |
2 files changed, 88 insertions, 4 deletions
diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn index ce6ba9d2..331632f3 100644 --- a/open_issues/glibc/debian.mdwn +++ b/open_issues/glibc/debian.mdwn @@ -37,10 +37,28 @@ fail. (Same for `libc6-dev_extra_pkg_install` in `debian/sysdeps/i386.mk`, for example.) Why is this special handling only done for `xen`, but not for `i686`? +> Samuel: Historically because it's done that way in linux-i386. I don't know +> the real reason. + Do `export LC_ALL=C` before building, otherwise the testsuite/make error messages will be different from those stored in the -`debian/testsuite-checking/expected-results-*` files. +`debian/testsuite-checking/expected-results-*` files, resulting in a spurious +build failure. + +Run `debian/rules build-arch DEB_BUILD_OPTIONS=parallel=2 [EGLIBC_PASSES=...]` +to build (or `build` instead of `build-arch` to build the arch-independent +stuff, too). Can interrupt with `C-c` during locale stuff or testsuite if only +interested in the build tree. + +Run `fakeroot debian/rules binary DEB_BUILD_OPTIONS=parallel=2 +[EGLIBC_PASSES=...]` to build Debian packages or `binary-arch` for just the +architecture-dependent ones. + +The latter two steps can also be combined as `dpkg-buildpackage -R'debian/rules +EGLIBC_PASSES=libc' -nc -b -uc`. `-nc` will prevent the *clean step* which +would first try to un-patch, which may conflict if you have done any edits +apter applying patches. -Run `debian/rules build-arch DEB_BUILD_OPTIONS=parallel=2 [EGLIBC_PASSES=...]`. -Can stop with `C-c` during locale stuff or testsuite if only interested in the -build tree. +If the Debian symbol versioning file is not up to date and the build of Debian +packages fails due to this, putting `DPKG_GENSYMBOLS_CHECK_LEVEL=0` in the +environment \`\`helps''; see `man dpkg-gensymbols`. diff --git a/open_issues/glibc/t/tls.mdwn b/open_issues/glibc/t/tls.mdwn new file mode 100644 index 00000000..14ef36e4 --- /dev/null +++ b/open_issues/glibc/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 :) |