diff options
author | Pedro Alves <palves@redhat.com> | 2013-10-02 11:44:20 +0000 |
---|---|---|
committer | Pedro Alves <palves@redhat.com> | 2013-10-02 11:44:20 +0000 |
commit | b477a5e649150a2ed9c5090b01989e746d65cef5 (patch) | |
tree | e2f1366c7a649dbd8c47d2df3057b15f8a66c5ea /gdb/testsuite/boards | |
parent | 1a3d890bcc0e6f9fe0116b3274023ae0af847593 (diff) | |
download | gdb-b477a5e649150a2ed9c5090b01989e746d65cef5.zip gdb-b477a5e649150a2ed9c5090b01989e746d65cef5.tar.gz gdb-b477a5e649150a2ed9c5090b01989e746d65cef5.tar.bz2 |
Teach the testsuite that GDBserver reliably reports program exits.
Running catch-syscall.exp against a gdbserver that actually supports
it, we get:
FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
FAIL: gdb.base/catch-syscall.exp: continue until exit at catch syscall with unused syscall (mlock) (the program exited)
FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
The fail pattern is:
Catchpoint 2 (call to syscall exit_group), 0x000000323d4baa29 in _exit () from /lib64/libc.so.6
(gdb) PASS: gdb.base/catch-syscall.exp: program has called exit_group
delete breakpoints
Delete all breakpoints? (y or n) y
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break exit
Breakpoint 3 at 0x323d438bf0
(gdb) continue
Continuing.
[Inferior 1 (process 21081) exited normally]
That "break exit" + "continue" comes from:
> # gdb_continue_to_end:
> # The case where the target uses stubs has to be handled specially. If a
> # stub is used, we set a breakpoint at exit because we cannot rely on
> # exit() behavior of a remote target.
> #
The native-gdbserver.exp board, used to test against gdbserver in
"target remote" mode, triggers that case ($use_gdb_stub is true). So
gdb_continue_to_end doesn't work for catch-syscall.exp as here we
catch the exit_group and continue from that, expecting to see a real
program exit. I was about to post a patch that changes
catch-syscall.exp to call a new function that just always does what
gdb_continue_to_end does in the !$use_gdb_stub case. But, since
GDBserver doesn't really need this, in the end I thought it better to
teach the testsuite that there are stubs that know how to report
program exits, by adding a new "exit_is_reliable" board variable that
then gdb_continue_to_end checks.
Tested on x86_64 Fedora 17, native and gdbserver.
gdb/testsuite/
2013-10-02 Pedro Alves <palves@redhat.com>
* README (Board Settings): Document "exit_is_reliable".
* lib/gdb.exp (gdb_continue_to_end): Check whether the board says
running to exit reliably reports program exits.
* boards/native-gdbserver.exp: Set exit_is_reliable in the board
info.
* boards/native-stdio-gdbserver.exp: Likewise.
Diffstat (limited to 'gdb/testsuite/boards')
-rw-r--r-- | gdb/testsuite/boards/native-gdbserver.exp | 1 | ||||
-rw-r--r-- | gdb/testsuite/boards/native-stdio-gdbserver.exp | 1 |
2 files changed, 2 insertions, 0 deletions
diff --git a/gdb/testsuite/boards/native-gdbserver.exp b/gdb/testsuite/boards/native-gdbserver.exp index 6c1430f..ab239ec 100644 --- a/gdb/testsuite/boards/native-gdbserver.exp +++ b/gdb/testsuite/boards/native-gdbserver.exp @@ -31,6 +31,7 @@ set_board_info noargs 1 set_board_info sockethost "localhost:" set_board_info use_gdb_stub 1 +set_board_info exit_is_reliable 1 # We will be using the standard GDB remote protocol. set_board_info gdb_protocol "remote" diff --git a/gdb/testsuite/boards/native-stdio-gdbserver.exp b/gdb/testsuite/boards/native-stdio-gdbserver.exp index 3b99909..a093904 100644 --- a/gdb/testsuite/boards/native-stdio-gdbserver.exp +++ b/gdb/testsuite/boards/native-stdio-gdbserver.exp @@ -34,6 +34,7 @@ set_board_info sockethost "stdio" set_board_info gdb,socketport "" set_board_info gdb,get_remote_address ${board}_get_remote_address set_board_info use_gdb_stub 1 +set_board_info exit_is_reliable 1 # We will be using the standard GDB remote protocol. set_board_info gdb_protocol "remote" |