GNU Hurd/ open issues/ gdb

Welcome to... ... the GNU Hurd!

Here's what's to be done for maintaining GNU GDB.

  1. General information
  2. Sources
  3. Configuration
  4. Build
    1. Analysis
  5. Install
    1. Analysis
  6. Testsuite
    1. Analysis

General information

Sources

Configuration

Last reviewed up to the Git mirror's 6330ab576e18fb97912839fc116c7babb5fd8c70 (2013-04-28) sources.

  • 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.

Build

Here's a log of a GDB build run; this is from our Git repository's tschwinge/Ferry_Tagscherer branch, commit 6330ab576e18fb97912839fc116c7babb5fd8c70 (2013-04-28), run on kepler.SCHWINGE and coulomb.SCHWINGE.

$ export LC_ALL=C
$ ../Ferry_Tagscherer/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.7 CXX=g++-4.7 --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 210 MiB and needs roughly 9 min on kepler.SCHWINGE and 25 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' []

  • dlopen/-ldl

    -checking for library containing dlopen... none required
+checking for library containing dlopen... -ldl

  • O_NOFOLLOW

    First seen in 20f498edfd7e57d3297febcf9c7c7d667cc74239..69a5e2b022c7d15ec4c7c49e6f53a8d924d3b72b:

    -checking for working fcntl.h... yes
+checking for working fcntl.h... no (bad O_NOFOLLOW)

    open issue glibc?

  • Why does GNU/Linux have an additional -ldl -rdynamic when linking gdb?

  • 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 **'

  • 6b25dae901ddedb3f330803542d3eac73cdcae4b..6330ab576e18fb97912839fc116c7babb5fd8c70:

     gcc-4.7 -c -DHAVE_CONFIG_H -g -O2  -I. -I../../Ferry_Tagscherer/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ../../Ferry_Tagscherer/libiberty/hashtab.c -o hashtab.o
+../../Ferry_Tagscherer/libiberty/hashtab.c: In function 'hash_pointer':
+../../Ferry_Tagscherer/libiberty/hashtab.c:1001:7: warning: right shift count >= width of type [enabled by default]

Install

$ make install 2>&1 | tee log_install
[...]

This takes up around 50 MiB, and needs roughly 1 min on kepler.SCHWINGE and 2 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 14 min on kepler.SCHWINGE and 70 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. killing 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

$ 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.

  • 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

    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

  • 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.arch/i386-float.exp: info float

    Running ../../../Ferry_Tagscherer/gdb/testsuite/gdb.arch/i386-float.exp ...
PASS: gdb.arch/i386-float.exp: first stepi
FAIL: gdb.arch/i386-float.exp: info float
PASS: gdb.arch/i386-float.exp: second stepi
PASS: gdb.arch/i386-float.exp: info float

    Only fails for GNU/Hurd: the floating point stack initially is not all-zeroes, which is expected, and which it is on GNU/Linux.

TODO.