diff options
Diffstat (limited to 'open_issues/glibc')
| -rw-r--r-- | open_issues/glibc/debian.mdwn | 64 | ||||
| -rw-r--r-- | open_issues/glibc/mremap.mdwn | 68 | ||||
| -rw-r--r-- | open_issues/glibc/octave.mdwn | 35 | ||||
| -rw-r--r-- | open_issues/glibc/t/tls-threadvar.mdwn | 60 | ||||
| -rw-r--r-- | open_issues/glibc/t/tls.mdwn | 70 |
5 files changed, 297 insertions, 0 deletions
diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn new file mode 100644 index 00000000..331632f3 --- /dev/null +++ b/open_issues/glibc/debian.mdwn @@ -0,0 +1,64 @@ +[[!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]]."]]"""]] + + +# Open Issues + +`threads = yes` is set in `debian/sysdeps/linux.mk` and +`debian/sysdeps/kfreebsd.mk`, `debian/sysdeps/hurd.mk` set to `no`. But this +is only read in `debian/rules` for deciding some `nscd` package issue? + +`debian/sysdeps/hurd.mk`'s `libc_extra_install` for `ld.so`: check with GCC +configuration. + +Could add a toggle to `$(stamp)build_%` in `debian/rules.d/build.mk` to skip +locale stuff. + +`--disable-compatible-utmp`? + + +# Building + +Run `debian/rules patch` to apply patches (instead of having it done during the +build). Then you can edit files manually. + +Several passes: `libc`, `i686`, `xen`; `EGLIBC_PASSES='libc i686'`, etc. + +If building with `EGLIBC_PASSES=libc` (more specifically, without `xen`), the +`libc0.3-dev_extra_pkg_install` rule in `debian/sysdeps/hurd-i386.mk` will +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, 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. + +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/mremap.mdwn b/open_issues/glibc/mremap.mdwn new file mode 100644 index 00000000..874c7ae0 --- /dev/null +++ b/open_issues/glibc/mremap.mdwn @@ -0,0 +1,68 @@ +[[!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]] + +The Hurd does not currently support the `mremap` function. + +For the `MREMAP_MAYMOVE` case it is easy to work around; see +`[binutils]/gold/mremap.c`, for example. + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-01-12 + + <antrik> maybe it would be easiest actually to implement mremap()?... + <braunr> antrik: i'm nto sure + <braunr> antrik: implementing mremap could be relatively easy to do + actually + <braunr> antrik: IIRC, vm_map() supports overlapping + <antrik> braunr: yes, I think so too + <antrik> braunr: haven't checked, but I have a vague recollection that the + fundamentals are pretty much there + +[[!taglink open_issue_glibc]]: check if it is possible to implement `mremap`. +[[I|tschwinge]] remember some discussion about this, but have not yet worked on +locating it. [[Talk to me|tschwinge]] if you'd like to have a look at this. + + +# IRC, OFTC, #debian-hurd, 2012-06-19 + + <bdefreese> OK, how the heck do you get an undefined reference to mremap? + <youpi> simply because we don't have it + <pinotree> mremap exists only on linux + <bdefreese> It's in sys/mman.h + <pinotree> on linux? + <bdefreese> No, on GNU/Hurd + <bdefreese> /usr/include/i386-gnu/sys/mman.h + <youpi> that's just the common file with linux + <youpi> containing just the prototype + <youpi> that doesn't mean there's an implementation behind + <pinotree> youpi: hm no, linux has an own version + <youpi> uh + <bdefreese> Ah, aye, I didn't look at the implementation.. :( + <youpi> it's then odd that it was added to the generic sys/mman.h :) + <bdefreese> Just another stub? + <pinotree> ah, only few linux archs have own versions + <youpi> for the macro values I guess + <pinotree> http://paste.debian.net/175173/ on glibc/master + <bdefreese> Hmm, so where is MREMAP_MAYMOVE coming in from? + <youpi> rgrep on a linux box ;) + <youpi> <bits/mman.h> + <youpi> but that's again linuxish + <bdefreese> Aye but with us having that in the header it is causing some + code to be run which utilizes mremap. If that wasn't defined we wouldn't + be calling it. + <youpi> ah + <youpi> we could try to remove it indeed + <bdefreese> Should I change the code to #ifdef MREMAP_MAYMOVE & !defined + __GNU__? + <youpi> no, I said we could remove the definition of MREMAP_MAYMOVE itself diff --git a/open_issues/glibc/octave.mdwn b/open_issues/glibc/octave.mdwn new file mode 100644 index 00000000..b12b7558 --- /dev/null +++ b/open_issues/glibc/octave.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 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]] + + +# IRC, OFTC, #debian-hurd, 2012-04-23 + + <pinotree> diffing the octave i386 vs hurd-i386 build logs gives + interesting surprises + <youpi> checking whether this system has an arbitrary file name length + limit... no | checking whether this system has an arbitrary + file name length limit... yes + <youpi> ? + <pinotree> not only that + <youpi> checking whether getcwd handles long file names properly... yes + | checking whether getcwd handles long file names properly... no, but it + is partly worki+ + <youpi> ? + <pinotree> -checking whether fdopendir works... yes + <pinotree> +checking whether fdopendir works... no + <pinotree> (- is i386, + is hurd-i386) + <pinotree> -checking whether getlogin_r works with small buffers... yes + <pinotree> +checking whether getlogin_r works with small buffers... no + <pinotree> -checking for working mkstemp... yes + <pinotree> +checking for working mkstemp... no + <pinotree> +checking for working nanosleep... no (mishandles large + arguments) 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 :) |