diff options
Diffstat (limited to 'open_issues/binutils.mdwn')
| -rw-r--r-- | open_issues/binutils.mdwn | 227 |
1 files changed, 163 insertions, 64 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? |