[[!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
<!--
git checkout reviewed
git diff --patience --stat=$COLUMNS,$COLUMNS --patch --src-prefix=./ --dst-prefix=./ --find-renames --ignore-space-change ..sourceware/master | awk '/^diff/ { c = " " $0; } /^@@/ { print c; } { print; }' | less
-i
/^---.*/([^.]*|.*\.texi.*|[^/]*gnu[^/]*)$|hurd|linux|nacl|nptl|glibc|gs:
-->
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.
<!--
$ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-test) 2>&1 | tee log_install && test -f .go-test && make -k check 2>&1 | tee log_test
-->
## 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.InferiorThread object at 0x61170>, <gdb.InferiorThread object at 0x61160>)
(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, `<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`
* `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:
<gnu_srs1> How to debug a program that works in the shell but Cannot
access memory at address ... in gdb?
<tschwinge> 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.
<gnu_srs1> tschwinge: looks like -fPIE is used.
<gnu_srs1> 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 [<function called from gdb>]
(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 <signal handler called>
#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=<synthetic pointer>) 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 <captured_command_loop>, 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 <captured_main>, 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 = <optimized out>
(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
<rekado> 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.
<teythoon> which process segfaults, pfinet or gdb?
<rekado> gdb segfaults.
## 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?