[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 2013 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_gdb]] Here's what's to be done for maintaining GNU GDB. [[!toc levels=2]] # [[General information|/gdb]] # [[Sources|source_repositories/gdb]] # Configuration Last reviewed up to the [[Git mirror's d19fd090b7ec0a60846c52cad9fc0c24c3729565 (2013-09-18) sources|source_repositories/gdb]]. * Globally * a.out, 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 conditionalized like this at all.) * `bfd/` See [[binutils]]. * `libdecnumber/` Should/can probably align to GNU/Linux. * Have a look at config/i386/i386gnu.mh. * configure.tgt * glibc-tdep et al. also for GNU/Hurd? * [[gdbserver]] * 82763a3d329b0d342d0273941b1521be9ef0c604 »MODIFIED is unknown, pass it as true.« * Configure so that Debian system's `/usr/lib/debug/[...]` will be loaded automatically. * old-style function definition ../../Ferry_Tagscherer/gdb/gnu-nat.c: In function 'trace_me': ../../Ferry_Tagscherer/gdb/gnu-nat.c:2106:8: warning: old-style function definition [-Wold-style-definition] void trace_me () ^ # Build Here's a log of a GDB build run; this is from our [[Git repository|source_repositories/gdb]]'s `tschwinge/Ferry_Tagscherer` branch, commit d19fd090b7ec0a60846c52cad9fc0c24c3729565 (2013-09-18), run on kepler.SCHWINGE and coulomb.SCHWINGE. $ export LC_ALL=C $ ../Ferry_Tagscherer/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.8 CXX=g++-4.8 --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. 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 230 MiB and needs roughly 8 min on kepler.SCHWINGE and 31 min on coulomb.SCHWINGE. ## Analysis x86 GNU/Linux' and GNU/Hurd's configurations are slightly different, thus mask out most of the differences that are due to GNU/Linux supporting more core file formats and more emulation vectors. $ toolchain/logs/process gdb build * Why do we specify `-D_GNU_SOURCE`, and GNU/Linux doesn't? * GNU/Linux: `gdb/symfile-mem.c` for [[vDSO]]. * GNU/Linux: `gdb/i386-nat.c` for hardware breakpoints, etc. -- we should probably use that, too. Related to Samuel's Hurd GDB patch? * `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] * fe19822761b4635f392875a186e48af446b40f41..7a63e9515491f21eaf07301df87d389def20e317: `-Wmissing-prototypes` gnu-nat.c: At top level: gnu-nat.c:643:1: warning: no previous prototype for 'make_inf' [] gnu-nat.c: At top level: gnu-nat.c:879:1: warning: no previous prototype for 'inf_set_traced' [] gnu-nat.c:980:1: warning: no previous prototype for 'inf_port_to_thread' [] gnu-nat.c: At top level: gnu-nat.c:1748:1: warning: no previous prototype for 'inf_task_died_status' [] gnu-nat.c: At top level: gnu-nat.c:2273:1: warning: no previous prototype for 'gnu_read_inferior' [] gnu-nat.c:2319:1: warning: no previous prototype for 'gnu_write_inferior' [] gnu-nat.c: At top level: gnu-nat.c:3415:1: warning: no previous prototype for '_initialize_gnu_nat' [] notify_S.c:305:24: warning: no previous prototype for 'notify_server' [] notify_S.c:341:28: warning: no previous prototype for 'notify_server_routine' [] process_reply_S.c:343:24: warning: no previous prototype for 'process_reply_server' [] process_reply_S.c:379:28: warning: no previous prototype for 'process_reply_server_routine' [] msg_reply_S.c:165:24: warning: no previous prototype for 'msg_reply_server' [] msg_reply_S.c:201:28: warning: no previous prototype for 'msg_reply_server_routine' [] exc_request_S.c:157:24: warning: no previous prototype for 'exc_server' [] exc_request_S.c:193:28: warning: no previous prototype for 'exc_server_routine' [] * `O_NOFOLLOW` First seen in 20f498edfd7e57d3297febcf9c7c7d667cc74239..69a5e2b022c7d15ec4c7c49e6f53a8d924d3b72b: -checking for working fcntl.h... yes +checking for working fcntl.h... no (bad O_NOFOLLOW) [[!taglink open_issue_glibc]]? * 00e1c4298d2b6fe040a9a970e98349602b12ddbf..6b25dae901ddedb3f330803542d3eac73cdcae4b: +../../Ferry_Tagscherer/gdb/gnu-nat.c: In function 'info_port_rights': +../../Ferry_Tagscherer/gdb/gnu-nat.c:3058:11: warning: passing argument 1 of 'parse_to_comma_and_eval' from incompatible pointer type [enabled by default] +In file included from ../../Ferry_Tagscherer/gdb/breakpoint.h:23:0, + from ../../Ferry_Tagscherer/gdb/inferior.h:37, + from ../../Ferry_Tagscherer/gdb/gnu-nat.c:56: +../../Ferry_Tagscherer/gdb/value.h:729:22: note: expected 'const char **' but argument is of type 'char **' # Install $ make install 2>&1 | tee log_install [...] This takes up around 50 MiB, and needs roughly 1 min on kepler.SCHWINGE and 3 min on coulomb.SCHWINGE. ## Analysis $ toolchain/logs/process gdb install * `libtool: finish`: `ldconfig` is not run for the Hurd. # Testsuite $ make -k check 2>&1 | tee log_test [...] This needs roughly 15 min on kepler.SCHWINGE and 72 min on coulomb.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 (`?`) one ("57 PIDs before" `expect [...] gdb.cp`). ## Analysis The testsuite uses the system's default `gcc` (and similar) compilers, not those specified on the `configure` line ([[!taglink open_issue_gdb]]?), see `find_gcc` (and similar) usage in the testsuite and DejaGnu. Maybe something like `gdb/testsuite/boards/cc-with-tweaks.exp` would help, or setting `CC_FOR_TARGET` (and similar) per `gdb/testsuite/lib/future.exp`? $ toolchain/logs/process gdb test * `gdb.base/attach-pie-misread.exp` Is only run for GNU/Linux; needs [[prelink]]. * Disabled * `gdb.base/readline.exp` [[term_blocking]] issue. * `gdb.base/sigall.exp` From `send signal TSTP` on, all FAIL running into timeouts. * `gdb.python/py-inferior.exp` (mostly disabled) Running ../../../Ferry_Tagscherer/gdb/testsuite/gdb.python/py-inferior.exp ... [...] python print 'result =', i0.was_attached result = False (gdb) PASS: gdb.python/py-inferior.exp: test Inferior.was_attached python print i0.threads () (, ) (gdb) FAIL: gdb.python/py-inferior.exp: test Inferior.threads break check_threads Breakpoint 2 at 0x8048869: file ../../../Ferry_Tagscherer/gdb/testsuite/gdb.python/py-inferior.c, line 61. (gdb) continue Continuing. [New Thread 25670.6] [New Thread 25670.7] [New Thread 25670.8] [New Thread 25670.9] [New Thread 25670.10] [New Thread 25670.11] [New Thread 25670.12] [New Thread 25670.13] Breakpoint 2, check_threads (barrier=0x15ff144) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.python/py-inferior.c:61 61 pthread_barrier_wait (barrier); (gdb) PASS: gdb.python/py-inferior.exp: continue to breakpoint: cont to check_threads python print len (i0.threads ()) 10 (gdb) FAIL: gdb.python/py-inferior.exp: test Inferior.threads 2 break 28 Breakpoint 3 at 0x80487c2: file ../../../Ferry_Tagscherer/gdb/testsuite/gdb.python/py-inferior.c, line 28. (gdb) continue Continuing. FAIL: gdb.python/py-inferior.exp: continue to breakpoint: cont to Break here. (timeout) python addr = gdb.selected_frame ().read_var ('str') FAIL: gdb.python/py-inferior.exp: read str address (timeout) [All following tests FAIL with timeout.] FAIL: gdb.python/py-inferior.exp: Switch to first inferior (timeout) remove-inferiors 3 FAIL: gdb.python/py-inferior.exp: Remove second inferior (timeout) At this point, the system hangs; no new processes can be spawned, so perhaps an issue with the exec server. * `gdb.threads/manythreads.exp` [[!taglink open_issue_libpthread]]. Perhaps fails due to pthread attributes usage? Doesn't execute properly: $ gdb/testsuite/gdb.threads/manythreads manythreads: ../libpthread/sysdeps/mach/pt-thread-halt.c:51: __pthread_thread_halt: Unexpected error: (ipc/rcv) invalid name. Killed * Linux syscall usage, `` * `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` * `gdb.threads/sigstep-threads.c` Also uses `tgkill`. * `UNSUPPORTED: gdb.threads/watchpoint-fork.exp: parent: multithreaded: Couldn't compile ../../../Ferry_Tagscherer/gdb/testsuite/gdb.threads/watchpoint-fork-mt.c ../../../Ferry_Tagscherer/gdb/testsuite/gdb.threads/watchpoint-fork-parent.c: unrecognized error` * `UNSUPPORTED: gdb.threads/multi-create.exp: Couldn't compile ../../../master/gdb/testsuite/gdb.threads/multi-create.c: unrecognized error` ../../../master/gdb/testsuite/gdb.threads/multi-create.c: In function 'create_function': ../../../master/gdb/testsuite/gdb.threads/multi-create.c:46:39: error: 'PTHREAD_STACK_MIN' undeclared (first use in this function) ../../../master/gdb/testsuite/gdb.threads/multi-create.c:46:39: note: each undeclared identifier is reported only once for each function it appears in ../../../master/gdb/testsuite/gdb.threads/multi-create.c: In function 'main': ../../../master/gdb/testsuite/gdb.threads/multi-create.c:73:39: error: 'PTHREAD_STACK_MIN' undeclared (first use in this function) * `UNSUPPORTED: gdb.threads/staticthreads.exp: Couldn't compile ../../../master/gdb/testsuite/gdb.threads/staticthreads.c: unrecognized error` ../../../master/gdb/testsuite/gdb.threads/staticthreads.c: In function 'main': ../../../master/gdb/testsuite/gdb.threads/staticthreads.c:52:37: error: 'PTHREAD_STACK_MIN' undeclared (first use in this function) ../../../master/gdb/testsuite/gdb.threads/staticthreads.c:52:37: note: each undeclared identifier is reported only once for each function it appears in * `UNSUPPORTED: gdb.threads/create-fail.exp: Couldn't compile ../../../Ferry_Tagscherer/gdb/testsuite/gdb.threads/create-fail.c: unrecognized error` [...]/gdb.threads/create-fail.c:77: undefined reference to `pthread_attr_setaffinity_np' [...]/gdb.threads/create-fail.c:83: undefined reference to `pthread_create' * `UNTESTED: gdb.base/longest-types.exp: longest-types.exp` ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/longest-types.c:20:8: error: size of array 'buf' is too large Also on GNU/Linux. * `FAIL: gdb.base/jit.exp: PIE: one_jit_test-1: Can't run to main` (gdb) break main Breakpoint 1 at 0xb84: file ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/jit-main.c, line 128. (gdb) run Starting program: /media/erich/home/thomas/tmp/gdb/tschwinge/Ferry_Tagscherer.build/gdb/testsuite/gdb.base/jit-main Cannot access memory at address 0x393 Cannot access memory at address 0x38f (gdb) FAIL: gdb.base/jit.exp: PIE: one_jit_test-1: Can't run to main [[GCC/PIE]]. Is the following supposed to terminate in this way? (gdb) break main Breakpoint 1 at 0x675: file ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/attach-pie-noexec.c, line 23. (gdb) run Starting program: /media/erich/home/thomas/tmp/gdb/tschwinge/Ferry_Tagscherer.build/gdb/testsuite/gdb.base/attach-pie-noexec Cannot access memory at address 0x6c626172 Cannot access memory at address 0x6c62616e (gdb) testcase ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/attach-pie-noexec.exp completed in 3 seconds IRC, freenode, #hurd, 2013-09-06: How to debug a program that works in the shell but Cannot access memory at address ... in gdb? Build it without -pie -- but that is just a guess of what might be going on. * tschwinge clearly has spent enough time with obscure things to be able to make such guesses. tschwinge: looks like -fPIE is used. verified: some (all?) executables compiled with -fPIE, -fpie and linked with -pie cannot be debugged in gdb :( * `solib-event stop` Running ../../../Ferry_Tagscherer/gdb/testsuite/gdb.mi/mi-catch-load.exp ... PASS: gdb.mi/mi-catch-load.exp: breakpoint at main PASS: gdb.mi/mi-catch-load.exp: mi runto main PASS: gdb.mi/mi-catch-load.exp: catch-load: auto-solib-add on PASS: gdb.mi/mi-catch-load.exp: catch-load: catch load FAIL: gdb.mi/mi-catch-load.exp: catch-load: solib-event stop PASS: gdb.mi/mi-catch-load.exp: breakpoint at main PASS: gdb.mi/mi-catch-load.exp: mi runto main PASS: gdb.mi/mi-catch-load.exp: catch-unload: auto-solib-add on PASS: gdb.mi/mi-catch-load.exp: catch-unload: catch unload FAIL: gdb.mi/mi-catch-load.exp: catch-unload: solib-event stop *stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x00014add",func="??",args=[],from="/lib/ld.so"},thread-id="4",stopped-threads="all" * `gdb.base/call-signal-resume.exp` $ gdb -q gdb/testsuite/gdb.base/call-signals (gdb) break stop_one (gdb) r (gdb) call gen_signal() (gdb) bt (gdb) frame [] (gdb) return (gdb) break handle_signal (gdb) c (gdb) c kepler.SCHWINGE: Breakpoint 2, handle_signal (sig=6) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:28 28 } (gdb) bt #0 handle_signal (sig=6) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:28 #1 #2 0xb7fde416 in __kernel_vsyscall () #3 0xb7dffd96 in kill () at ../sysdeps/unix/syscall-template.S:81 #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: Breakpoint 2, handle_signal (sig=6) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:28 28 } (gdb) bt #0 handle_signal (sig=6) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:28 #1 0x010baac2 in trampoline () from /lib/i386-gnu/libc.so.0.3 #2 0x00000006 in ?? () #3 0x00000000 in ?? () kepler.SCHWINGE: (gdb) c Continuing. no signal [Inferior 1 (process 10401) exited normally] coulomb.SCHWINGE: (gdb) c Continuing. no signal Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x01116c28 in _IO_acquire_lock_fct (p=) at libioP.h:905 #2 _IO_puts (str=0x80487e0 "no signal") at ioputs.c:45 #3 0x080486d8 in gen_signal () at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:38 #4 0x0804873d in main () at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:81 This is apparently new with the glibc 2.17 upgrade. If not doing the manual `gen_signal` call, it works fine. TODO. * `gdb.base/relativedebug.exp` (gdb) PASS: gdb.base/relativedebug.exp: continue bt #0 0x010a1afc in ?? () from /lib/i386-gnu/libc.so.0.3 #1 0x010a23be in mach_msg () from /lib/i386-gnu/libc.so.0.3 #2 0x0126cd98 in msg_sig_post () from /lib/i386-gnu/libhurduser.so.0.3 #3 0x010e2141 in ?? () from /lib/i386-gnu/libc.so.0.3 #4 0x010e23ed in kill () from /lib/i386-gnu/libc.so.0.3 #5 0x010e17f4 in raise () from /lib/i386-gnu/libc.so.0.3 #6 0x010e5b7c in abort () from /lib/i386-gnu/libc.so.0.3 #7 0x08048607 in handler (signo=14) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/relativedebug.c:25 #8 0x010bdac2 in ?? () from /lib/i386-gnu/libc.so.0.3 Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) FAIL: gdb.base/relativedebug.exp: pause found in backtrace This is apparently new with the glibc 2.17 upgrade. Previously it said: (gdb) PASS: gdb.base/relativedebug.exp: continue bt #0 0x0107c85c in ?? () from /lib/i386-gnu/libc.so.0.3 #1 0x0107d069 in mach_msg () from /lib/i386-gnu/libc.so.0.3 #2 0x01220d4f in msg_sig_post () from /lib/i386-gnu/libhurduser.so.0.3 #3 0x010bb683 in ?? () from /lib/i386-gnu/libc.so.0.3 #4 0x010bb8f6 in kill () from /lib/i386-gnu/libc.so.0.3 #5 0x010bad76 in raise () from /lib/i386-gnu/libc.so.0.3 #6 0x010bf029 in abort () from /lib/i386-gnu/libc.so.0.3 #7 0x08048597 in handler (signo=14) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/relativedebug.c:25 #8 0x01098282 in ?? () from /lib/i386-gnu/libc.so.0.3 #9 0x010bbe5a in sigsuspend () from /lib/i386-gnu/libc.so.0.3 #10 0x0112fee1 in pause () from /lib/i386-gnu/libc.so.0.3 #11 0x080485c5 in main () at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/relativedebug.c:32 (gdb) PASS: gdb.base/relativedebug.exp: pause found in backtrace TODO. * `gdb.gdb/selftest.exp` (gdb) PASS: gdb.gdb/selftest.exp: send SIGINT signal to child process backtrace #0 0x0146fafc in ?? () from /lib/i386-gnu/libc.so.0.3 #1 0x014703be in mach_msg () from /lib/i386-gnu/libc.so.0.3 #2 0x0163bd98 in msg_sig_post () from /lib/i386-gnu/libhurduser.so.0.3 #3 0x014b0141 in ?? () from /lib/i386-gnu/libc.so.0.3 #4 0x014b03ed in kill () from /lib/i386-gnu/libc.so.0.3 #5 0x082cf471 in _rl_handle_signal (sig=2) at ../../Ferry_Tagscherer/readline/signals.c:221 #6 0x0148bac2 in ?? () from /lib/i386-gnu/libc.so.0.3 Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) FAIL: gdb.gdb/selftest.exp: backtrace through signal handler This is apparently new with the glibc 2.17 upgrade. Previously it said: (gdb) PASS: gdb.gdb/selftest.exp: send SIGINT signal to child process backtrace #0 0x0144885c in ?? () from /lib/i386-gnu/libc.so.0.3 #1 0x01449069 in mach_msg () from /lib/i386-gnu/libc.so.0.3 #2 0x015ecd4f in msg_sig_post () from /lib/i386-gnu/libhurduser.so.0.3 #3 0x01487683 in ?? () from /lib/i386-gnu/libc.so.0.3 #4 0x014878f6 in kill () from /lib/i386-gnu/libc.so.0.3 #5 0x082cf401 in _rl_handle_signal (sig=2) at ../../Ferry_Tagscherer/readline/signals.c:221 #6 0x01464282 in ?? () from /lib/i386-gnu/libc.so.0.3 #7 0x0144fce3 in ?? () from /lib/i386-gnu/libc.so.0.3 #8 0x0153975b in poll () from /lib/i386-gnu/libc.so.0.3 #9 0x081c91c2 in gdb_wait_for_event (block=1) at ../../Ferry_Tagscherer/gdb/event-loop.c:804 #10 0x081c998f in gdb_do_one_event () at ../../Ferry_Tagscherer/gdb/event-loop.c:402 #11 0x081c9b07 in start_event_loop () at ../../Ferry_Tagscherer/gdb/event-loop.c:431 #12 0x081c2f42 in captured_command_loop (data=data@entry=0x0) at ../../Ferry_Tagscherer/gdb/main.c:260 #13 0x081c0e57 in catch_errors (func=func@entry=0x81c2f30 , func_args=func_args@entry=0x0, errstring=errstring@entry=0x83 5b81b "", mask=mask@entry=6) at ../../Ferry_Tagscherer/gdb/exceptions.c:546 #14 0x081c388c in captured_main (data=data@entry=0x19ff150) at ../../Ferry_Tagscherer/gdb/main.c:1055 #15 0x081c0e57 in catch_errors (func=func@entry=0x81c3130 , func_args=func_args@entry=0x19ff150, errstring=errstring@entry=0x835b 81b "", mask=mask@entry=6) at ../../Ferry_Tagscherer/gdb/exceptions.c:546 #16 0x081c43c0 in gdb_main (args=0x19ff150) at ../../Ferry_Tagscherer/gdb/main.c:1064 #17 0x08099533 in main (argc=5, argv=0x19ff1e8) at ../../Ferry_Tagscherer/gdb/gdb.c:34 (gdb) PASS: gdb.gdb/selftest.exp: backtrace through signal handler TODO. * `gdb.python/python.exp` >PASS: gdb.python/python.exp: post event insertion - gdb.post_event(Foo()) end ERROR: Process no longer exists UNRESOLVED: gdb.python/python.exp: post event insertion - end This is apparently new with the glibc 2.17 upgrade. Previously it said: >PASS: gdb.python/python.exp: post event insertion - gdb.post_event(Foo()) end (gdb) PASS: gdb.python/python.exp: post event insertion - end [More PASSes.] TODO. * `gdb.base/restore.exp`, `gdb.base/store.exp` Several FAILs, starting with GCC 4.8 usage: (gdb) PASS: gdb.base/restore.exp: caller3 calls callee1; return callee now print l1 $16 = (gdb) FAIL: gdb.base/restore.exp: caller3 calls callee1; return restored l1 to 32492 [[!GCC_PR 55056]], [[!message-id "20130126202645.GA4888@host2.jankratochvil.net"]], and maybe [[!message-id "CAO2gOZXvCLdaKE2=ZKpjGVGq8A0wQ94-AUo7eKvvWHWncrU_yg@mail.gmail.com"]] look related. TODO. # Open Issues ## [[tag/open_issue_gdb]] ## `info files` SIGSEGV [[!tag open_issue_gdb]] ### IRC, freenode, #hurd, 2013-09-07 I'm trying to debug pfinet, but I'm not very familiar with gdb. Tried to attach to the running pfinet process (built with debug symbols), set a breakpoint and ... when I ran "info files" the process segfaulted. which process segfaults, pfinet or gdb? gdb segfaults. ## Watchpoints [[!tag open_issue_gdb]] ### IRC, freenode, #hurd, 2013-09-16 tschwinge: Is gdb watch known to fail on hurd? It hangs for me when logged in via ssh. gnu_srs: Don't know about GDB's watch command. Are you sure it is hanging?