diff options
Diffstat (limited to 'open_issues/glibc')
| -rw-r--r-- | open_issues/glibc/debian.mdwn | 64 | ||||
| -rw-r--r-- | open_issues/glibc/getlogin_r.mdwn | 45 | ||||
| -rw-r--r-- | open_issues/glibc/mremap.mdwn | 221 | ||||
| -rw-r--r-- | open_issues/glibc/octave.mdwn | 35 | ||||
| -rw-r--r-- | open_issues/glibc/t/tls-threadvar.mdwn | 31 | ||||
| -rw-r--r-- | open_issues/glibc/t/tls.mdwn | 70 |
6 files changed, 466 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/getlogin_r.mdwn b/open_issues/glibc/getlogin_r.mdwn new file mode 100644 index 00000000..9980ea1f --- /dev/null +++ b/open_issues/glibc/getlogin_r.mdwn @@ -0,0 +1,45 @@ +[[!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]]."]]"""]] + +[[!meta title="getlogin_r"]] + +[[!tag open_issue_glibc]] + + +# IRC, freenode, #hurd, 2012-04-23 + + * pinotree spots how our getlogin_r() implementation uses a static + buffer... + <braunr> oO + <pinotree> braunr: yeah, the _r means "reentrantbutnotreally" xD + <braunr> pinotree: that's amazing .. + <antrik> pinotree: without having checked the actual implementation, that + doesn't sound like a problem... + <antrik> caching doesn't break reentrancy. the problem with the plain + getlogin() is that a static buffer is *returned to the user* + <pinotree> antrik: http://paste.debian.net/164727/ + <braunr> ah, caching + <pinotree> i don't think this is caching at all + <antrik> pinotree: OK, not actually caching... but same effect as far as I + can tell + <antrik> pinotree: or is it the fixed size of the temporary variable you + are concerned about? + <pinotree> antrik: my concern was about the "static" of the buffer used for + the get_login rpc + <antrik> pinotree: I'm not sure that's a problem. can the login actually + ever change for a running process? + <pinotree> dunno + <pinotree> but if so, it would be pointless to do the rpc every time + instead of just once + <antrik> pinotree: true + * pinotree would just make it non-static and be safe + <antrik> pinotree: well, one might argue that allocating a KiB of stack + space is not very friendly, especially in a low-level library... + <antrik> not sure what the general policy is about such things in libc diff --git a/open_issues/glibc/mremap.mdwn b/open_issues/glibc/mremap.mdwn new file mode 100644 index 00000000..a293eea0 --- /dev/null +++ b/open_issues/glibc/mremap.mdwn @@ -0,0 +1,221 @@ +[[!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]] + +[[!toc]] + + +# binutils gold + +## IRC, freenode, #hurd, 2011-01-12 + + <teythoon> I've been looking into building gold on hurd and it built fine + with one minor tweak + <teythoon> and it's working fine according to its test suite + <teythoon> the only problem is that the build system is failing to detect + the hurdish mremap which lives in libmemusage + <teythoon> on linux it is in the libc so the check succeeds + <teythoon> any hints on how to fix this properly? + <antrik> hm... it's strange that it's a different library on the Hurd + <antrik> are the implementations compatible? + <teythoon> antrik: it seems so, though the declarations differ slightly + <antrik> I guess the best thing is to ask on the appropriate list(s) why + they are different... + <teythoon> teythoon@ganymede:~/build/gold/binutils-2.21/gold$ grep -A1 + mremap /usr/include/sys/mman.h + <teythoon> extern void *mremap (void *__addr, size_t __old_len, size_t + __new_len, int __flags, ...) __THROW; + <teythoon> vs + <antrik> of course it would be possible to modify the configure script to + check for the Hurd variant too; but first we should establish whether + here is actually any reason for being different, or it's just some + historical artefact that should be fixed... + <teythoon> teythoon@ganymede:~/build/gold/binutils-2.21/gold$ fgrep 'extern + void *mremap' mremap.c + <teythoon> extern void *mremap (void *, size_t, size_t, int, ...); + <teythoon> the problem is that the test fails to link due to the fact that + mremap isn't in the libc on hurd + <antrik> yeah, it would be possible for the configure script to check + whether it works when the hurdish extra library is added explicitely + <antrik> but again, I don't see any good reason for being different here in + the first place... + <teythoon> so should I create a patch to move mremap? + <antrik> if it's not too complicated, that would be nice... it's always + easier to discuss when you already have code :-) + <antrik> OTOH, asking first might spare you some useless work if it turns + out there *is* some reason for being different after all... + so where is the right place to discuss this? + <antrik> bug-hurd mailing list and/or glibc mailing list. not sure which + one is better -- I guess it doesn't hurt to crosspost... + +[[mailing_lists/libc-alpha]] is the correct list, and cross-posting to +[[mailing_lists/bug-hurd]] would be fine, too. + + <teythoon> antrik: some further digging revealed that mremap belongs to + /lib/libmemusage.so on both hurd and linux + <teythoon> the only difference is that on linux there is a weak reference + to that function in /lib/libc-2.11.2.so + <teythoon> $ objdump -T /lib/libc-2.11.2.so | fgrep mremap + <teythoon> 00000000000cf7e0 w DF .text 0000000000000028 GLIBC_2.2.5 + mremap + <antrik> ah, it's probably simply a bug that we don't have this weak + reference too + <antrik> IIRC we had similar bugs before + <antrik> teythoon: can you provide a patch for that? + <teythoon> antrik: unfortunately I have no idea how that weak ref ended up + there + + <guillem> teythoon: also the libmemusage.s seems to be just a debugging + library to be used by LD_PRELOAD or similar + <guillem> which override those memory functions + <guillem> the libc should provide actual code for those functions, even if + the symbol is declared weak (so overridable) + <guillem> teythoon: are you sure that's the actual problem? can you paste + somewhere the build logs with the error? + <teythoon> guillem: sure + <teythoon> http://paste.debian.net/104437/ + <teythoon> that's the part of config.log that shows the detection (or the + failure to detect it) of mremap + <teythoon> this results in HAVE_MREMAP not being defined + <teythoon> as a consequence it is declared in gold.h and this declaration + conflicts with the one from sys/mman.h http://paste.debian.net/104438/ + <teythoon> on linux the test for mremap succeeds + <guillem> teythoon: hmm oh I guess it's just what that, mremap is linux + specific so it's not available on the hurd + <guillem> teythoon: I just checked glibc and seems to confirm that + <braunr> CONFORMING TO This call is Linux-specific, and should not be used + in programs intended to be portable. + <teythoon> ah okay + <teythoon> so I guess we shouldn't ship an header with that declaration... + <guillem> teythoon: yeah :/ good luck telling that to drepper :) + <guillem> teythoon: I guess he'll suggest that everyone else needs to get + our own copy of sys/mman.h + <guillem> s/our/their/ + <teythoon> hm, so how should I proceed? + <braunr> what's your goal ? + <braunr> detecting mremap ? + <teythoon> making binutils/gold compile ootb on hurd + <teythoon> I picked it from the open issues page ;) + <braunr> well, if there is no mremap, you need a replacement + <teythoon> gold has a replacement + <braunr> ok + <braunr> so your problem is fixing the detection of mremap right ? + <teythoon> yes + <braunr> ok, that's a build system question then :/ + <braunr> you need to ask an autotools guy + <teythoon> well, actually the build system correctly detects the absence of + mremap + <braunr> (gold does use the autotools right ?) + <teythoon> yes + <braunr> oh, i'm lost now (i admit i didn't read the whole issue :/) + <teythoon> it is just that the declaration in sys/mman.h conflicts with + their own declaration + <braunr> ah + <braunr> so in the absence of mremap, they use their own builtin function + <teythoon> yes + <teythoon> and according to the test suite it is working perfectly + <teythoon> gold that is + <teythoon> the declaration in mman.h has an extra __THROW + <guillem> a workaround would be to rename gold's mremap to something else, + gold_mremap for example + <braunr> that's really the kind of annoying issue + <braunr> you either have to change glibc, or gold + <guillem> yeah + <braunr> you'll face difficulty changing glibc, as guillem told you + <guillem> the correct solution though IMO is to fix glibc + <braunr> but this may be true for gold too + <braunr> guillem: i agree + <antrik> maybe it would be easiest actually to implement mremap()?... + <braunr> but as this is something quite linux specific, it makes sense to + use another internal name, and wrap that to the linux mremap if it's + detected + <braunr> antrik: i'm nto sure + <antrik> braunr: I don't think using such workarounds is a good + idea. clearly there would be no issue if the header file wouldn't be + incorrect on Hurd + <braunr> antrik: that's why i said i agree with guillem when he says "the + correct solution though IMO is to fix glibc" + <teythoon> what exactly is the problem with getting a patch into glibc? + <braunr> the people involved + <guillem> teythoon: and touching a generic header file + <braunr> but feel free to try, you could be lucky + <teythoon> but glibc is not an linux specific piece of software, right? + <braunr> teythoon: no, it's not + <guillem> erm... + <braunr> teythoon: but in practice, it is + <guillem> supposedly not :) + <antrik> braunr: BTW, by "easiest" I don't mean coding alone, but + coding+pushing upstream :-) + <guillem> so the problem is, misc/sys/mman.h should be a generic header and + as such not include linux specific parts, which are not present on hurd, + kfreebsd, etc etc + <braunr> antrik: yes, that's why guillem and i suggested the workaround + thing in gold + <antrik> that also requires pushing upstream. and quite frankly, if I were + the gold maintainer, I wouldn't accept it. + <guillem> but the easiest (and wrong) solution in glibc to avoid maintainer + conflict will probably be copying that file under hurd's glibc tree and + install that instead + <braunr> antrik: implementing mremap could be relatively easy to do + actually + <braunr> antrik: IIRC, vm_map() supports overlapping + <antrik> well, actually the easiest solution would be to create a patch + that never goes upstream but is included in Debian, like many + others... but that's obviously not a good long-term plan + <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 + <antrik> teythoon: so, apart from an ugly workaround in gold, there are + essentially three options: 1. implement mremap; 2. make parts of mman.h + conditional; 3. use our own copy of mman.h + <antrik> 1. would be ideal, but might be non-trivial; 2. would might be + tricky to get right, and even more tricky to get upstream; 3. would be + simple, but a maintenance burden in the long term + <teythoon> looking at golds replacement code (mmap & memcpy) 1 sounds like + the best option performance wise + +[[!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..e72732ab --- /dev/null +++ b/open_issues/glibc/t/tls-threadvar.mdwn @@ -0,0 +1,31 @@ +[[!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. 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 :) |