Merge remote-tracking branch 'feldtkeller.SCHWINGE/master'

10 files changed, 160 insertions, 238 deletions

diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index 9d486b00..e3d2700d 100644
--- a/community/gsoc/project_ideas.mdwn
+++ b/community/gsoc/project_ideas.mdwn
@@ -110,6 +110,7 @@ other: language_bindings, gnat, gccgo, perl_python.  -->
 [[!inline pages="community/gsoc/project_ideas/libcap" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/xattr" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/valgrind" show=0 feeds=no actions=yes]]
+[[!inline pages="community/gsoc/project_ideas/gcc_asan" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/driver_glue_code" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/dtrace" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/libdiskfs_locking" show=0 feeds=no actions=yes]]
diff --git a/open_issues/binutils_gold.mdwn b/community/gsoc/project_ideas/gcc_asan.mdwn
index 9eeebf2d..229c46ec 100644
--- a/open_issues/binutils_gold.mdwn
+++ b/community/gsoc/project_ideas/gcc_asan.mdwn
@@ -1,5 +1,4 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation,
-Inc."]]
+[[!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
@@ -9,8 +8,14 @@ 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_binutils open_issue_porting]]
+[[!meta title="Port GCC's AddressSanitizer to the Hurd"]]
 
-Have a look at gold / port as needed.
+[[!tag open_issue_gcc]]
 
-Apparently it needs [[glibc/mremap]].
+See the entry on the [[open_issues/code_analysis]] page.
+
+See also the [[valgrind]] task.
+
+A follow-up project is porting GCC's ThreadSanitizer.
+
+Possible mentors: Thomas Schwinge (tschwinge)
diff --git a/open_issues/automatic_backtraces_when_assertions_hit.mdwn b/open_issues/automatic_backtraces_when_assertions_hit.mdwn
index f6bf5856..df7294e9 100644
--- a/open_issues/automatic_backtraces_when_assertions_hit.mdwn
+++ b/open_issues/automatic_backtraces_when_assertions_hit.mdwn
@@ -76,4 +76,4 @@ In context of the [[ext2fs_libports_reference_counting_assertion]].
 
 # GCC's libbacktrace
 
-Introduced in commit ecd3459e7bb829202601e3274411135a15c64dde.
+Introduced in GCC commit ecd3459e7bb829202601e3274411135a15c64dde.
diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn
index eec5154f..5c309d47 100644
--- a/open_issues/binutils.mdwn
+++ b/open_issues/binutils.mdwn
@@ -33,14 +33,14 @@ though, as explained below.
 <!--
 
 git checkout reviewed
-git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -p -C --cc ..sourceware/master
+git log --reverse --topo-order --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..sourceware/master
 -i
-/^commit |^---$|hurd|linux|nacl
+/^commit |^merge:|^---$|hurd|linux|nacl|nptl|glibc|gs:
 
 -->
 
-Last reviewed up to the [[Git mirror's dde164167b2db4c05d58b1941d610beb6d5ca99f
-(2012-06-08) sources|source_repositories/binutils]].
+Last reviewed up to the [[Git mirror's 7c102198e4a1ecee9cf175bd4ad87ee435956cae
+(2012-12-16) sources|source_repositories/binutils]].
 
   * Globally
 
@@ -114,16 +114,20 @@ Last reviewed up to the [[Git mirror's dde164167b2db4c05d58b1941d610beb6d5ca99f
             Compare to `i[3-7]86-*-linux-*`, but don't need a.out (`i386linux`)
             and 64 bit support.
 
+  * `__ehdr_start symbol`, c84ed8d89d0b8bf5a2968d465f77ac24bcfc40c2 -- can this
+    be helpful in the exec server, glibc, or elsewhere?  Used in GDB (BFD)
+    commit bdbd9758806ed855af89244870fdc52cf3ff09bc.
+
 
 # Build
 
-Here's a log of a binutils build run; this is from our [[Git repository's
-e1104996559067c40207c803ab1a5847a4a05145 (2012-06-07)
-sources|source_repositories/binutils]], run on kepler.SCHWINGE and
-coulomb.SCHWINGE.
+Here's a log of a binutils build run; this is from our [[Git
+repository|source_repositories/binutils]]'s `tschwinge/Paul_Desmond` branch,
+commit 7c102198e4a1ecee9cf175bd4ad87ee435956cae (2012-12-16), run on
+kepler.SCHWINGE and coulomb.SCHWINGE.
 
     $ export LC_ALL=C
-    $ ../master/configure --prefix="$PWD".install --with-sysroot=/ SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 2>&1 | tee log_build
+    $ ../Paul_Desmond/configure --prefix="$PWD".install --enable-gold --with-sysroot=/ SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 2>&1 | tee log_build
     [...]
     $ make 2>&1 | tee log_build_
     [...]
@@ -133,8 +137,8 @@ harmonized.  Debian GCC (which is used in binutils' testsuite) likes to pass
 `--sysroot=/` to `ld`, so we need to configure binutils with support for
 sysroots.
 
-This takes up around 120 MiB, and needs roughly 4 min on kepler.SCHWINGE and
-15 min on coulomb.SCHWINGE.
+This takes up around 900 MiB, and needs roughly 11 min on kepler.SCHWINGE and
+42 min on coulomb.SCHWINGE.
 
 <!--
 
@@ -151,13 +155,20 @@ formats, and more emulation vectors.
 
     $ toolchain/logs/process binutils build
 
+  * gold GNU/Linux vs. GNU/Hurd
+
+        -checking for glibc ifunc support... both
+        +checking for glibc ifunc support... dyn
+
+    Missing [[IFUNC]] support on GNU/Hurd.
+
 
 # Install
 
     $ make install 2>&1 | tee log_install
     [...]
 
-This takes up around 70 MiB, and needs roughly 1 min on kepler.SCHWINGE and 3
+This takes up around 150 MiB, and needs roughly 1 min on kepler.SCHWINGE and 3
 min on coulomb.SCHWINGE.
 
 
@@ -170,10 +181,10 @@ min on coulomb.SCHWINGE.
 
 # Testsuite
 
-    $ make -k check
+    $ make -k check 2>&1 | tee log_test
     [...]
 
-This needs roughly 3 min on kepler.SCHWINGE and 13 min on coulomb.SCHWINGE.
+This needs roughly 6 min on kepler.SCHWINGE and 42 min on coulomb.SCHWINGE.
 
 
 ## Analysis
@@ -199,3 +210,46 @@ This needs roughly 3 min on kepler.SCHWINGE and 13 min on coulomb.SCHWINGE.
     [[I|tschwinge]] suppose this is due to us having an override w.r.t. weak
     symbol handling in glibc, needed for our external [[/libpthread]].  TODO:
     document properly.
+
+  * `FAIL: gas/i386/rept`
+
+    Added in commit 06f1247c54126b9f1e6acb8ff8c7be35aec6f44c (2012-06-07) as
+    part of the fix for [[!sourceware_PR 14201]], renamed in commit
+    d654e24bbc2f601df4dc43b26049b0339528b93a (2012-06-07):
+
+        WARNING: program timed out.
+        FAIL: gas/i386/rept
+
+  * ld IFUNC execution tests
+
+    Missing [[IFUNC]] support on GNU/Hurd.
+
+    Added in commit 82c5587db078581cfe94a4385ed99de1d1fa6657 (2012-09-19):
+
+        FAIL: Common symbol override ifunc test 1a
+        FAIL: Common symbol override ifunc test 1b
+
+  * gold GNU/Linux vs. GNU/Hurd
+
+        -FAIL: relro_test.sh
+        +PASS: relro_test.sh
+
+        -PASS: ver_matching_test.sh
+        +FAIL: ver_matching_test.sh
+
+        -PASS: script_test_3
+        +FAIL: script_test_3
+
+        -PASS: tls_phdrs_script_test
+        +FAIL: tls_phdrs_script_test
+
+        -PASS: ifuncmain1static
+        -PASS: ifuncmain1picstatic
+        -PASS: ifuncmain2static
+        -PASS: ifuncmain2picstatic
+        -PASS: ifuncmain4static
+        -PASS: ifuncmain4picstatic
+        -PASS: ifuncmain5static
+        -PASS: ifuncmain5picstatic
+        -PASS: ifuncmain7static
+        -PASS: ifuncmain7picstatic
diff --git a/open_issues/boehm_gc.mdwn b/open_issues/boehm_gc.mdwn
index 6ab39b2e..7f860bba 100644
--- a/open_issues/boehm_gc.mdwn
+++ b/open_issues/boehm_gc.mdwn
@@ -359,8 +359,6 @@ restults of GNU/Linux and GNU/Hurd look very similar.
 
 # TODO
 
-  * Port stuff to [[GCC]], and test it there.
-
   * What are other applications to test Boehm GC?  Also especially in
     combination with [[/libpthread]] and dynamic loading of shared libraries?
 
diff --git a/open_issues/code_analysis.mdwn b/open_issues/code_analysis.mdwn
index 2ab8bf1d..a73f102c 100644
--- a/open_issues/code_analysis.mdwn
+++ b/open_issues/code_analysis.mdwn
@@ -152,11 +152,20 @@ There is a [[!FF_project 276]][[!tag bounty]] on some of these tasks.
         <youpi> ah, no, the libthreads code properly sets the guard, just for
           grow-up stacks
 
-  * GCC's AddressSanitizer (ASan; `-faddress-sanitizer`)
+  * GCC's AddressSanitizer, a memory error detector (ASan;
+    `-fsanitize=address`)
 
     [Finding races and memory errors with GCC instrumentation
     (AddressSanitizer)](http://gcc.gnu.org/wiki/cauldron2012#Finding_races_and_memory_errors_with_GCC_instrumentation_.28AddressSanitizer.29),
-    GNU Tools Cauldron 2012.
+    GNU Tools Cauldron 2012.  <http://code.google.com/p/address-sanitizer/>.
+
+    Not yet [[ported to the Hurd|community/gsoc/project_ideas/gcc_asan]].
+
+  * GCC's ThreadSanitizer, a data race detector (TSan; `-fsanitize=thread`)
+
+    <http://code.google.com/p/data-race-test/wiki/ThreadSanitizer>
+
+    Not yet [[ported to the Hurd|community/gsoc/project_ideas/gcc_asan]].
 
   * Input fuzzing
 
diff --git a/open_issues/formal_verification.mdwn b/open_issues/formal_verification.mdwn
index b7db76ee..474670c3 100644
--- a/open_issues/formal_verification.mdwn
+++ b/open_issues/formal_verification.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
@@ -15,6 +16,8 @@ Especially in the field of [[DSL]]s, this is used for asserting program codes'
 correctness, as explained in {{$microkernel/barrelfish#fof_plos09}}, for
 example.
 
+See also [[code_analysis]].
+
 [[!toc]]
 
 
diff --git a/open_issues/gcc.mdwn b/open_issues/gcc.mdwn
index 574a743b..66fad780 100644
--- a/open_issues/gcc.mdwn
+++ b/open_issues/gcc.mdwn
@@ -33,12 +33,12 @@ example.  Especially all the compiler magic is all the same.
 git checkout reviewed
 git log --reverse --topo-order --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..upstream/trunk
 -i
-/^commit |^Merge:|^---$|hurd|linux|nacl|nptl|glibc|gs:
+/^commit |^merge:|^---$|hurd|linux|nacl|nptl|glibc|gs:
 
 -->
 
-Last reviewed up to the [[Git mirror's 769bf18a20ee2540ca7601cdafabd62b18b9751b
-(2012-10-01) sources|source_repositories/gcc]].
+Last reviewed up to the [[Git mirror's be3860ba8df48cca3253da4f02fd2d42d856ce80
+(2012-12-10) sources|source_repositories/gcc]].
 
 <http://gcc.gnu.org/install/configure.html> has documentation for the
 `configure` switches.
@@ -112,9 +112,7 @@ Last reviewed up to the [[Git mirror's 769bf18a20ee2540ca7601cdafabd62b18b9751b
 
   * `--enable-gnu-unique-object`
 
-  * `--enable-lto`, `--enable-gold`
-
-    [[binutils_gold]]
+  * `--enable-lto`
 
   * `--enable-indirect-function`
 
@@ -301,12 +299,39 @@ Last reviewed up to the [[Git mirror's 769bf18a20ee2540ca7601cdafabd62b18b9751b
     "20110609002620.GA16719@const.famille.thibault.fr"]].  commit
     026e608ecebcb2a6193971006a85276307d79b00.
 
+  * 549e2197b118efb2d947aaa15d445b05c1b5ed62 `Import the asan runtime library
+    into GCC tree`.  Linux-specific things:
+    `ASAN_USE_ALIAS_ATTRIBUTE_FOR_INDEX`, `ASAN_LINUX`, `ASAN_POSIX`,
+    `libsanitizer/asan/asan_linux.cc`,
+    `libsanitizer/asan/asan_malloc_linux.cc`,
+    `libsanitizer/asan/asan_posix.cc`,
+    `libsanitizer/interception/interception.h`,
+    `libsanitizer/interception/interception_linux.cc`,
+    `libsanitizer/interception/interception_linux.h`,
+    `libsanitizer/sanitizer_common/sanitizer_allocator.cc`,
+    `libsanitizer/sanitizer_common/sanitizer_linux.cc`,
+    `libsanitizer/sanitizer_common/sanitizer_posix.cc`,
+    `libsanitizer/sanitizer_common/sanitizer_procmaps.h`,
+    `libsanitizer/sanitizer_common/sanitizer_symbolizer_linux.cc`.
+    4afab99bf0fe2d6905a9fa9d6ab886ca102312df `Enable libsanitizer just on x86
+    linux for now`.  492e75a7336b4dbfe38207ea3abf8d5bd72376a9 `Move
+    libsanitizer configure logic to subdirectory`.
+    6aea389d84c2172668af5f108e2b17e131120d0b `Add STATIC_LIBASAN_LIBS for
+    -static-libasan`.  Further commits later on.
+
+      * 9cf754572854d9d9cd43c277eb7afb12e4911358 `Import tsan runtime from
+        llvm`.  Linux-specific things: `libsanitizer/tsan/tsan_platform.h`,
+        `libsanitizer/tsan/tsan_platform_linux.cc`,
+        `libsanitizer/tsan/tsan_symbolize_addr2line_linux.cc`.
+        a96132f29aa3dfe94141a87537f62ea73ce0fc19 `Set TSAN_SUPPORTED=yes for
+        x86_64/i686-linux for 64-bit multilib`.  Further commits later on.
+
 
 # Build
 
 Here's a log of a GCC build run; this is from our [[Git repository's
-b401cb7ed15602d244a6807835b0b9d740a302a8 (2012-11-26;
-769bf18a20ee2540ca7601cdafabd62b18b9751b (2012-10-01))
+a1d48e100791bc67ff355e0931a604e767c827b7 (2012-12-10;
+be3860ba8df48cca3253da4f02fd2d42d856ce80 (2012-12-10))
 sources|source_repositories/gcc]], run on kepler.SCHWINGE and coulomb.SCHWINGE.
 
     $ export LC_ALL=C
@@ -319,8 +344,8 @@ 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 3.1 GiB, and needs roughly 3.25 h on kepler.SCHWINGE and
-13.25 h on coulomb.SCHWINGE.
+This takes up around 3.5 GiB, and needs roughly 3.25 h on kepler.SCHWINGE and
+14.25 h on coulomb.SCHWINGE.
 
 <!--
 
@@ -338,42 +363,6 @@ This takes up around 3.1 GiB, and needs roughly 3.25 h on kepler.SCHWINGE and
 
     Addressed in Debian glibc.
 
-  * DFP
-
-    Addressed in *hurd/decimal_floating_point* branch.
-
-        +configure: WARNING: decimal float is not supported for this target, ignored
-
-    ... and later on:
-
-        -checking for decimal floating point... bid
-        +checking for decimal floating point... configure: WARNING: decimal float is not supported for this target, ignored
-        +dpd
-
-    ... and later on:
-
-        -checking whether decimal floating point is supported... yes
-        +checking whether decimal floating point is supported... no
-        +configure: WARNING: decimal float is not supported for this target, ignored
-
-      * `libstdc++-v3/acinclude.m4`: ISO/IEC TR 24733
-
-            -checking for ISO/IEC TR 24733 ... yes
-            +checking for ISO/IEC TR 24733 ... no
-
-      * `--enable-decimal-float`, `--enable-fixed-point`, `--with-long-double-128`
-
-        `configure: WARNING: decimal float is not supported for this target,
-        ignored`
-
-          * `libgcc/configure.ac` [might
-            need](http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00315.html) to be
-            aligned for us to the `*linux*` cases.  As well as at the end of
-            `libgcc/config.host`.  Check.
-
-                checking whether decimal floating point is supported... no
-                checking whether fixed-point is supported... no
-
   * `host-linux.c` vs. `host-default.c`
 
   * *fixincludes* stuff
@@ -514,7 +503,7 @@ This takes up around 3.1 GiB, and needs roughly 3.25 h on kepler.SCHWINGE and
     $ make install 2>&1 | tee log_install
     [...]
 
-This takes up around 850 MiB, and needs roughly 4 min on kepler.SCHWINGE and 35
+This takes up around 1 GiB, and needs roughly 5 min on kepler.SCHWINGE and 37
 min on coulomb.SCHWINGE.
 
 
@@ -595,10 +584,10 @@ coulomb.SCHWINGE:
     $ make -k check-target 2>&1 | tee log_test_4_check-target
     [...]
 
-This needs roughly 6.75 h on kepler.SCHWINGE and 3.5 h (`check-fixincludes`,
-`gcc/check-ada`) + 10 h (`gcc/check-c`) + 3.75 h (`gcc/check-c++`) + 5.5 h
+This needs roughly 7 h on kepler.SCHWINGE and 4 h (`check-fixincludes`,
+`gcc/check-ada`) + 12.5 h (`gcc/check-c`) + 4.25 h (`gcc/check-c++`) + 5.5 h
 (`gcc/check-fortran`, `gcc/check-java`, `gcc/check-lto`, `gcc/check-objc`) +
-8.25 h (`check-intl`, [...], `check-lto-plugin`, `check-target`) = 31 h on
+9 h (`check-intl`, [...], `check-lto-plugin`, `check-target`) = 35.25 h on
 coulomb.SCHWINGE.
 
 
@@ -623,6 +612,20 @@ coulomb.SCHWINGE.
     769bf18a20ee2540ca7601cdafabd62b18b9751b (2012-10-01)), there are
     regressions (FAILs) in libgomp execution tests on coulomb.SCHWINGE.
 
+  * 769bf18a20ee2540ca7601cdafabd62b18b9751b..be3860ba8df48cca3253da4f02fd2d42d856ce80
+
+    On GNU/Hurd:
+
+         Running [...]/hurd/master/gcc/testsuite/g++.dg/tls/tls.exp ...
+        +FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 execution test
+        +FAIL: g++.dg/tls/thread_local3g.C -std=gnu++11 execution test
+        +FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 execution test
+        +FAIL: g++.dg/tls/thread_local4g.C -std=gnu++11 execution test
+        +FAIL: g++.dg/tls/thread_local5.C -std=gnu++11 execution test
+        +FAIL: g++.dg/tls/thread_local5g.C -std=gnu++11 execution test
+
+    They used to PASS.
+
   * TODO
 
 
diff --git a/open_issues/glibc/mremap.mdwn b/open_issues/glibc/mremap.mdwn
index a293eea0..874c7ae0 100644
--- a/open_issues/glibc/mremap.mdwn
+++ b/open_issues/glibc/mremap.mdwn
@@ -10,177 +10,24 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_glibc]]
 
-[[!toc]]
-
+The Hurd does not currently support the `mremap` function.
 
-# binutils gold
+For the `MREMAP_MAYMOVE` case it is easy to work around; see
+`[binutils]/gold/mremap.c`, for example.
 
-## 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...
+[[!toc]]
 
-[[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
+# IRC, freenode, #hurd, 2011-01-12
 
-    <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
diff --git a/toolchain/logs b/toolchain/logs
-Subproject 272397686eea60669290da0add796ca601b1a2e
+Subproject b2218016e588eed4e81eeb85b35f58bcd784da4