summaryrefslogtreecommitdiff
path: root/open_issues
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues')
-rw-r--r--open_issues/binutils.mdwn227
-rw-r--r--open_issues/code_analysis.mdwn4
-rw-r--r--open_issues/gnumach_panic_thread_dispatch.mdwn12
-rw-r--r--open_issues/libpthread_assertion_thread_prevp.mdwn13
-rw-r--r--open_issues/performance.mdwn27
5 files changed, 212 insertions, 71 deletions
diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn
index 306ba38a..15ddcc7b 100644
--- a/open_issues/binutils.mdwn
+++ b/open_issues/binutils.mdwn
@@ -41,14 +41,14 @@ GDB needs an processor architecture as well as operating system port.
<!--
git checkout reviewed
-git diff --patience --stat=$COLUMNS,$COLUMNS --patch --src-prefix=./ --dst-prefix=./ --find-renames --ignore-space-change ..upstream/master | awk '/^diff/ { c = " " $0; } /^@@/ { print c; } { print; }' | less
+git diff --patience --stat=$COLUMNS,$COLUMNS --patch --src-prefix=./ --dst-prefix=./ --word-diff --color --find-renames --ignore-space-change ..upstream/master | awk '/^(\x1b\[[0-9]+m)?diff/ { c = " " $0; } /^(\x1b\[[0-9]+m)?@@/ { print c; } { print; }' | less
-i
/^---.*/([^.]*|.*\.texi.*|[^/]*gnu[^/]*)$|hurd|linux|nacl|nptl|glibc|gs:
-->
-Last reviewed up to Git commit c2853f3d99797a321c37948297441ca6021f719a
-(2014-02-14).
+Last reviewed up to Git commit 05db5edd7923711a20c6225ea8e15f36e819d140
+(2014-09-16).
* Globally
@@ -119,6 +119,79 @@ Last reviewed up to Git commit c2853f3d99797a321c37948297441ca6021f719a
* In `gdb/gnu-nat.c:gnu_wait`, we don't implement
`gdb/target/wait.h:TARGET_WNOHANG`. What is this needed for?
+ * *complete errno.h*
+
+ diff --git toolchain/logs/binutils-gdb/kepler.SCHWINGE/log_build_ toolchain/logs/binutils-gdb/laplace.SCHWINGE/log_build_
+ [...]
+ -checking for complete errno.h... yes
+ +checking for complete errno.h... no
+ +checking for EMULTIHOP value... yes
+ +checking for ENOLINK value... yes
+ +checking for EOVERFLOW value... yes
+ [...]
+ +rm -f errno.h-t errno.h && \
+ +{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */' && \
+ + sed -e 's|@''GUARD_PREFIX''@|GL|g' \
+ + -e 's|@''INCLUDE_NEXT''@|include_next|g' \
+ + -e 's|@''PRAGMA_SYSTEM_HEADER''@|#pragma GCC system_header|g' \
+ + -e 's|@''PRAGMA_COLUMNS''@||g' \
+ + -e 's|@''NEXT_ERRNO_H''@|<errno.h>|g' \
+ + -e 's|@''EMULTIHOP_HIDDEN''@|0|g' \
+ + -e 's|@''EMULTIHOP_VALUE''@||g' \
+ + -e 's|@''ENOLINK_HIDDEN''@|0|g' \
+ + -e 's|@''ENOLINK_VALUE''@||g' \
+ + -e 's|@''EOVERFLOW_HIDDEN''@|0|g' \
+ + -e 's|@''EOVERFLOW_VALUE''@||g' \
+ + < ../../../../W._C._Handy/gdb/gnulib/import/errno.in.h; \
+ +} > errno.h-t && \
+ +mv errno.h-t errno.h
+
+ [[!taglink open_issue_glibc]]?
+
+ * Watchpoints
+
+ * Unresolved issues w.r.t. watchpoint usage in context of multiple
+ threads, and `fork`/`vfork`. The Linux port has a bunch of
+ special-case code.
+
+ * We don't have anything corresponding to Linux'
+ `linux_nat_set_forget_process`, `x86_forget_process`, or Linux'
+ whole `linux-fork.c` machinery. Likewise for
+ `linux_nat_set_prepare_to_resume`, `x86_linux_prepare_to_resume`,
+ which the Linux port uses to actually set the debug registers.
+ Likewise for `linux_nat_set_new_thread`, `x86_linux_new_thread`,
+ and `linux_nat_set_new_fork`, `x86_linux_new_fork`.
+
+ * Look into `*_cleanup_dregs`, `*_post_startup_inferior`. Commits
+ 53a5351d907ef4eacd463a48a86d35b2b70b9f60,
+ 52b9821179d84d61852ac2ae2bd16fbb56ffe277,
+ 9742079a314711c13d269e9e583b7b82dc42f1a6,
+ e24d4c64ff2e89327ba84fdcc77cc557791eb3cd,
+ fa4ba8da6c28c972dd1b6b9971e29b51aabaafcc,
+ 9b4f1ba7ede77d776fabb9642cbeef5091e38e1d,
+ 4de4c07c6b48659ae212352236be9413c853a23c,
+ 4056d25828218621e7276a3a0c0567cac892ae84,
+ 10d6c8cd3f92fadf295eb3c91d550626f6080f79,
+ 4105de343e714e0096723905ada442f1524776a6,
+ c5af0dad33ff96dbb404710539f01b011cff0453,
+ 9bb9e8ade770027f5cced2856574e2d317b15254,
+ 1ced966e3458bf3db742913f4d0a55549824e298,
+ 4403d8e9b35649c5b24f65c0ec0decc3839e1164,
+ 26cb8b7c1a23586ea311d7480f882e2883f6f1f5.
+
+ * [[!message-id "201112051601.59664.pedro@codesourcery.com"]].
+
+ * `I386_WATCHPOINTS_IN_TARGET_VECTOR`
+
+ * `prepare_to_resume`
+
+ * `new_fork`
+
+ * `forget_process`
+
+ * `dr_status_mirror` is not really used anywhere. Get rid of it; or,
+ update it everytime the real value is read from the kernel?
+
* `libdecnumber/`
Should/can probably align to GNU/Linux.
@@ -167,30 +240,27 @@ Last reviewed up to Git commit c2853f3d99797a321c37948297441ca6021f719a
# Build
Here's a log of a binutils-gdb build run; this is from Git commit
-c2853f3d99797a321c37948297441ca6021f719a (2014-02-14) plus
-[[!message-id "87vbxxhww4.fsf@kepler.schwinge.homeip.net"]],
-[[!message-id "8738kyi30l.fsf@kepler.schwinge.homeip.net"]],
-[[!message-id "8761ofv62k.fsf@kepler.schwinge.homeip.net"]],
-[[!message-id "1391759958-972-2-git-send-email-yao@codesourcery.com"]],
-[[!message-id "1391759958-972-3-git-send-email-yao@codesourcery.com"]], run on
-kepler.SCHWINGE and coulomb.SCHWINGE.
+05db5edd7923711a20c6225ea8e15f36e819d140 (2014-09-16), run on kepler.SCHWINGE
+and laplace.SCHWINGE (with [[!message-id "87iokondoc.fsf@schwinge.name"]]
+applied).
$ export LC_ALL=C
- $ ../W._C._Handy/configure --prefix="$PWD".install --enable-gold --with-sysroot=/ SHELL=/bin/dash CC=gcc-4.8 CXX=g++-4.8 --disable-werror 2>&1 | tee log_build
+ $ ../W._C._Handy/configure --prefix="$PWD".install --enable-gold --enable-plugins --with-sysroot=/ SHELL=/bin/dash CC=gcc-4.9 CXX=g++-4.9 --disable-werror 2>&1 | tee log_build
[...]
$ make 2>&1 | tee log_build_
[...]
Different hosts may default to different shells and compiler versions; thus
-harmonized. Debian GCC (which is used in binutils' testsuite) likes to pass
-`--sysroot=/` to `ld`, so we need to configure binutils with support for
+harmonized. Debian GCC (which is used in the testsuite) likes to pass
+`-plugin [...]` and `--sysroot=/` to `ld`,
+so we need to configure with support for plugins and
sysroots. In the GDB build, there are several occurences of *error:
dereferencing type-punned pointer will break strict-aliasing rules* in the
MIG-generated stub files; thus no `-Werror` until that is resolved
([[strict_aliasing]]).
-This takes up around 1.3 GiB, and needs roughly 17 min on kepler.SCHWINGE and
-79 min on coulomb.SCHWINGE.
+This takes up around 1.3 GiB, and runs for [[22 min|performance#measure]] on
+kepler.SCHWINGE and [[21 min|performance#measure]] on laplace.SCHWINGE.
<!--
@@ -216,33 +286,15 @@ formats, and more emulation vectors.
* `gdb/gnu-nat.c`
- gnu-nat.c: In function 'proc_set_exception_port':
- gnu-nat.c:409:3: warning: format '%d' expects argument of type 'int', but argument 8 has type 'mach_port_t' [-Wformat]
- gnu-nat.c: In function 'proc_steal_exc_port':
- gnu-nat.c:449:7: warning: format '%d' expects argument of type 'int', but argument 8 has type 'mach_port_t' [-Wformat]
- gnu-nat.c:470:7: warning: format '%d' expects argument of type 'int', but argument 8 has type 'mach_port_t' [-Wformat]
- gnu-nat.c: In function 'make_proc':
- gnu-nat.c:583:7: warning: format '%d' expects argument of type 'int', but argument 2 has type 'mach_port_t' [-Wformat]
- gnu-nat.c:586:7: warning: format '%d' expects argument of type 'int', but argument 8 has type 'mach_port_t' [-Wformat]
- gnu-nat.c: In function 'inf_set_pid':
- gnu-nat.c:761:3: warning: format '%d' expects argument of type 'int', but argument 7 has type 'task_t' [-Wformat]
- gnu-nat.c: In function 'inf_validate_procs':
- gnu-nat.c:1085:6: warning: format '%d' expects argument of type 'int', but argument 8 has type 'thread_t' [-Wformat]
- gnu-nat.c: In function 'inf_signal':
- gnu-nat.c:1349:4: warning: format '%d' expects argument of type 'int', but argument 7 has type 'thread_t' [-Wformat]
- gnu-nat.c:1349:4: warning: format '%d' expects argument of type 'int', but argument 8 has type 'thread_t' [-Wformat]
- gnu-nat.c: In function 'S_exception_raise_request':
- gnu-nat.c:1668:3: warning: format '%d' expects argument of type 'int', but argument 7 has type 'thread_t' [-Wformat]
- gnu-nat.c:1668:3: warning: format '%d' expects argument of type 'int', but argument 8 has type 'task_t' [-Wformat]
- gnu-nat.c:1705:8: warning: format '%d' expects argument of type 'int', but argument 7 has type 'mach_port_t' [-Wformat]
- gnu-nat.c:1711:8: warning: format '%d' expects argument of type 'int', but argument 7 has type 'mach_port_t' [-Wformat]
- gnu-nat.c: In function 'do_mach_notify_dead_name':
- gnu-nat.c:1762:3: warning: format '%d' expects argument of type 'int', but argument 7 has type 'mach_port_t' [-Wformat]
- gnu-nat.c: In function 'gnu_write_inferior':
- gnu-nat.c:2383:8: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'vm_address_t' [-Wformat]
- gnu-nat.c:2393:8: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'vm_address_t' [-Wformat]
- gnu-nat.c: In function 'steal_exc_port':
- gnu-nat.c:2864:5: warning: format '%d' expects argument of type 'int', but argument 2 has type 'mach_port_t' [-Wformat]
+ In file included from ../../W._C._Handy/gdb/defs.h:454:0,
+ from ../../W._C._Handy/gdb/gnu-nat.c:23:
+ ../../W._C._Handy/gdb/gnu-nat.c: In function 'proc_trace':
+ ./nm.h:35:60: warning: right-hand operand of comma expression has no effect [-Wunused-value]
+ ((((struct i386_thread_state *) (state))->efl &= ~0x100), 1)
+ ^
+ ../../W._C._Handy/gdb/gnu-nat.c:526:5: note: in expansion of macro 'THREAD_STATE_CLEAR_TRACED'
+ THREAD_STATE_CLEAR_TRACED (state);
+ ^
* fe19822761b4635f392875a186e48af446b40f41..7a63e9515491f21eaf07301df87d389def20e317:
@@ -267,14 +319,18 @@ formats, and more emulation vectors.
[[!taglink open_issue_glibc]]?
+ * On GNU Hurd, the `checking types of arguments for ptrace...` configure
+ check takes a rather long time to determine the result,
+ `int,int,long,long`.
+
# Install
$ make install 2>&1 | tee log_install
[...]
-This takes up around 200 MiB, and needs roughly 2 min on kepler.SCHWINGE and 6
-min on coulomb.SCHWINGE.
+This takes up around 200 MiB, and runs for [[1 min|performance#measure]] on
+kepler.SCHWINGE and [[1 min|performance#measure]] on laplace.SCHWINGE.
## Analysis
@@ -289,15 +345,16 @@ min on coulomb.SCHWINGE.
$ make -k check 2>&1 | tee log_test
[...]
-This needs roughly 20 min on kepler.SCHWINGE and 140 min on coulomb.SCHWINGE.
+This runs for [[26 min|performance#measure]] on kepler.SCHWINGE and [[63
+min|performance#measure]] on laplace.SCHWINGE.
When running `make -k check 2>&1 | tee log_test`, at the end of the testsuite
the `tee` process does not terminate if there are still stray leftover
processes that [have their stdout/stderr
open](http://sourceware.org/ml/gdb-patches/2012-10/msg00489.html). `kill`ing
these (`SIGKILL` may be needed), makes the `tee` process terminate, too. On
-GNU/Hurd, these generally are `gdb.multi/watchpoint-multi`, and an unknown
-(`?`) GDB one ("57 PIDs before" `expect [...] gdb.cp`).
+GNU/Hurd, these generally are `gdb.base/sigaltstack`, `gdb.base/siginfo`,
+`gdb.multi/watchpoint-multi`, `gdb.threads/watchthreads`.
## Analysis
@@ -368,6 +425,8 @@ like `gdb/testsuite/boards/cc-with-tweaks.exp` would help, or setting
* Disabled
+ * `gdb.base/attach-wait-input.exp`
+
* `gdb.base/interrupt.exp`
PASS: gdb.base/interrupt.exp: child process is alive
@@ -525,6 +584,15 @@ like `gdb/testsuite/boards/cc-with-tweaks.exp` would help, or setting
(gdb) kill
Kill the program being debugged? (y or n) y
+ * `gdb.base/random-signal.exp`
+
+ Several things (suddenly?) seem to go wrong here. It seems we do hit
+ (something similar to?) the issue described in the log of commit
+ 427cd150eed8c0dd4f0d0a1105448b4ebe36da6d, which adds this test. The
+ `alarm` call in `random-signal.c` doesn't seem to trigger, so
+ `random-signal` keeps running (comsuming *system* CPU time) until
+ manually terminated.
+
* `gdb.base/readline.exp`
[[term_blocking]] issue.
@@ -533,6 +601,28 @@ like `gdb/testsuite/boards/cc-with-tweaks.exp` would help, or setting
From `send signal TSTP` on, all FAIL running into timeouts.
+ * `gdb.base/watch-vfork.exp`
+
+ Running ../../../W._C._Handy/gdb/testsuite/gdb.base/watch-vfork.exp ...
+ PASS: gdb.base/watch-vfork.exp: Watchpoint on global variable (hw)
+ FAIL: gdb.base/watch-vfork.exp: Watchpoint triggers after vfork (hw)
+ PASS: gdb.base/watch-vfork.exp: Watchpoint on global variable (sw)
+ FAIL: gdb.base/watch-vfork.exp: Watchpoint triggers after vfork (sw) (timeout)
+ Running ../../../W._C._Handy/gdb/testsuite/gdb.base/watch_thread_num.exp ...
+ PASS: gdb.base/watch_thread_num.exp: successfully compiled posix threads test case
+ ERROR: Couldn't load [...]/tschwinge/W._C._Handy.build/gdb/testsuite/gdb.base/watch_thread_num into [...]/tschwinge/W._C._Handy.build/gdb/testsuite/../../gdb/gdb (timeout).
+ ERROR: Delete all breakpoints in delete_breakpoints (timeout)
+
+ PID UID PPID PGrp Sess TH Vmem RSS %CPU User System Args
+ 10067 1000 1 10067 10062 2 146M 696K 0.0 0:00.02 0:08.40 /media/erich/home/thomas/tmp/binutils-gdb/tschwinge/W._C._Handy.build/gdb/testsuite/gdb.base/watch-vfork
+ 10107 1000 22500 10107 10107 2 150M 13M 97.3 0:00.04 3:10.07 /media/erich/home/thomas/tmp/binutils-gdb/tschwinge/W._C._Handy.build/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory /media/erich/home/thomas/tmp/binutils-gdb/tschwin
+
+ Open new screen window. Prompt is being displayed, but any input not
+ shown/reacted on. Once the watch-vfork process is killed, the input
+ shows up.
+
+ Once the busy-looping GDB process is killed, testing proceeds.
+
* `gdb.python/py-inferior.exp` (mostly disabled)
Running ../../../Ferry_Tagscherer/gdb/testsuite/gdb.python/py-inferior.exp ...
@@ -577,6 +667,8 @@ like `gdb/testsuite/boards/cc-with-tweaks.exp` would help, or setting
At this point, the system hangs; no new processes can be spawned, so
perhaps an issue with the exec server.
+ * `gdb.threads/hand-call-in-threads.exp`
+
* `gdb.threads/manythreads.exp`
[[!taglink open_issue_libpthread]]. Perhaps fails due to pthread
@@ -586,12 +678,20 @@ like `gdb/testsuite/boards/cc-with-tweaks.exp` would help, or setting
manythreads: ../libpthread/sysdeps/mach/pt-thread-halt.c:51: __pthread_thread_halt: Unexpected error: (ipc/rcv) invalid name.
Killed
+ * `gdb.threads/signal-delivered-right-thread.exp`
+
+ * `gdb.threads/step-over-trips-on-watchpoint.exp`
+
+ * `gdb.threads/thread-find.exp`
+
* Linux syscall usage, `<asm/unistd.h>`
* `UNSUPPORTED: gdb.threads/ia64-sigill.exp: Couldn't compile ../../../master/gdb/testsuite/gdb.threads/ia64-sigill.c: unrecognized error`
* `UNSUPPORTED: gdb.threads/siginfo-threads.exp: Couldn't compile ../../../Ferry_Tagscherer/gdb/testsuite/gdb.threads/siginfo-threads.c: unrecognized error`
+ Also uses `tgkill`.
+
* `gdb.threads/sigstep-threads.c`
Also uses `tgkill`.
@@ -697,7 +797,7 @@ like `gdb/testsuite/boards/cc-with-tweaks.exp` would help, or setting
#4 0x0804859c in gen_signal () at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:35
#5 0x08048610 in main () at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:81
- coulomb.SCHWINGE:
+ laplace.SCHWINGE:
Breakpoint 2, handle_signal (sig=6) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:28
28 }
@@ -714,7 +814,7 @@ like `gdb/testsuite/boards/cc-with-tweaks.exp` would help, or setting
no signal
[Inferior 1 (process 10401) exited normally]
- coulomb.SCHWINGE:
+ laplace.SCHWINGE:
(gdb) c
Continuing.
@@ -852,17 +952,25 @@ like `gdb/testsuite/boards/cc-with-tweaks.exp` would help, or setting
TODO.
+ * `gdb.base/watchpoint-hw-hit-once.exp`
+
+ PASS: gdb.base/watchpoint-hw-hit-once.exp: rwatch watchee
+ PASS: gdb.base/watchpoint-hw-hit-once.exp: continue
+ FAIL: gdb.base/watchpoint-hw-hit-once.exp: continue to break-at-exit
+
+ The watchpoint does trigger again, wrongly.
+
* `gdb.arch/i386-prologue.exp`
There are several FAILs, where there are unexpected frames showing up in
backtraces, for example. Earlier on, these just FAILed on
- coulomb.SCHWINGE; since
+ laplace.SCHWINGE; since
9939e1314f970c6ba568956148a518ac710a280a..c2853f3d99797a321c37948297441ca6021f719a
on kepler.SCHWINGE, too. TODO.
* [[libgc|boehm_gc]] `GC_find_limit_with_bound` SIGSEGVs
- On coulomb.SCHWINGE, in
+ On laplace.SCHWINGE, in
9939e1314f970c6ba568956148a518ac710a280a..c2853f3d99797a321c37948297441ca6021f719a
several PASSes regressed to FAILs:
@@ -918,6 +1026,10 @@ like `gdb/testsuite/boards/cc-with-tweaks.exp` would help, or setting
TODO.
+ * GDB: *Memory at address 0 is possibly executable*, and similar others
+
+ [[!message-id "878ulqqlrr.fsf@schwinge.name"]].
+
TODO.
@@ -939,16 +1051,3 @@ TODO.
set a breakpoint and ... when I ran "info files" the process segfaulted.
<teythoon> which process segfaults, pfinet or gdb?
<rekado> gdb segfaults.
-
-
-## GDB Watchpoints
-
-[[!tag open_issue_gdb]]
-
-
-### IRC, freenode, #hurd, 2013-09-16
-
- <gnu_srs> tschwinge: Is gdb watch known to fail on hurd? It hangs for me
- when logged in via ssh.
- <tschwinge> gnu_srs: Don't know about GDB's watch command. Are you sure it
- is hanging?
diff --git a/open_issues/code_analysis.mdwn b/open_issues/code_analysis.mdwn
index df434b76..2e10da80 100644
--- a/open_issues/code_analysis.mdwn
+++ b/open_issues/code_analysis.mdwn
@@ -258,7 +258,9 @@ There is a [[!FF_project 276]][[!tag bounty]] on some of these tasks.
* [Jones: system call abuse](http://lwn.net/Articles/414273/), Dave
Jones, 2010.
- * [Trinity: A Linux kernel fuzz tester (and then
+ * [Trinity: A Linux system call
+ fuzzer]http://codemonkey.org.uk/projects/trinity/().
+ [Trinity: A Linux kernel fuzz tester (and then
some)](http://www.socallinuxexpo.org/scale11x/presentations/trinity-linux-kernel-fuzz-tester-and-then-some),
Dave Jones, The Eleventh Annual Southern California Linux Expo, 2013.
diff --git a/open_issues/gnumach_panic_thread_dispatch.mdwn b/open_issues/gnumach_panic_thread_dispatch.mdwn
index db094f2f..5ee19eb0 100644
--- a/open_issues/gnumach_panic_thread_dispatch.mdwn
+++ b/open_issues/gnumach_panic_thread_dispatch.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2013, 2014 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
@@ -18,3 +18,13 @@ License|/fdl]]."]]"""]]
<braunr> ouch
<youpi> during a perl build
<braunr> TH_SWAPPED | TH_HALTED | TH_RUN
+
+
+# rpctrace
+
+Happens when debugging "certain things" with [[hurd/debugging/rpctrace]]?
+
+
+## 2014-09-17
+
+[[!message-id "87tx46m4ls.fsf@schwinge.name"]].
diff --git a/open_issues/libpthread_assertion_thread_prevp.mdwn b/open_issues/libpthread_assertion_thread_prevp.mdwn
index f93f07d6..85ac58d4 100644
--- a/open_issues/libpthread_assertion_thread_prevp.mdwn
+++ b/open_issues/libpthread_assertion_thread_prevp.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013, 2014 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
@@ -107,3 +108,13 @@ failed"]]
<braunr> so i guess something is wrong with thread recycling
<braunr> but i wanted to completely rewrite that part with the new kernel
call i asked bddebian to work on :)
+
+
+## 2014-09-15
+
+During a run of the GDB testsuite, [[I|tschwinge]] hit `C-c`, and then saw:
+
+ [...]
+ Running ../../../W._C._Handy/gdb/testsuite/gdb.base/shreloc.exp ...
+ ^Cexpect: ./pthread/pt-internal.h:131: __pthread_enqueue: Assertion `thread->prevp == 0' failed.
+ Aborted
diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn
index 64b245f2..ab08dd11 100644
--- a/open_issues/performance.mdwn
+++ b/open_issues/performance.mdwn
@@ -241,13 +241,26 @@ call|/glibc/fork]]'s case.
<teythoon> i especially like how general it is
-# Measurement
+# <a name="measure">Measure</a>
+
+On some pages, we're filing information about performace measurements.
+
+
+## kepler.SCHWINGE
+
+Debian GNU/Linux, x86. Running as a Xen domU, the system is not reserved
+exclusively for measurement purposes, so it's a best-effort service.
+
+
+## laplace.SCHWINGE
+
+Debian GNU/Hurd, x86. Running as a QEMU/KVM instance, the system is not
+reserved exclusively for measurement purposes, so it's a best-effort service.
-## coulomb
### [[!message-id "87wqghouoc.fsf@schwinge.name"]]
-## IRC, freenode, #hurd, 2014-02-27
+### IRC, freenode, #hurd, 2014-02-27
<braunr> tschwinge: about your concern with regard to performance
measurements, you could run kvm with hugetlbfs and cpuset
@@ -257,4 +270,10 @@ call|/glibc/fork]]'s case.
<braunr> hugetlbs reduces the overhead of page faults, and also implies
locked memory while cpuset isolates the vm from global scheduling
<braunr> hugetlbfs*
- <tschwinge> Thanks, will look into that.
+
+
+### 2014-07-25, tschwinge
+
+Support for [huge pages](https://wiki.debian.org/Hugepages) as well as [CPU
+sets](https://code.google.com/p/cpuset/) requires special setup; not doing that
+at the moment.