diff options
Diffstat (limited to 'open_issues')
22 files changed, 1175 insertions, 206 deletions
diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn index 6be690d8..8d6b3a94 100644 --- a/open_issues/binutils.mdwn +++ b/open_issues/binutils.mdwn @@ -35,19 +35,20 @@ though, as explained below. git checkout reviewed git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -p -C --cc ..sourceware/master -i -/^commit |^---$|hurd|linux +/^commit |^---$|hurd|linux|nacl --> -Last reviewed up to the [[Git mirror's 6de66ef60a39ab2cdacf801dae0110f36a76537c -(2012-02-15) sources|source_repositories/binutils]]. +Last reviewed up to the [[Git mirror's dde164167b2db4c05d58b1941d610beb6d5ca99f +(2012-06-08) sources|source_repositories/binutils]]. * Globally - * a.out, COFF, PE image support and 64 bit support are not interesting. + * a.out (such as `ld/emulparams/i386linux.sh`, `ld/emultempl/linux.em`, + etc.), COFF, PE image support and 64-bit support are not interesting. * In the testsuites, `.exp` and `.d` files very likely should not only - care for `*-*-linux*`, but also `*-*-gnu*`. (If the need to be + care for `*-*-linux*`, but also `*-*-gnu*`. (If they need to be conditionalized like this at all.) * `bfd/` @@ -117,7 +118,7 @@ Last reviewed up to the [[Git mirror's 6de66ef60a39ab2cdacf801dae0110f36a76537c # Build Here's a log of a binutils build run; this is from our [[Git repository's -f42a507c8b1e79cec0e755249e9fb5c2e012fe83 (2012-02-15) +e1104996559067c40207c803ab1a5847a4a05145 (2012-06-07) sources|source_repositories/binutils]], run on kepler.SCHWINGE and coulomb.SCHWINGE. @@ -133,6 +134,12 @@ harmonized. This takes up around 120 MiB, and needs roughly 4 min on kepler.SCHWINGE and 15 min on coulomb.SCHWINGE. +<!-- + + $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-check) 2>&1 | tee log_install && test -f .go-check && make -k check 2>&1 | tee log_check + +--> + ## Analysis diff --git a/open_issues/boehm_gc.mdwn b/open_issues/boehm_gc.mdwn index 31359da3..6ab39b2e 100644 --- a/open_issues/boehm_gc.mdwn +++ b/open_issues/boehm_gc.mdwn @@ -15,18 +15,26 @@ This one does need Hurd-specific configuration. It is, for example, used by [[/GCC]] (which has its own fork), so any changes committed upstream should very like also be made there. +[[!toc levels=2]] + # [[General information|/boehm_gc]] -# [[Sources|source_repositories/boehm_gc]] +# Configuration +<!-- -# Configuration +git checkout reviewed +git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..upstream/master +-i +/^commit |^---$|hurd|linux|glibc -[[tschwinge]] reviewed its GNU/Hurd port's configuration on 2010-12-08, based -on CVS HEAD sources from 2010-12-02, converted to [[Git, correspondingly -1c2455988a8f59a5f83b986b9156f03be395b3b6|source_repositories/boehm_gc]]. +--> + +Last reviewed up to the 5f492b98dd131bdd6c67eb56c31024420c1e7dab (2012-06-08) +sources, and for `libatomic_ops` to the +6a0afde033f105c6320f1409162e3765a1395bfd (2012-05-15) sources. * `configure.ac` @@ -253,19 +261,98 @@ on CVS HEAD sources from 2010-12-02, converted to [[Git, correspondingly Nothing. + * b8b65e8a5c2c4896728cd00d008168a6293f55b1 configure.ac probably not all + correct. + + * `mmap`, b64dd3bc1e5a23e677c96b478d55648a0730ab75 + + * `parallel mark`, 07c2b8e455c9e70d1f173475bbf1196320812154, pass + `--disable-parallel-mark` or enable for us, too? + + * `HANDLE_FORK`, e9b11b6655c45ad3ab3326707aa31567a767134b, + 806d656802a1e3c2b55cd9e4530c6420340886c9, + 1e882b98c2cf9479a9cd08a67439dab7f9622924 + + * Check `include/private/thread_local_alloc.h` re + `USE_COMPILER_TLS`/`USE_PTHREAD_SPECIFIC`. + + +# Build + +Here's a log of a binutils build run; this is from the +5f492b98dd131bdd6c67eb56c31024420c1e7dab (2012-06-08) sources, and for +`libatomic_ops` for the 6a0afde033f105c6320f1409162e3765a1395bfd (2012-05-15) +sources, run on kepler.SCHWINGE and coulomb.SCHWINGE. + + $ export LC_ALL=C + $ (cd ../master/ && ln -sfn ../libatomic_ops/master libatomic_ops) + $ (cd ../master/ && autoreconf -vfi) + $ ../master/configure --prefix="$PWD".install SHELL=/bin/bash CC=gcc-4.6 CXX=g++-4.6 --enable-cplusplus --enable-gc-debug --enable-gc-assertions --enable-assertions 2>&1 | tee log_build + [...] + $ make 2>&1 | tee log_build_ + [...] + +Different hosts may default to different shells and compiler versions; thus +harmonized. Using bash instead of dash as otherwise libtool explodes. + +This takes up around X MiB, and needs roughly X min on kepler.SCHWINGE and +X min on coulomb.SCHWINGE. + +<!-- + + $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-check) 2>&1 | tee log_install && test -f .go-check && { make -k check 2>&1 | tee log_check; (cd libatomic_ops/ && make -k check) 2>&1 | tee log_check_; } + +--> + +## Analysis + + $ ssh kepler.SCHWINGE 'cd tmp/source/boehm-gc/ && cat master.build/log_build* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/linux/log_build + $ ssh coulomb.SCHWINGE 'cd tmp/boehm-gc/ && cat master.build/log_build* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/hurd/log_build + $ diff -wu <(sed -f toolchain/logs/boehm-gc/linux/log_build.sed < toolchain/logs/boehm-gc/linux/log_build) <(sed -f toolchain/logs/boehm-gc/hurd/log_build.sed < toolchain/logs/boehm-gc/hurd/log_build) > toolchain/logs/boehm-gc/log_build.diff + + * only GNU/Linux: `configure: WARNING: "Explicit GC_INIT() calls may be + required."` + + * only GNU/Linux: `configure: WARNING: "Client must not use + -fomit-frame-pointer."` + + +# Install + + $ make install 2>&1 | tee log_install + [...] + +This takes up around X MiB, and needs roughly X min on kepler.SCHWINGE and X +min on coulomb.SCHWINGE. + + +## Analysis + + $ ssh kepler.SCHWINGE 'cd tmp/source/boehm-gc/ && cat master.build/log_install | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/linux/log_install + $ ssh coulomb.SCHWINGE 'cd tmp/boehm-gc/ && cat master.build/log_install | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/hurd/log_install + $ diff -wu toolchain/logs/boehm-gc/linux/log_install toolchain/logs/boehm-gc/hurd/log_install > toolchain/logs/boehm-gc/log_install.diff + # Testsuite -There are different configurations possible, but in general, the testsuite -restults of GNU/Linux and GNU/Hurd look very similar. + $ make -k check + [...] + $ (cd libatomic_ops/ && make -k check) + [...] -It has last been run and compared on 2010-11-10, based on CVS HEAD sources from -2010-11-04, converted to [[Git, correspondingly -9abb37b2e581b415bb1f482085891a289c2c0be1|source_repositories/boehm_gc]]. +This needs roughly X min on kepler.SCHWINGE and X min on coulomb.SCHWINGE. -## `--enable-cplusplus --enable-gc-debug` - * GNU/Hurd is missing *Call chain at allocation: [...] output*. +## Analysis + + $ ssh kepler.SCHWINGE 'cd tmp/source/boehm-gc/ && cat master.build/log_check* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/linux/log_check + $ ssh coulomb.SCHWINGE 'cd tmp/boehm-gc/ && cat master.build/log_check* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/hurd/log_check + $ diff -wu <(sed -f toolchain/logs/boehm-gc/linux/log_check.sed < toolchain/logs/boehm-gc/linux/log_check) <(sed -f toolchain/logs/boehm-gc/hurd/log_check.sed < toolchain/logs/boehm-gc/hurd/log_check) > toolchain/logs/boehm-gc/log_check.diff + +There are different configurations possible, but in general, the testsuite +restults of GNU/Linux and GNU/Hurd look very similar. + + * GNU/Hurd is missing `Call chain at allocation: [...]` output. `os_dep.c`:`GC_print_callers` @@ -277,6 +364,9 @@ It has last been run and compared on 2010-11-10, based on CVS HEAD sources from * What are other applications to test Boehm GC? Also especially in combination with [[/libpthread]] and dynamic loading of shared libraries? + * There are patches (apparently not committed) that GCC itself can use + it, too: <http://gcc.gnu.org/wiki/Garbage_collection_tuning>. + * There's been some talking about it on GNU guile mailing lists, and two Git branches (2010-12-15: last change 2009-09). diff --git a/open_issues/bpf.mdwn b/open_issues/bpf.mdwn index 2a8c897a..e24d761b 100644 --- a/open_issues/bpf.mdwn +++ b/open_issues/bpf.mdwn @@ -562,3 +562,26 @@ This is a collection of resources concerning *Berkeley Packet Filter*s. DDE accordingly <braunr> antrik: i agree <braunr> antrik: eth-multiplexer would be the right place + + +## IRC, freenode, #hurd, 2012-04-24 + + <gnu_srs> braunr: Is BPF fully supported by now? Can it be used for + isc-dhcp? + <braunr> gnu_srs: bpf isn't supported at all + <braunr> gnu_srs: instead of emulating it, i added a hurd-specific module + in libpcap + <braunr> if isc-dhcp can use libpcap, then fine + <braunr> (otherwise we could create a hurd-specific patch for dhcp that + uses the in-kernel bpf filter implementation) + <braunr> gnu_srs: can't it use a raw socket ? + <youpi> it can + <youpi> it's just that the shape of the patch to do so wasn't exactly how + they needed it + <youpi> so they have to rework it a bit + <youpi> and that takes time + <braunr> ok + <braunr> antrik: for now, we prefer encapsulating the system specific code + in libpcap, and let users of that library benefit from it + <braunr> instead of implementing the low level bpf interface, which + nonetheless has some system-specific variants .. diff --git a/open_issues/file_system_exerciser.mdwn b/open_issues/file_system_exerciser.mdwn index 4277e5e7..c51863b9 100644 --- a/open_issues/file_system_exerciser.mdwn +++ b/open_issues/file_system_exerciser.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!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 @@ -13,3 +13,17 @@ License|/fdl]]."]]"""]] Test our file system implementations with the File System Exerciser. * <http://codemonkey.org.uk/projects/fsx/> + + +# Alternatives + + +## fs_mark + + +### IRC, freenode, #hurd, 2012-04-30 + + <pinotree> mcsim: http://sourceforge.net/projects/fsmark/ + <pinotree> mcsim: just saw it in debian's NEW queue and from the + description it seemed like something it could be helpful for you + <pinotree> (and in general to test fs'es) diff --git a/open_issues/fork_deadlock.mdwn b/open_issues/fork_deadlock.mdwn new file mode 100644 index 00000000..6b90aa0a --- /dev/null +++ b/open_issues/fork_deadlock.mdwn @@ -0,0 +1,65 @@ +[[!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]] + +This started appearing when Jérémie's [[glibc]] signal patches were integrated: +very sporadically, but still now and then, `fork` will hang, as follows, and +typically in `/bin/sh`. + +From a `libtool` invocation: + + #0 0x0107b13c in swtch_pri () at /build/eglibc-Q9jlik/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + No locals. + #1 0x0107c9c4 in __spin_lock_solid (lock=0x125080c) at spin-solid.c:27 + No locals. + #2 0x01091427 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55 + No locals. + #3 _hurd_sigstate_lock (ss=0x1250008) at hurdsig.c:172 + No locals. + #4 0x011261ec in _hurd_critical_section_unlock (our_lock=<optimized out>) at ../hurd/hurd/signal.h:235 + No locals. + #5 __fork () at ../sysdeps/mach/hurd/fork.c:706 + env = {{__jmpbuf = {18784244, 19197896, 1, 16925832, 16925460, 17980399}, __mask_was_saved = 0, __saved_mask = 33}} + pid = 0 + err = <optimized out> + __PRETTY_FUNCTION__ = "__fork" + ss = 0x1250008 + threads = 0x0 + nthreads = 0 + stopped = 1 + i = 6 + [...] + + +Another one in `dash`: + + #0 0x0105927c in swtch_pri () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + No locals. + #1 0x0105ac44 in __spin_lock_solid (lock=0x123580c) at spin-solid.c:27 + No locals. + #2 0x010701c7 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55 + No locals. + #3 _hurd_sigstate_lock (ss=0x1235008) at hurdsig.c:172 + No locals. + #4 0x011048f0 in _hurd_critical_section_unlock (our_lock=0x1235008) at ../hurd/hurd/signal.h:235 + ss = 0x1235008 + pending = <optimized out> + #5 __fork () at ../sysdeps/mach/hurd/fork.c:706 + env = {{__jmpbuf = {18780148, 19087304, 134621988, 0, 16938700, 17842902}, __mask_was_saved = 0, __saved_mask = 4294967295}} + pid = 0 + err = 0 + __PRETTY_FUNCTION__ = "__fork" + ss = 0x1235008 + threads = 0x0 + nthreads = 0 + stopped = 1 + i = 6 + [...] diff --git a/open_issues/gcc.mdwn b/open_issues/gcc.mdwn index da4b9345..d5ba484c 100644 --- a/open_issues/gcc.mdwn +++ b/open_issues/gcc.mdwn @@ -26,62 +26,19 @@ example. Especially all the compiler magic is all the same. # [[Sources|source_repositories/gcc]] -## Boehm GC - -GCC includes an own variant of [[/Boehm_GC]] that is based on an upstream -version, but with own patches, etc. This is used for Java. (There are patches -(apparently not committed) that GCC itself can use it, too: -<http://gcc.gnu.org/wiki/Garbage_collection_tuning>.) - -Patches to GCC's fork should be contributed back to upstream [[/Boehm_GC]]. - -[[tschwinge]] reviewed (but only briefly for large parts) the differences on -2010-12-08, based on the [[GCC Git mirror's -8e79e9d43f32c8852f068da91d655297d92ac0f4 (2010-11-29) -sources|source_repositories/GCC]] and Boehm GC's CVS HEAD sources from -2010-12-02, converted to [[Git, correspondingly -1c2455988a8f59a5f83b986b9156f03be395b3b6|source_repositories/boehm_gc]]. - -On 2010-11-17, -[[tschwinge]] reviewed the Debian GCC Boehm GC changes, compared them to the -upstream code, and put it into the local *hurd/boehm-gc/config_backport* -branch, planning to submit it to gcc-patches after testing with the GCC -testsuite. - - * Check - - * 02e191ba495b4ec87aeb961ff9afdb666287104a - - * ce062771587f6637ce09f79c36e24de691032919 - - * a9cc177ef514d6eb39db72c82911fcea2cd70dba - - * 7b8d306d18986cd98808c9ed5d3a696a186dc213 - - Looks generally OK. - - * a3a3fd06ae58af9591a95c94245809b0359289ff - - Looks OK. - - * fe5ef4a01870545d0344e670cd528ad096ebab1d - - OK. - - # Configuration <!-- git checkout reviewed -git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -p -C --cc ..upstream/master +git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -p -C --cc ..upstream/trunk -i -/^commit |^---$|hurd|linux +/^commit |^---$|hurd|linux|nptl|glibc --> -Last reviewed up to the [[Git mirror's 9aa4b6a8046270a9dbdf47827f1ea873217d7aa5 -(2011-11-28) sources|source_repositories/gcc]]. +Last reviewed up to the [[Git mirror's dfed30bca14de84e0446cc02f5a27407dbfdc3e1 +(2012-06-11) sources|source_repositories/gcc]]. <http://gcc.gnu.org/install/configure.html> has documentation for the `configure` switches. @@ -100,7 +57,7 @@ Last reviewed up to the [[Git mirror's 9aa4b6a8046270a9dbdf47827f1ea873217d7aa5 * `libstdc++-v3/config/os/gnu-linux/*` Is used for all GNU systems, as per `libstdc++-v3/configure.host`. - Should rename to `gnu` to reflect this? + Should rename to `gnu-user` to reflect this? * `gcc/acinclude.m4`:`gcc_GAS_FLAGS`: always pass `--32` to assembler for x86 Linux. (Why?) @@ -250,16 +207,35 @@ Last reviewed up to the [[Git mirror's 9aa4b6a8046270a9dbdf47827f1ea873217d7aa5 * f29a2041f32773464e226a83f41762c2e9cf658e (e53a96c2136f7cdff4699475fea41afeed9dece3) + Testresults same as for GNU/Linux. + + * [high] 3efc00f6f17778172d3fa7ac737fa1473b3b4d5a, `Check __GLIBC__ when + using __SIGRTMIN`. GCC PR52390. Fixed by + 8d2259c83f94c082ad8a00b5d00bb639ce24efce. + + * 15ac1e637ad0cb92bf7629205c617ea847a4b810 `Build 64-bit libffi multilib for + i?86-linux`. + + * `libstdc++`: uses `_GLIBCXX_HAVE_TLS`, but where is this defined? Supposed + to come from `config/tls.m4:GCC_CHECK_TLS`? + + * `libgcc/gthr-posix.h:__gthread_active_p` -- is this suitable for us? This + is used in libgcc for ObjC wrapper stuff and similar in libstdc++. + C.f. [[!message-id "x57jobtqx89w.fsf@frobland.mtv.corp.google.com"]], + [[!message-id "x57jd359fkx3.fsf@frobland.mtv.corp.google.com"]] as well as + [[!debbug 629866]]/[[!message-id + "20110609002620.GA16719@const.famille.thibault.fr"]]. + # Build Here's a log of a GCC build run; this is from our [[Git repository's -74a56c71c55f667824eb2ef1d62d408e9c000d5e (2011-10-23) +2e2db3f92b534460c68c2f9ae64455884424beb6 (2012-06-15; 2012-06-06) sources|source_repositories/gcc]], run on kepler.SCHWINGE and coulomb.SCHWINGE. $ export LC_ALL=C $ (cd ../master/ && contrib/gcc_update --touch) - $ ../master/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 2>&1 | tee log_build + $ ../master/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 --enable-build-with-cxx --enable-languages=all,ada 2>&1 | tee log_build [...] $ make 2>&1 | tee log_build_ [...] @@ -267,15 +243,19 @@ sources|source_repositories/gcc]], run on kepler.SCHWINGE and coulomb.SCHWINGE. Different hosts may default to different shells and compiler versions; thus harmonized. -This takes up around 2.9 GiB, and needs roughly 2.75 h on kepler.SCHWINGE and -13.25 h on coulomb.SCHWINGE. +This takes up around 3.1 GiB, and needs roughly 3.0 h on kepler.SCHWINGE and +12.75 h on coulomb.SCHWINGE. + +<!-- + + $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-check) 2>&1 | tee log_install && test -f .go-check && make -k RUNTESTFLAGS=-v check 2>&1 | tee log_check + +--> ## Analysis - $ ssh kepler.SCHWINGE 'cd tmp/source/gcc/ && cat hurd/master.build/log_build* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/gcc/linux/log_build - $ ssh coulomb.SCHWINGE 'cd tmp/gcc/ && cat hurd/master.build/log_build* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/gcc/hurd/log_build - $ diff -wu <(sed -f toolchain/logs/gcc/linux/log_build.sed < toolchain/logs/gcc/linux/log_build) <(sed -f toolchain/logs/gcc/hurd/log_build.sed < toolchain/logs/gcc/hurd/log_build) > toolchain/logs/gcc/log_build.diff + $ toolchain/logs/process gcc build * [[`checking if gcc static flag -static works... no`|glibc_madvise_vs_static_linking]] @@ -334,17 +314,16 @@ This takes up around 2.9 GiB, and needs roughly 2.75 h on kepler.SCHWINGE and * `libgomp/config/linux/`, `libgomp/config/linux/x86` + `sed`ed away. + * `-ftls-model=initial-exec -march=i486 -mtune=i686` + `sed`ed away. + * Missing `EOWNERDEAD`, `ENOTRECOVERABLE`. What're they used for? * `RLIMIT_VMEM`. Usage kosher? - * `basic_file.cc` - - +basic_file.cc: In member function 'std::streamsize std::__basic_file<char>::showmanyc()': - +basic_file.cc:347:33: warning: enumeral and non-enumeral type in conditional expression [enabled by default] - * `libtool: link: ar rc .libs/libstdc++.a [...]` Just different order of object files, or another problem? TODO @@ -357,11 +336,10 @@ This takes up around 2.9 GiB, and needs roughly 2.75 h on kepler.SCHWINGE and * `libobjc/thr.c`: `gcc/gthr-posix.h` libtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] [...]/hurd/master/libobjc/thr.c -c [...] - +In file included from ../.././gcc/gthr-default.h:1:0, - + from [...]/hurd/master/libobjc/../gcc/gthr.h:160, + +In file included from [...]/hurd/master/libobjc/../libgcc/gthr.h:142:0, + from [...]/hurd/master/libobjc/thr.c:45: - +[...]/hurd/master/libobjc/../gcc/gthr-posix.h: In function '__gthread_objc_thread_set_priority': - +[...]/hurd/master/libobjc/../gcc/gthr-posix.h:389:41: warning: unused parameter 'priority' [-Wunused-parameter] + +../libgcc/gthr-default.h: In function '__gthread_objc_thread_set_priority': + +../libgcc/gthr-default.h:388:41: warning: unused parameter 'priority' [-Wunused-parameter] * `/proc/self/*` @@ -398,18 +376,6 @@ This takes up around 2.9 GiB, and needs roughly 2.75 h on kepler.SCHWINGE and +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:446:1: warning: unused parameter 'name' [-Wunused-parameter] +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:452:1: warning: unused parameter 'name' [-Wunused-parameter] - * `gnu/java/net/natPlainSocketImpl.cc` - - libtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] -c gnu/java/net/natPlainSocketImpl.cc [...] - +gnu/java/net/natPlainSocketImpl.cc: In member function 'virtual jint gnu::java::net::PlainSocketImpl::available()': - +gnu/java/net/natPlainSocketImpl.cc:515:27: warning: enumeral and non-enumeral type in conditional expression [enabled by default] - - * `gnu/java/nio/channels/natFileChannelImpl.cc` - - libtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] -c gnu/java/nio/channels/natFileChannelImpl.cc [...] - +gnu/java/nio/channels/natFileChannelImpl.cc: In member function 'jint gnu::java::nio::channels::FileChannelImpl::available()': - +gnu/java/nio/channels/natFileChannelImpl.cc:388:20: warning: enumeral and non-enumeral type in conditional expression [enabled by default] - * `libgcj.la` Just different order of object files, or another problem? @@ -421,21 +387,60 @@ This takes up around 2.9 GiB, and needs roughly 2.75 h on kepler.SCHWINGE and `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions` + * `jar` + + make[2]: Entering directory `[...]/hurd/master.build/[ARCH]/libjava' + -: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=[...]/hurd/master.build/[ARCH]/libjava/scripts/jar" DO=all multi-do + +: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=jar" DO=all multi-do + + Probably because kepler.SCHWINGE has an OpenJDK `/usr/bin/jar`, and + coulomb.SCHWINGE a GCJ one. + + There are other instances of this in the following. + + * *default library search path* + + -checking for the default library search path... /lib /usr/lib /lib/[MULTIARCH] /usr/lib/[MULTIARCH] /lib/i486-linux-gnu /usr/lib/i486-linux-gnu /usr/local/lib /lib64 /usr/lib64 + +checking for the default library search path... /lib /usr/lib + + Should be aligned by Samuel's binutils patch. + + * `value-unwind.h` + + -DEFINES='' HEADERS='../../../master/libgcc/config/i386/value-unwind.h' \ + +DEFINES='' HEADERS='' \ + ../../../master/libgcc/mkheader.sh > tmp-libgcc_tm.h + + Comes from `gcc/config.gcc`: for `i[34567]86-*-linux*` + vs. `i[34567]86-*-*`, but apparently is important only for *x86_64* anyway. + + * `soft-fp` prototypes + + ../../../master/libgcc/soft-fp/eqtf2.c:34:9: warning: no previous prototype for '__eqtf2' [-Wmissing-prototypes] + +../../../master/libgcc/soft-fp/eqtf2.c:50:1: warning: no previous prototype for '__netf2' [-Wmissing-prototypes] + + ../../../master/libgcc/soft-fp/getf2.c:34:9: warning: no previous prototype for '__getf2' [-Wmissing-prototypes] + +../../../master/libgcc/soft-fp/getf2.c:50:1: warning: no previous prototype for '__gttf2' [-Wmissing-prototypes] + + ../../../master/libgcc/soft-fp/letf2.c:34:9: warning: no previous prototype for '__letf2' [-Wmissing-prototypes] + +../../../master/libgcc/soft-fp/letf2.c:50:1: warning: no previous prototype for '__lttf2' [-Wmissing-prototypes] + + * `libatomic` on GNU/Linux compiles several more files than on GNU/Hurd. Is + that correct? Probably futex support. + # Install $ make install 2>&1 | tee log_install [...] -This takes up around 630 MiB, and needs roughly 4 min on kepler.SCHWINGE and 35 +This takes up around 850 MiB, and needs roughly 4 min on kepler.SCHWINGE and 45 min on coulomb.SCHWINGE. ## Analysis - $ ssh kepler.SCHWINGE 'cd tmp/source/gcc/ && cat hurd/master.build/log_install | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/gcc/linux/log_install - $ ssh coulomb.SCHWINGE 'cd tmp/gcc/ && cat hurd/master.build/log_install | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/gcc/hurd/log_install - $ diff -wu <(sed -f toolchain/logs/gcc/linux/log_install.sed < toolchain/logs/gcc/linux/log_install) <(sed -f toolchain/logs/gcc/hurd/log_install.sed < toolchain/logs/gcc/hurd/log_install) > toolchain/logs/gcc/log_install.diff + $ toolchain/logs/process gcc install * `libtool: finish`: `ldconfig` is not run for the Hurd. @@ -445,6 +450,8 @@ min on coulomb.SCHWINGE. `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions` (as above) + * `jar`: as above. + # Testsuite @@ -456,19 +463,16 @@ Testing on GNU/Hurd is blocked on TODO. Can use parallel testing, see [[!message-id "20110331070322.GI11563@sunsite.ms.mff.cuni.cz"]]. - $ make -k check 2>&1 | tee log_check + $ make -k RUNTESTFLAGS=-v check 2>&1 | tee log_check [...] -This needs roughly TODO min on kepler.SCHWINGE and TODO min on -coulomb.SCHWINGE. - - $ ssh kepler.SCHWINGE 'cd tmp/source/gcc/ && cat hurd/master.build/TODO | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/gcc/linux/sum - $ ssh coulomb.SCHWINGE 'cd tmp/gcc/ && cat hurd/master.build/TODO | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/gcc/hurd/sum - $ diff -u -F ^Running toolchain/logs/gcc/linux/sum toolchain/logs/gcc/hurd/sum > toolchain/logs/gcc/sum.diff +This needs roughly 6.5 h on kepler.SCHWINGE and 50.25 h on coulomb.SCHWINGE. ## Analysis + $ toolchain/logs/process gcc test + TODO. diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index b15c880a..61886e08 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -30,24 +30,14 @@ Here's what's to be done for maintaining glibc. <!-- git checkout reviewed -git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -p -C --cc ..sourceware/master +git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..sourceware/master -i -/^commit |^---$|hurd|linux|gs:|__ASSUME +/^commit |^Merge:|^---$|hurd|linux|gs:|__ASSUME --> -Last reviewed up to the [[Git mirror's d40c5d54cb551acba4ef1617464760c5b3d41a14 -(2012-02-28) sources|source_repositories/glibc]]. - - * t/dup3 - - [[tschwinge]] is not convinced that - 22542dcc89805af8d9bd9209129259d2737372b5 (and then also - ff3f3a789ba08b656dbaa3901091b6410bb883f8) are correct. - - * 94b7cc3711b0b74c1d3ae18b9a2e019e51a8e0bf -- dup3 changes; relevant for - `t/dup3`: hidden def. ed690b2f24bbc4d9c541fc81a7c67e6dc5678a96 -- why - not for dup3, too? Because it is a syscall (that is always inlined)? +Last reviewed up to the [[Git mirror's e80d6f94e19d17b91e3cd3ada7193cc88f621feb +(2012-04-05) sources|source_repositories/glibc]]. * `t/hurdsig-fixes` @@ -55,18 +45,10 @@ Last reviewed up to the [[Git mirror's d40c5d54cb551acba4ef1617464760c5b3d41a14 hurdsig.c:1188:26: warning: 'pending' may be used uninitialized in this function [-Wmaybe-uninitialized] hurdsig.c:1168:12: note: 'pending' was declared here - * `t/init-first.c` - - Follow up here: [[!message-id "20070722171859.GN25744@fencepost.gnu.org"]] - or [[!message-id "87mxe4kwws.fsf@gnu.org"]]. Close [[!GNU_Savannah_bug - 17647]]. Debian: [[!message-id "E1Qup1U-0006Zc-39@vasks.debian.org"]] - (part of Ludo's patch; the part that is not harmful to GCC 4.4). - - * `t/kernel-features.h_includes` + * `t/host-independency` - Before running `tg update`, review for additional changes: - - $ git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -p -C --cc -S__ASSUME_ top-bases/t/kernel-features.h_includes..baseline + `libc-alpha` discussion/commit. GCC + c05436a7e361b8040ee899266e15bea817212c37. * `t/sysvshm` @@ -202,11 +184,88 @@ Last reviewed up to the [[Git mirror's d40c5d54cb551acba4ef1617464760c5b3d41a14 `CLOCK_REALTIME_ALARM`, `O_PATH`, `PTRACE_*` (for example, cbff0d9689c4d68578b6a4f0a17807232506ea27), `RLIMIT_RTTIME`, `SEEK_DATA` (`unistd.h`), `SEEK_HOLE` (`unistd.h`) - `clock_adjtime`, `fallocate`, `fallocate64`, `getcontext` (and - `setcontext`), `name_to_handle_at`, `open_by_handle_at`, - `process_vm_readv`, `process_vm_writev`, `sendmmsg`, + `clock_adjtime`, `fallocate`, `fallocate64`, `name_to_handle_at`, + `open_by_handle_at`, `process_vm_readv`, `process_vm_writev`, `sendmmsg`, `setns`, `sync_file_range` + * `chflags` + + IRC, OFTC, #debian-hurd, 2012-04-27: + + <Steap> Does anyone have any idea why int main(void) { return + chflags(); } will compile with gcc but not with g++ ? It says + that "chflags" was not declared in this scope. + <Steap> I get the same error on FreeBSD, but including sys/stat.h + makes it work + <Steap> Can't find a solution on Hurd though :/ + <youpi> the Hurd doesn't have chflags + <youpi> apparently linux neither + <youpi> what does it do? + <Steap> change flags :) + <Steap> Are you sure the Hurd does not have chflags ? Because gcc + does not complain + <youpi> there is no chflags function in /usr/include + <youpi> but what flags does it change? + <Steap> According to the FreeBSD manpage, it can set flags such as + UF_NODUMP, UF_IMMUTABLE etc. + <youpi> Hum, there is actually a chflags() definition + <youpi> but no declaration + <youpi> so actually chflags is supported, but the declaration was + forgotten + <youpi> probably because since linux doens't have it, it has never + been a problem up to now + <youpi> so I'd say ignore the error for now, we'll add the + declaration + + * `getcontext`/`setcontext` + + Needed for [[gccgo]]. + + IRC, freenode, #hurd, 2012-04-19: + + <gnu_srs> How much work/knowledge is needed to implement + getcontext/setcontext? + <gnu_srs> Any already implemented alternatives available? + <youpi> x86 registers knowledge, as well as unix signal masks + <youpi> there's the linux implementation that can be taken as an + exxample, but the signal part has to be rewritten + <gnu_srs> Well, it's a pity they are not implemented. That's the + remaining hurdle to get gccgo working :-( + <youpi> uh :/ + <gnu_srs> Everything builds, but the testsuite fails due to these + missing functions. + <gnu_srs> Regarding getcontext/setcontext they seem to be written + in assembly for linux but the code is not very long. + <gnu_srs> How much effort would it be to write something similar + for Hurd? Anybody fluent in asm? + <gnu_srs> And registers and signals. + <tschwinge> gnu_srs: Signals is the key thing -- everything else we + can probably just copy. I have never/not yet looked at it, + though. + <gnu_srs> For kfreebsd it is written in C: kern_context.c, 3/4 in + one file: getcontext, setcontext, swapcontext, not makecontext. + <gnu_srs> Dunno how much assembly calls used though. + <gnu_srs> Hi, any preferences about implementing get/setcontext in + C or Asm? + <tschwinge> gnu_srs: I think these will have to be implemented in + assembly. Based on the Linux x86 variants. + + IRC, freenode, #hurd, 2012-04-20: + + <tschwinge> youpi: Your understanding of that is better than mine + -- the *context stuff can't be very useful at the moment, because + when the user changes uc_stack.ss_sp (which the glibc tests are + doing), we're losing access to the _hurd_threadvars. Correct? + <tschwinge> At least the getcontext test works, the other get a + SIGILL. + <tschwinge> others + <tschwinge> _hurd_threadvars issue is just guessing. + <youpi> tschwinge: yes, threadvars are on the stack + <youpi> threadvars is not much code, it should just work, but care + has to be taken on the libpthread/libthread side, which does some + initialization + <tschwinge> OK, that at least matches my understanding. + * `syncfs` We should be easily able to implement that one. @@ -264,6 +323,35 @@ Last reviewed up to the [[Git mirror's d40c5d54cb551acba4ef1617464760c5b3d41a14 * `timespec_get` (74033a2507841cf077e31221de2481ff30b43d51) + * `waitflags.h` (`WEXITED`, `WNOWAIT`, `WSTOPPED`, `WCONTINUED`) + + IRC, freenode, #hurd, 2012-04-20: + + <pinotree> in glibc, we use the generic waitflags.h which, unlike + linux's version, does not define WEXITED, WNOWAIT, WSTOPPED, + WCONTINUED + <pinotree> should the generic bits/waitflags.h define them anyway, + since they are posix? + <youpi> well, we'd have to implement them anyway + <youpi> but otherwise, I'd say yes + <pinotree> sure, but since glibc headers should expose at least + everything declared by posix, i thought they should be defined + anyway + <youpi> that might bring bugs + <youpi> some applications might be #ifdefing them + <youpi> and break when they are defined but not working + <pinotree> i guess they would define them to 0, andd having them to + non-zero values shouldn't break them (since those values don't do + anything, so they would act as if they were 0.. or not?) + <youpi> no, I mean they would do something else, not define them to + 0 + <pinotree> like posix/tst-waitid.c, you mean? + <youpi> yes + + For specific packages: + + * [[octave]] + * Create `t/cleanup_kernel-features.h`. * Add tests from Linux kernel commit messages for `t/dup3` et al. @@ -449,16 +537,32 @@ Last reviewed up to the [[Git mirror's d40c5d54cb551acba4ef1617464760c5b3d41a14 edc5984d4d18296d7aa3d8f4ed8f7336a743170e + 57769839788e2c62b68d9dfbf4b35052321278ba. <http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>. - * *baseline* * [low] `conformtest`, 3134156779108fe8b46e0f4cd60d837572faaa93 + 4efeffc1d583597e4f52985b9747269e47b754e2 + - d94a4670800de6e8f088b8630ad5142866127980 -- what does it do for us? + d94a4670800de6e8f088b8630ad5142866127980 -- takes 1.75 h (out of 2.75 h + total) on coulomb.SCHWINGE -- disable? Should probably mirror + `bits/siginfo.h` changes. + * [low] stack guard, 6c6a98c983c44b440ae66d2aa8f32529a9dd7bfe, + [[!message-id "4F3BE241.9090409@mentor.com"]] -- anything needed for + us? + * [low] `libc-lockP.h` 9463518d0d314d7bd0160315e0ef30e15be08985 -- + probably should do similar changes, also to the generic file. + * [low] `bits/socket.h`/`bits/socket_type.h` [[!message-id + "Pine.LNX.4.64.1203090206420.18868@digraph.polyomino.org.uk"]] + 02a6f887cb3e2c048937111eb4cf150d397609de -- probably should do the same + for the generic version as used by GNU Hurd. + * [log] CFI for `_start`, 6a1bd2a100c958d30bbfe8c9b8f9071d24b7c3f4, + [[!message-id "20120316180551.GA6291@host2.jankratochvil.net"]] -- what + about other architectures? + * *baseline* + * [high] `sendmmsg` usage, c030f70c8796c7743c3aa97d6beff3bd5b8dcd5d -- + need a `ENOSYS` stub. # Build Here's a log of a glibc build run; this is from our [[Git repository's -001500ab4e25e6b8cf83eb9539e362ed4803d2c1 (2012-04-05; 2012-02-25) +d7294bbed51242338c4e9c15e1ee74a763259faf (2012-06-21; 2012-03-28) ([[!message-id "878vfhdapq.fsf@schwinge.name"]] applied) sources|source_repositories/glibc]], run on coulomb.SCHWINGE. $ export LC_ALL=C @@ -467,11 +571,11 @@ sources|source_repositories/glibc]], run on coulomb.SCHWINGE. $ make install_root=/INVALID 2>&1 | tee log_build_ [...] -This takes up around 500 MiB and needs roughly X min on kepler.SCHWINGE and 110 -min on coulomb.SCHWINGE (GCC 4.4/4.5/4.6). +This takes up around 500 MiB and needs roughly X min on kepler.SCHWINGE and 100 +min on coulomb.SCHWINGE. <!-- - $ (make install_root=/INVALID && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install_root="$PWD".install install && touch .go-check) 2>&1 | tee log_install && test -f .go-check && ln -s /usr/lib/i386-*gnu/libstdc++.so.6 /lib/i386-*gnu/libpthread-stubs.so.0 /lib/i386-*gnu/libgcc_s.so.1 mach/libmachuser.so.1 hurd/libhurduser.so.0.3 ./ && make -k install_root=/INVALID check TIMEOUTFACTOR=10 2>&1 | tee log_check + $ (make install_root=/INVALID && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install_root="$PWD".install install && touch .go-check) 2>&1 | tee log_install && test -f .go-check && ln -s /usr/lib/i386-*gnu/libstdc++.so.6 /lib/i386-*gnu/libpthread-stubs.so.0 /lib/i386-*gnu/libgcc_s.so.1 mach/libmachuser.so.1 hurd/libhurduser.so.0.3 ./ && make -k install_root=/INVALID check TIMEOUTFACTOR=10 2>&1 | tee log_test Mask out gcc-4.X (with possibly a backslash before the dot), GCC 4.5's column output for (warning, error) messages, GCC 4.6's `[-Wsomething]` or `[enabled by @@ -488,6 +592,8 @@ default]` identifiers which warning flag triggered. ## Analysis + $ toolchain/logs/process gcc build fetch coulomb.SCHWINGE + TODO. * With GCC 4.5, there's a ton of these warnings: @@ -552,6 +658,8 @@ TODO. ../sysdeps/i386/fpu/bits/fenv.h: Assembler messages: ../sysdeps/i386/fpu/bits/fenv.h:125: Warning: translating to `fdivp %st,%st(1)' + Should be fixed as of 2012-04-16. + * baseline fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b introduces: @@ -577,6 +685,8 @@ TODO. pldd-xx.c:26:0: warning: "static_assert" redefined [enabled by default] ../assert/assert.h:119:0: note: this is the location of the previous definition + Should be fixed as of 2012-04-16. + tst-relsort1.c:6:1: warning: function declaration isn't a prototype [-Wstrict-prototypes] @@ -593,6 +703,8 @@ min on coulomb.SCHWINGE. ## Analysis + $ toolchain/logs/process gcc install fetch coulomb.SCHWINGE + TODO. <!-- @@ -607,10 +719,10 @@ TODO. # Testsuite - $ make -k install_root=/INVALID check 2>&1 | tee log_check + $ make -k install_root=/INVALID check 2>&1 | tee log_test [...] -This needs roughly 60 min on coulomb.SCHWINGE. +This needs roughly X h on kepler.SCHWINGE and 2.75 h on coulomb.SCHWINGE. <!-- $ ssh kepler.SCHWINGE 'cd tmp/source/gdb/ && sed < hurd/master.build/gdb/testsuite/gdb.sum -e "s%\(/media/data\)\?${PWD}%[...]%g"' > open_issues/gdb/sum_linux @@ -626,13 +738,15 @@ Comparing the results files, [[sum_linux]] to [[sum_hurd]]: ## Analysis + $ toolchain/logs/process gcc test fetch coulomb.SCHWINGE + There is quite a baseline of failures. ### Additional Failures Compared to Debian - $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/convertlog.sh log_check > log_check.filtered - $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/compare.sh ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/expected-results-i486-gnu-libc log_check.filtered + $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/convertlog.sh log_test > log_test.filtered + $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/compare.sh ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/expected-results-i486-gnu-libc log_test.filtered * `bug-atexit3.out`, `debug/tst-chk4`, `debug/tst-chk5`, `debug/tst-chk6`, `debug/tst-lfschk4`, `debug/tst-lfschk5`, `debug/tst-lfschk6` @@ -748,6 +862,12 @@ There is quite a baseline of failures. Fails sometimes (is listed in Debian eglibc-2.13-21's `expected-results-i486-gnu-libc`). + * `elf/tst-unused-dep.out` (1f393a11f65dcaa1952bdcaf0317a65a5f8aff9d, + [[!sourceware_bug 13706]], [[!message-id "4F4210C1.1090704@redhat.com"]]) + + Unused direct dependencies: + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.6-486/dlfcn/libdl.so.2 + ## OLD 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/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/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index f8e27e62..9feb30c8 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -2116,3 +2116,20 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task. remember) <braunr> use "physical" instead of "real memory" <mcsim> braunr: thank you. + + +# IRC, freenode, #hurd, 2012-04-22 + + <braunr> youpi: tschwinge: when the slab code was added, a few new files + made into gnumach that come from my git repo and are used in other + projects as well + <braunr> they're licensed under BSD upstream and GPL in gnumach, and though + it initially didn't disturb me, now it does + <braunr> i think i should fix this by leaving the original copyright and + adding the GPL on top + <youpi> sure, submit a patch + <braunr> hm i have direct commit acces if im right + <youpi> then fix it :) + <braunr> do you want to review ? + <youpi> I don't think there is any need to + <braunr> ok diff --git a/open_issues/gnumach_page_cache_policy.mdwn b/open_issues/gnumach_page_cache_policy.mdwn new file mode 100644 index 00000000..75fcdd88 --- /dev/null +++ b/open_issues/gnumach_page_cache_policy.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_gnumach]] + + +# IRC, freenode, #hurd, 2012-04-26 + + <braunr> another not-too-long improvement would be changing the page cache + policy + <youpi> to drop the 4000 objects limit, you mean ? + <braunr> yes + <youpi> do you still have my patch attempt ? + <braunr> no + <youpi> let me grab that + <braunr> oh i won't start it right away you know + <braunr> i'll ask for it when i do + <youpi> k + <braunr> (otherwise i fell i'll just loose it again eh) + <youpi> :) + <braunr> but i imagine it's not too hard to achieve + <youpi> yes + <braunr> i also imagine to set a large threshold of free pages to avoid + deadlocks + <braunr> which will still be better than the current situation where we + have either lots of free pages because tha max limit is reached, or lots + of pressure and system freezes :/ + <youpi> yes diff --git a/open_issues/gnumach_rpc_timeouts.mdwn b/open_issues/gnumach_rpc_timeouts.mdwn new file mode 100644 index 00000000..68cfcb5a --- /dev/null +++ b/open_issues/gnumach_rpc_timeouts.mdwn @@ -0,0 +1,19 @@ +[[!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_gnumach]] + + +# IRC, freenode, #hurd, 2012-04-28 + + <pinotree> uhm, apparently mach cannot handle timeouts for rpc's of more + than (2^(sizeof(mach_msg_timeout_t) * 8) - 1) / HZ + <pinotree> it seems that how ticks are calculated in mach, it becomes 0 + <pinotree> +because of diff --git a/open_issues/gnumach_vm_map_red-black_trees.mdwn b/open_issues/gnumach_vm_map_red-black_trees.mdwn new file mode 100644 index 00000000..17263099 --- /dev/null +++ b/open_issues/gnumach_vm_map_red-black_trees.mdwn @@ -0,0 +1,154 @@ +[[!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_gnumach]] + + +# IRC, freenode, #hurd, 2012-04-23 + + <braunr> btw, i'm running a gnumach version using red-black trees for vm + map entries + <antrik> braunr: sounds fashionable ;-) + <youpi> braunr: with some perf improvement? + <braunr> looks promising for our ext2fs instances showing several thousands + of map entries + <braunr> youpi: i'm not using it for lookups yet + <braunr> but the tree is there, maintained, used for both regular and copy + maps, and it doesn't crash + <youpi> good :) + <braunr> antrik: isn't it ? :) + <braunr> youpi: and the diff stat is like 50/15 + <antrik> braunr: what's the goal of using the fashionable trees? + <braunr> antrik: speeding up lookups in address spaces + <antrik> braunr: so the idea is that if we have a heavily fragmented + address space, the performance penalty is smaller? + <braunr> yes + <antrik> OK + <antrik> I take it you gave up on attempts to actually decrease + fragmentation?... + <braunr> it's not as good as reducing fragmentation, which requires + implementing a powerful merge, but it's still better + <braunr> yes + <braunr> it's too messy for my brain :/ + <antrik> I see + <antrik> oh + <braunr> it will add some overhead though + <youpi> I guess log(n) ? + <braunr> but if there is a significant performance gain, it'll be worth it + <braunr> yes + <braunr> i was more thinking about the memory overhead + <antrik> right now it's a linear list? + <youpi> I don't think we care nowadays :) + <braunr> antrik: yes + <antrik> ouch + <braunr> antrik: yes ... :> + <braunr> the original authors expected vm maps to have like 30 entries + <braunr> so they used a list for the maps, and a hash table for the + object/offset to physical page lookups + <braunr> there is a small lookup cache though, which is a nice optimization + <braunr> my code now uses it first, and falls back to the RB tree if the + hint didn't help + <antrik> braunr: well, don't forget to check whether it actually *is* still + an optimisation, when using fashionable trees ;-) + <braunr> antrik: i checked that already :) + <braunr> i did the same in x15 + <antrik> I see + <braunr> both bsd and linux uses a similar technique + <braunr> use* + <braunr> (well, bsd actually use what is done in mach :) + <antrik> (or perhaps the other way around... ;-) ) + <braunr> i don't think so, as the bsd vm is really the mach vm + <braunr> but we don't care much + <antrik> oh, right... that part actually went full circle + <braunr> youpi: i have a patch ready for test on machines with significant + amounts of map entries (e.g. the buildds ..) + <braunr> youpi: i won't have time for tests tonight, are you interested ? + <braunr> (i've been running it for 15 minutes without any issue for now) + <youpi> I'd say post to the list + <braunr> ok + <youpi> braunr: your patch uses the rb tree for lookups, right? + <youpi> braunr: the buildd using rbtree seems swift + <youpi> but maybe it's just a psychologic effect :) + <youpi> the chroot ext2fs already has 1392 lines in vminfo + <youpi> an rbtree can't hurt there :) + <youpi> braunr: it really seems faster + <youpi> the reboot might have helped too + <youpi> benchmarks shall say + <youpi> for now, I'll just let ironforge use it + <antrik> youpi: it's always fast after a reboot ;-) + <youpi> sure + <youpi> but still + <youpi> I mean + <youpi> *obviously* the reboot has helped + <youpi> but it might not be all + <youpi> at least it feels so + <youpi> and obviously only benchmarks can say + <antrik> the major benefit AIUI is rather that the slowdown happening over + time will be less noticable + +[[performance/degradation]]. + + <youpi> "over time" is actually quite fast + <youpi> ext2 fills up very quickly when you build a package + <youpi> it went up to 1700 lines very quickly + <youpi> and stabilized around there + <antrik> yeah, it can be very fast under heavy load + <youpi> that's why I say reboot seems not all + <youpi> it's already not so fresh + <youpi> with 1700 lines in vminfo + <antrik> well, I don't know how much of the slowdown I'm experiencing + (after doing stuff under memory pressure) is actually related to VM map + fragmentation... + <antrik> might be all, might be none, might be something in between + <youpi> then try his patch + <antrik> guess I should play a bit with vminfo... + <antrik> well, currently I actually experience pretty little slowdown, as + for certain reasons (only indirectly related to the Hurd) I'm not running + mutt on this machine, so I don't really have memory pressure... + + +## IRC, freenode, #hurd, 2012-04-24 + + <braunr> youpi: yes, it uses bst lookups + <braunr> youpi: FYI, the last time i checked, one ext2fs instance had 4k+ + map entries, and another around 7.5k + <braunr> (on ironforge) + + +## IRC, freenode, #hurd, 2012-04-24 + + <youpi> braunr: $ sudo vminfo 624 | wc -l + <youpi> 22957 + <youpi> there's no way it can not help :) + <braunr> youpi: 23k, that's really huge + + +## IRC, freenode, #hurd, 2012-04-26 + + <braunr> youpi: any new numbers wrt the rbtree patch ? + <youpi> well, buildd times are not really accurate :) + <youpi> but what I can tell is that it managed to build qtwebkit fine + <braunr> ok + <youpi> so the patch is probably safe :) + <braunr> i'll commit it soon then + <youpi> I'd say feel free to, yes + <braunr> thanks + + +## IRC, freenode, #hurd, 2012-04-27 + + <braunr> elmig: don't expect anything grand though, this patch is mostly + useful when address spaces get really fragmented, which mainly happens on + buildds + <braunr> (and it only speeds lookups, which isn't as good as reducing + fragmentation; things like fork still have to copy thousands of map + entries) + +[[glibc/fork]]. diff --git a/open_issues/largefile.mdwn b/open_issues/largefile.mdwn new file mode 100644 index 00000000..a6f76a0e --- /dev/null +++ b/open_issues/largefile.mdwn @@ -0,0 +1,21 @@ +[[!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_hurd]] + + +# IRC, freenode, #hurd, 2012-04-26 + + <pinotree> i kind of understood why (at least in some parts) largefile doesn't seem to work properly + <pinotree> libdiskfs/io-seek.c, SEEK_SET case: cred->po->filepointer = offset; + <pinotree> offset is off_t, which becomes off64_t when compiled with largefile, but filepointer seems to be... int + <pinotree> at least in libdiskfs/diskfs.h, while in libnetfs/netfs.h seems ok (loff_t) + <pinotree> diskfs.h is a public header though :/ + <youpi> well, we can change the soname to mark ABI change diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn index 614f1271..c5054b7f 100644 --- a/open_issues/libpthread.mdwn +++ b/open_issues/libpthread.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 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 @@ -25,43 +26,19 @@ There is a [[!FF_project 275]][[!tag bounty]] on this task. [[!inline pages=community/gsoc/project_ideas/pthreads feeds=no]] +## IRC, freenode, #hurd, 2012-04-26 -# pthread/stubs issue w/ dlopen'ed libraries + <pinotree> youpi: just to be sure: even if libpthread is compiled inside + glibc (with proper symbols forwarding etc), it doesn't change that you + cannot use both cthreads and pthreads in the same app, right? -IRC, freenode, #hurd, 2010-01-24 +[[Packaging_libpthread]]. - <pinotree> youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed - libraries - <pinotree> currently looks like libstdc++ on hurd links to pthread-stubs, - we're the only one with such configuration - <pinotree> i was looking at the gcc 4.4 patch hurd-pthread.diff, could it - be it does not set THREADLIBS in the configure.ac switch case? - <youpi> that's expected - <youpi> on linux the libc provides hooks itself, on hurd-i386 it's - pthread-stubs - <pinotree> why not explicitly link to pthread though? - <youpi> because there is no strict need to, for applications that don't - need libpthread - <youpi> the dlopen case is a tricky case that pthread-stubs had not thought - about - <pinotree> hm - <pinotree> what if the pthread stubs would be moved in our glibc? - <youpi> that's what we should do yes - <youpi> (ideally) - <youpi> but for this we need to build libpthread along glibc, to get it - really working - <youpi> and that's the tricky part (Makefile & such) which hasn't been done - yet - <pinotree> why both (stubs + actual libpthread)? - <youpi> because you need the stubs to be able to call the actual libpthread - <youpi> as soon libpthread gets dlopened for instance - <youpi> +as - <pinotree> i see - <youpi> (remember that nptl does this if you want to see how) - <youpi> (it's the libc files in nptl/) - <youpi> (and forward.c) - <guillem> also if libpthreads gets integrated with glibc don't we need to - switch the hurd from cthreads then? Which has been the blocker all this - time AFAIR? - <youpi> we don't _need_ to - <guillem> ok + <youpi> it's the same libpthread + <youpi> symbol forwarding does not magically resolve that libpthread lacks + some libthread features :) + <pinotree> i know, i was referring about the clash between actively using + both + <youpi> there'll still be the issue that only one will be initialized + <youpi> and one that provides libc thread safety functions, etc. + <pinotree> that's what i wanted to knew, thanks :) diff --git a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn new file mode 100644 index 00000000..f9195540 --- /dev/null +++ b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn @@ -0,0 +1,58 @@ +[[!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="libpthread: CLOCK_MONOTONIC"]] + +[[!tag open_issue_glibc open_issue_libpthread]] + +[[!message-id "201204220058.37328.toscano.pino@tiscali.it"]] + + +# IRC, freenode, #hurd- 2012-04-22 + + <pinotree> youpi: what i thought would be creating a + glib/hurd/hurdtime.{c,h}, adding _hurd_gettimeofday and + _hurd_clock_{gettime,settime,getres} to it and making the current .c in + sysdeps call those + <youpi> yep + <youpi> that's unfortunate, but that's what nptl actually does + <pinotree> this way we could add inside hurdtime.c the mapped time stuff + too + <pinotree> most probably a noobish question, but why does rt link to + pthread? + <youpi> no idea :) + <youpi> possibly due to aio implementation + <youpi> ./sysdeps/pthread/aio_cancel.c + <youpi> probably due to that + <youpi> (and others) + + +## IRC, freenode, #hurd- 2012-04-23 + + <youpi> pinotree: about librt vs libpthread, don't worry too much for now + <youpi> libpthread can lib against the already-installed librt + <youpi> it does work + <pinotree> youpi: wouldn't that cause a dependency loop? + <youpi> pinotree: what dependency loop? + <pinotree> youpi: librt wouldd link to pthread, no? + <youpi> and ? + <youpi> I don't think it's an issue that .so link with each other + <pinotree> it isn't? + <youpi> well, try + * pinotree never did that + <youpi> but I don't think it will pose problem + <youpi> well, perhaps initialization order + <youpi> anyway, I now have packages built, I'll test that + <youpi> pinotree: ok, it seems it doesn't work indeed :) + <youpi> early in initialization + <youpi> pinotree: the initialization bug might actually not be due to librt + at all + <youpi> pinotree: yes, things work even with -lrt + <pinotree> wow diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn index fb665c67..05a07ef2 100644 --- a/open_issues/libpthread_dlopen.mdwn +++ b/open_issues/libpthread_dlopen.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!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 @@ -10,7 +10,52 @@ License|/fdl]]."]]"""]] [[!tag open_issue_libpthread]] -IRC, OFTC, #debian-hurd, 2011-07-21. +[[!toc]] + + +# IRC, freenode, #hurd, 2010-01-24 + + <pinotree> youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed + libraries + <pinotree> currently looks like libstdc++ on hurd links to pthread-stubs, + we're the only one with such configuration + <pinotree> i was looking at the gcc 4.4 patch hurd-pthread.diff, could it + be it does not set THREADLIBS in the configure.ac switch case? + <youpi> that's expected + <youpi> on linux the libc provides hooks itself, on hurd-i386 it's + pthread-stubs + <pinotree> why not explicitly link to pthread though? + <youpi> because there is no strict need to, for applications that don't + need libpthread + <youpi> the dlopen case is a tricky case that pthread-stubs had not thought + about + <pinotree> hm + <pinotree> what if the pthread stubs would be moved in our glibc? + <youpi> that's what we should do yes + <youpi> (ideally) + <youpi> but for this we need to build libpthread along glibc, to get it + really working + +[[Packaging_libpthread]]. + + <youpi> and that's the tricky part (Makefile & such) which hasn't been done + yet + <pinotree> why both (stubs + actual libpthread)? + <youpi> because you need the stubs to be able to call the actual libpthread + <youpi> as soon libpthread gets dlopened for instance + <youpi> +as + <pinotree> i see + <youpi> (remember that nptl does this if you want to see how) + <youpi> (it's the libc files in nptl/) + <youpi> (and forward.c) + <guillem> also if libpthreads gets integrated with glibc don't we need to + switch the hurd from cthreads then? Which has been the blocker all this + time AFAIR? + <youpi> we don't _need_ to + <guillem> ok + + +# IRC, OFTC, #debian-hurd, 2011-07-21 <youpi> there's one known issue with pthreads <youpi> you can't dlopen() it diff --git a/open_issues/o_exec.mdwn b/open_issues/o_exec.mdwn new file mode 100644 index 00000000..3f77a0f2 --- /dev/null +++ b/open_issues/o_exec.mdwn @@ -0,0 +1,54 @@ +[[!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="O_EXEC"]] + +[[!tag open_issue_glibc open_issue_hurd]] + + +# IRC, freenode, #hurd, 2012-04-24 + + <pinotree> interesting, glibc on every OS except hurd (so including linux + too) does not define O_EXEC + <pinotree> can somebody please help me understand a POSIX behaviour? + <pinotree> it's about fexecve: + http://pubs.opengroup.org/onlinepubs/9699919799/functions/fexecve.html + <pinotree> basically, it seems to me (reading the "errors" and "application + usage" sections) that O_EXEC for open() the fd is not mandatory, and if + not used fexecve will check for file permission at call time? + <pinotree> because currently libdiskfs and libnetfs require the fd to be + open with O_EXEC + <braunr> "Since execute permission is checked by fexecve(), the file + description fd need not have been opened with the O_EXEC flag" + <braunr> this one makes it clear checking for O_EXEC is wrong + <braunr> it looks like O_EXEC is only needed when you want to have files + for which only the execution permission is set + <braunr> but not the read one + <braunr> (i don't understand the "and write" part though) + <braunr> "exec will fail if the mode of the file associated with fd does + not grant execute permission to the calling process at the time fexecve() + is called." + <braunr> this one strengthens the impression you have, that fexecve indeed + checks file permissions at the time it's called + <braunr> pinotree: hope it helps + <pinotree> so it implies the following: + <pinotree> O_RDONLY → exec works if the file is readable + <braunr> exec works if the file is readable and/or executable (although + without read permissions you can't check it) + <braunr> (well, fexecve) + <pinotree> O_EXEC → exec requires that the permission of the file at + fexecve() time have +x + <braunr> i'd say ye so far + <braunr> yes + <pinotree> so we need to fix lib{disk,net}fs then + <braunr> seems so + <pinotree> enlighting, merci braunr + <braunr> de rien + <pinotree> :) diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn index fa3d4312..d243aaaa 100644 --- a/open_issues/packaging_libpthread.mdwn +++ b/open_issues/packaging_libpthread.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 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 @@ -10,9 +11,13 @@ License|/fdl]]."]]"""]] [[!tag open_issue_libpthread open_issue_glibc]] -IRC, #hurd, 2010-07-31 +[[!toc]] - <tschwinge> My idea was to have a separate libpthread package. What do you think about that? + +# IRC, freenode, #hurd, 2010-07-31 + + <tschwinge> My idea was to have a separate libpthread package. What do you + think about that? <youpi> in the long term, that can't work with glibc <youpi> because of the thread stub stuff @@ -21,30 +26,114 @@ IRC, #hurd, 2010-07-31 <youpi> it's not really possible to keep synchronized <youpi> because you have to decide which package you unpack first <youpi> (when upgrading) - <tschwinge> Hmm, how is that different if two shared libraries are in one package vs. two packages? It isn't atomic either way? Aren't sonames / versioned library packages solving that? + <tschwinge> Hmm, how is that different if two shared libraries are in one + package vs. two packages? It isn't atomic either way? Aren't sonames / + versioned library packages solving that? <tschwinge> ... for incompatible forward changes? <youpi> that'd be a mess to maintain - <youpi> Drepper doesn't have this constraint and thus adds members of private fields at will - <tschwinge> OK, but how is it different then if the libpthread is in the Hurd package? + <youpi> Drepper doesn't have this constraint and thus adds members of + private fields at will + <tschwinge> OK, but how is it different then if the libpthread is in the + Hurd package? <youpi> I'm not saying it's better to have libpthread in the Hurd package <tschwinge> OK. - <youpi> I'm saying it's useless to package it separately when Drepper makes everything to have us put it along glibc + <youpi> I'm saying it's useless to package it separately when Drepper makes + everything to have us put it along glibc <tschwinge> Then, to goal is to have it in glibc? <tschwinge> OK. :-) - <tschwinge> OK, I can accommodate to that. Isn't not that we'd want to switch libpthread to something else so quickly. - <tschwinge> So our official goal is to have libpthread in glibc, at least for Debian purposese? + <tschwinge> OK, I can accommodate to that. Isn't not that we'd want to + switch libpthread to something else so quickly. + <tschwinge> So our official goal is to have libpthread in glibc, at least + for Debian purposese? <youpi> for any port purpose <tschwinge> Ack. - <youpi> provided you're using glibc, you're deemed to ship libpthread with it + <youpi> provided you're using glibc, you're deemed to ship libpthread with + it <youpi> because of the strong relations Drepper puts between them - <youpi> (just to remind: we already have bugs just because our current libpthread isn't bound enough to glibc: dlopen()ing a library depending on libpthread doesn't work, for instance) - <pinotree> yeah, pthread-stubs is linked to almost everywhere -lpthread isn't used + <youpi> (just to remind: we already have bugs just because our current + libpthread isn't bound enough to glibc: dlopen()ing a library depending + on libpthread doesn't work, for instance) + <pinotree> yeah, pthread-stubs is linked to almost everywhere -lpthread + isn't used <pinotree> (would be nice to not have those issues anymore...) - <tschwinge> So -- what do we need to put it into glibc? We can make libpthread a Git submodule (or move the code; but it's shared also for Neal's viengoos, so perhaps the submodule is better?), plus some glibc make foo, plus some other adaptions (stubs, etc.) - <tschwinge> Does that sound about right, or am I missing something fundamental? + <tschwinge> So -- what do we need to put it into glibc? We can make + libpthread a Git submodule (or move the code; but it's shared also for + Neal's viengoos, so perhaps the submodule is better?), plus some glibc + make foo, plus some other adaptions (stubs, etc.) + <tschwinge> Does that sound about right, or am I missing something + fundamental? <youpi> I actually don't know what a git submodule permits :) <youpi> looks like a good thing for this, yes - <tschwinge> Unfortunately I can't allocate much time at the moment to work on this. :-/ - <youpi> well, as long as I know where we're going, I can know how to package stuff in Debian - <tschwinge> That sounds like a plan to me. libpthread -> glibc as submodule. - <youpi> (note: actually, the interface between glibc and the libpthread is the responsibility of the libpthread: it gives a couple of .c files to be shipped in libc.so) + <tschwinge> Unfortunately I can't allocate much time at the moment to work + on this. :-/ + <youpi> well, as long as I know where we're going, I can know how to + package stuff in Debian + <tschwinge> That sounds like a plan to me. libpthread -> glibc as + submodule. + <youpi> (note: actually, the interface between glibc and the libpthread is + the responsibility of the libpthread: it gives a couple of .c files to be + shipped in libc.so) + + +# IRC, freenode, #hurd, 2012-04-21 + + <youpi> had you tried to build libpthread as a glibc addon? + <tschwinge> youpi: No, I only know about libpthread in Hurd build system, + and libpthread stand-alone (with the Auto* stuff that I added), but not + yet as a glibc add-on. + <youpi> k + <youpi> I'm trying it atm + <tschwinge> Oh, OK. + <youpi> that should fix the no-add-needed issue in gcc/binutils, as well as + the pthread_threads assertion errors in threaded plugins + <youpi> (once I add forward.c, but that part should not be hard) + <pinotree> that means also less use of pthread-stubs^ + <pinotree> ? + <youpi> tschwinge: do you remember whether sysdeps/mach/bits/spin* are used + by anybody? + <youpi> they are half-finished (no __PTHREAD_SPIN_LOCK_INITIALIZER), and + come in the way when building in glibc + <youpi> also, any reason for using ia32 and not i386? glibc uses the latter + <youpi> pinotree: rid of pthread-stubs yes + <pinotree> \o/ + <tschwinge> youpi: You mean sysdeps/mach/i386/machine-lock.h? No idea + about that one, sorry. + <youpi> I'm talking about libpthread + <youpi> not glibc + <tschwinge> Oh. + <tschwinge> sysdeps/ia32/bits/spin-lock.h:# define + __PTHREAD_SPIN_LOCK_INITIALIZER ((__pthread_spinlock_t) 0) + <tschwinge> Anyway, no idea about that either. + <youpi> that one is meant to be used with the spin-lock.h just below + <youpi> +-inline + <youpi> also, I guess signal/ was for the l4 port? + <tschwinge> youpi: I guess so. + <youpi> tschwinge: I have an issue with sysdeps pt files: + sysdeps/hurd/pt-getspecific.c is not looked for by libc ; symlinking into + sysdeps/mach/hurd/pt-getspecific.c works + <youpi> we don't have a non-mach sysdeps directory? + <pinotree> youpi: if you add sysdeps/mach/hurd/Implies containing only + "hurd", does sysdeps/hurd work? + <youpi> ah, right + <pinotree> youpi: did it work? (and, it was needed in sysdeps/mach/hurd, or + in libpthread/sysdeps/mach/hurd?) + <youpi> pinotree: it worked, it was for libpthread + <youpi> good: I got libpthread built and forward working + + +## IRC, freenode, #hurd, 2012-04-23 + + <youpi> phew + <youpi> confirmed that moving libpthread to glibc fixes the gcc/binutils + no-add-needed issue + + +## IRC, freenode, #hurd, 2012-04-27 + + <pinotree> youpi: wouldn't be the case to rename ia32 subdirs to i386 in + libpthread? + <pinotree> after all, Makefile hardcodes it, Makefile.am sets the variable + for it, and glibc expects i386 + <youpi> I know, I've asked tschwinge about it + <youpi> it's not urging anyway + <pinotree> right diff --git a/open_issues/settrans_directory_symlink.mdwn b/open_issues/settrans_directory_symlink.mdwn new file mode 100644 index 00000000..86148a52 --- /dev/null +++ b/open_issues/settrans_directory_symlink.mdwn @@ -0,0 +1,52 @@ +[[!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_hurd]] + +This works: + + $ touch a && settrans a /hurd/symlink b + +This doesn't: + + $ mkdir a && settrans a /hurd/symlink b + settrans: a: Is a directory + +It's the same `file_set_translator` RPC both times, and it's [[translator +short-circuiting|hurd/translator/short-circuiting]] which makes the latter one +fail: + +`libdiskfs/file-set-trans.c`: + + [...] + /* Set passive translator */ + if (passive_flags & FS_TRANS_SET) + { + if (!(passive_flags & FS_TRANS_FORCE)) + { + /* Handle the short-circuited translators */ + mode_t newmode = 0; + + if (diskfs_shortcut_symlink && !strcmp (passive, _HURD_SYMLINK)) + newmode = S_IFLNK; + [...] + + if (newmode) + { + if (S_ISDIR (np->dn_stat.st_mode)) + { + /* We can't allow this, because if the mode of the directory + changes, the links will be lost. Perhaps it might be + allowed for empty directories, but that's too much of a + pain. */ + mutex_unlock (&np->lock); + return EISDIR; + } + [...] diff --git a/open_issues/system_call_mechanism.mdwn b/open_issues/system_call_mechanism.mdwn index 5598148c..68418097 100644 --- a/open_issues/system_call_mechanism.mdwn +++ b/open_issues/system_call_mechanism.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!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 @@ -10,8 +10,47 @@ License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] -IRC, freenode, #hurd, 2011-05-07 +[[!toc]] + + +# IRC, freenode, #hurd, 2011-05-07 <braunr> very simple examples: system calls use old call gates, which are the slowest path to kernel space <braunr> modern processors have dedicated instructions now + + +# IRC, freenode, #hurd, 2012-04-22 + + <braunr> rah: basically, system calls are slower on mach because they use + call gates instead of newer sysenter/sysexit + <youpi> braunr: sysenter/exit is a x86_64 thing + <braunr> rah: apart from that, the code can't get much simpler, and *I* + know, for i have studied it, and wrote a compatible version in a clone + attempt + <youpi> braunr: on a x86_64 port we'd probably use sysenter/exit + <braunr> youpi: no there are 32-bits instructions, i don't remember if + they're called sysenter, it's in my thesis though so i'm sure of it :) + <youpi> braunr: ah, the other part + <youpi> is linux-x86 using them? + <braunr> youpi: yes, glibc uses them + <youpi> and does it really change much nowadays? + <youpi> what is the actual difference between int 80 and sysenter? + <braunr> less checking + <youpi> checking what? + <youpi> the idt? + <braunr> ring levels for example + <youpi> well, checking a ring is fast :) + <braunr> depending on the original and requested levels, there are lookups + in tables + <braunr> sysenter always assume 3 to 0 and 0 to 3 for sysexit + <youpi> ah, also it assumes things about segments + <youpi> so that indeed makes context things simpler + <braunr> right + <braunr> but mach doesn't uses int 0x80 + <braunr> it uses an lcall + <braunr> which is a bit slower from what I could read some time ago + <braunr> (not sure if it's still relevant) + <youpi> actually in 64bit mode I had to catch lcall from the invalid + instruction trap + <youpi> perhaps it got dropped in 64bit mode diff --git a/open_issues/user-space_device_drivers.mdwn b/open_issues/user-space_device_drivers.mdwn index 70c3c6dc..25168fce 100644 --- a/open_issues/user-space_device_drivers.mdwn +++ b/open_issues/user-space_device_drivers.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2009, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 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 @@ -64,7 +65,7 @@ Also see [[device drivers and IO systems]]. ## System Boot -IRC, freenode, #hurd, 2011-07-27 +### IRC, freenode, #hurd, 2011-07-27 < braunr> btw, was there any formulation of the modifications required to have disk drivers in userspace ? @@ -88,6 +89,11 @@ IRC, freenode, #hurd, 2011-07-27 < Tekk_> mhm < braunr> s/disk/storage/ +### IRC, freenode, #hurd, 2012-04-25 + + <youpi> btw, remember the initrd thing? + <youpi> I just came across task.c in libstore/ :) + # Plan |