aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/README
AgeCommit message (Collapse)AuthorFilesLines
2016-10-06Remove Java supportTom Tromey1-1/+1
This patch removes the Java support from gdb. gcj has not seen much development or use for years now, and was recently removed from GCC. This patch changes gdb to follow; in the unlikely event that there are still users using gcj, they can continue to use an older gdb to debug. Or, they can debug in C++ mode. Built and regtested on x86-64 Fedora 24. 2016-10-06 Tom Tromey <tom@tromey.com> * MAINTAINERS: Remove Java test maintainer. * varobj.h (java_varobj_ops): Don't declare. * valprint.h (struct value_print_options) <pascal_static_field_print>: Update comment. * utils.c (producer_is_gcc): Remove java reference. * symtab.h (struct general_symbol_info): Remove java references. (SYMBOL_SEARCH_NAME): Likewise. * objfiles.c (allocate_objfile): Update comment. * linespec.c (find_linespec_symbols): Remove java references. * gnu-v3-abi.c (gnuv3_rtti_type, gnuv3_baseclass_offset): Remove java references. * gdbtypes.h (struct cplus_struct_type) <is_java>: Remove. (TYPE_CPLUS_REALLY_JAVA): Remove. * c-varobj.c (enum vsections): Update comment. * symtab.c (symbol_set_language, symbol_set_names) (symbol_natural_name, symbol_demangled_name) (demangle_for_lookup, symbol_matches_domain) (default_make_symbol_completion_list_break_on_1): Remove java references. (JAVA_PREFIX, JAVA_PREFIX_LEN): Remove. * psymtab.c (match_partial_symbol, psymtab_search_name) (lookup_partial_symbol): Remove java references. * dwarf2read.c (find_slot_in_mapped_hash): Remove java references. (add_partial_symbol, dwarf2_compute_name, dwarf2_physname) (dwarf2_add_member_fn, is_vtable_name, read_structure_type) (process_structure_scope, read_subroutine_type) (read_subrange_type, load_partial_dies) (new_symbol_full, determine_prefix, typename_concat) (dwarf2_name): Remove java references. (set_cu_language): Treat Java as C++. * c-typeprint.c (c_type_print_args): Remove java reference. * defs.h (enum language) <language_java>: Remove. * Makefile.in (SFILES, HFILES_NO_SRCDIR, COMMON_OBS, YYFILES) (YYOBJ, local-maintainer-clean): Don't mention java files. * jv-exp.y, jv-lang.c, jv-lang.h, jv-typeprint.c, jv-valprint.c, jv-varobj.c: Remove. 2016-10-06 Tom Tromey <tom@tromey.com> * guile.texi (Types In Guile): Remove Java mentions. * python.texi (Types In Python): Remove Java mentions. * gdb.texinfo (Address Locations, Supported Languages) (Index Section Format): Remove Java mentions. 2016-10-06 Tom Tromey <tom@tromey.com> * gdb.compile/compile.exp: Change java tests to rust. * gdb.base/setshow.exp: Change java tests to rust. * gdb.base/default.exp: Remove java from language list. * README (Examples): Update language example. * gdb.python/py-lookup-type.exp (test_lookup_type): Remove java test. * lib/gdb.exp (skip_java_tests): Remove. * lib/java.exp: Remove. * gdb.java: Remove.
2016-06-21Add testing infrastruture bits for running with MI on a separate UIPedro Alves1-0/+6
With this, a specific test may can start GDB with MI on a separate UI by using: mi_gdb_start separate-mi-tty In addition, it's also possible to run the whole testsuite with MI on a separate tty, with: make check RUNTESTFLAGS="FORCE_SEPARATE_MI_TTY=1" gdb_main_spawn_id and mi_spawn_id are added so that tests may expect output from either channel. While at it, inferior_spawn_id was not being cleared when gdb exits, unlike the other spawn ids, thus a test that starts gdb more than once would end up using a stale spawn id. gdb/testsuite/ChangeLog: 2016-06-21 Pedro Alves <palves@redhat.com> * README (Testsuite Parameters): Document FORCE_SEPARATE_MI_TTY. * lib/gdb.exp (default_gdb_exit): Clear inferior_spawn_id. * lib/mi-support.exp (mi_uncatched_gdb_exit): Unset gdb_main_spawn_id, mi_spawn_id, unset inferior_spawn_id. (gdb_main_spawn_id, mi_spawn_id): Declare and comment. (mi_create_inferior_pty): New procedure, factored out from default_mi_gdb_start. (switch_gdb_spawn_id, mi_gdb_start_separate_mi_tty): New procedures. (default_mi_gdb_start): Call mi_gdb_start_separate_mi_tty if the separate-mi-tty option is specified, or SEPARATE_MI_TTY is set. Use mi_create_inferior_pty. (mi_gdb_start): Use eval to pass down args list.
2016-03-05Improve analysis of racy testcasesSergio Durigan Junior1-0/+45
This is an initial attempt to introduce some mechanisms to identify racy testcases present in our testsuite. As can be seen in previous discussions, racy tests are really bothersome and cause our BuildBot to pollute the gdb-testers mailing list with hundreds of false-positives messages every month. Hopefully, identifying these racy tests in advance (and automatically) will contribute to the reduction of noise traffic to gdb-testers, maybe to the point where we will be able to send the failure messages directly to the authors of the commits. I spent some time trying to decide the best way to tackle this problem, and decided that there is no silver bullet. Racy tests are tricky and it is difficult to catch them, so the best solution I could find (for now?) is to run our testsuite a number of times in a row, and then compare the results (i.e., the gdb.sum files generated during each run). The more times you run the tests, the more racy tests you are likely to detect (at the expense of waiting longer and longer). You can also run the tests in parallel, which makes things faster (and contribute to catching more racy tests, because your machine will have less resources for each test and some of them are likely to fail when this happens). I did some tests in my machine (8-core i7, 16GB RAM), and running the whole GDB testsuite 5 times using -j6 took 23 minutes. Not bad. In order to run the racy test machinery, you need to specify the RACY_ITER environment variable. You will assign a number to this variable, which represents the number of times you want to run the tests. So, for example, if you want to run the whole testsuite 3 times in parallel (using 2 cores), you will do: make check RACY_ITER=3 -j2 It is also possible to use the TESTS variable and specify which tests you want to run: make check TEST='gdb.base/default.exp' RACY_ITER=3 -j2 And so on. The output files will be put at the directory gdb/testsuite/racy_outputs/. After make invokes the necessary rules to run the tests, it finally runs a Python script that will analyze the resulting gdb.sum files. This Python script will read each file, and construct a series of sets based on the results of the tests (one set for FAIL's, one for PASS'es, one for KFAIL's, etc.). It will then do some set operations and come up with a list of unique, sorted testcases that are racy. The algorithm behind this is: for state in PASS, FAIL, XFAIL, XPASS...; do if a test's state in every sumfile is $state; then it is not racy else it is racy (The algorithm is actually a bit more complex than that, because it takes into account other things in order to decide whether the test should be ignored or not). IOW, a test must have the same state in every sumfile. After processing everything, the script prints the racy tests it could identify on stdout. I am redirecting this to a file named racy.sum. Something else that I wasn't sure how to deal with was non-unique messages in our testsuite. I decided to do the same thing I do in our BuildBot: include a unique identifier in the end of message, like: gdb.base/xyz.exp: non-unique message gdb.base/xyz.exp: non-unique message <<2>> This means that you will have to be careful about them when you use the racy.sum file. I ran the script several times here, and it did a good job catching some well-known racy tests. Overall, I am satisfied with this approach and I think it will be helpful to have it upstream'ed. I also intend to extend our BuildBot and create new, specialized builders that will be responsible for detecting the racy tests every X number of days. 2016-03-05 Sergio Durigan Junior <sergiodj@redhat.com> * Makefile.in (DEFAULT_RACY_ITER): New variable. (CHECK_TARGET_TMP): Likewise. (check-single-racy): New rule. (check-parallel-racy): Likewise. (TEST_TARGETS): Adjust rule to account for RACY_ITER. (do-check-parallel-racy): New rule. (check-racy/%.exp): Likewise. * README (Racy testcases): New section. * analyze-racy-logs.py: New file.
2016-02-11Add missing quotes to gdb/testsuite/READMEPedro Alves1-2/+2
gdb/testsuite/ChangeLog: 2016-02-11 Pedro Alves <palves@redhat.com> * README (Parallel testing): Add missing double quotes.
2016-02-11Support 'make check-parallel' in gdb's build dirPedro Alves1-13/+37
Currently, you can cd to the gdb/testsuite/ dir and use make check-parallel, instead of using FORCE_PARALLEL: $ make -j8 check-parallel RUNTESTFLAGS="--target_board=native-gdbserver" $ make -j8 check RUNTESTFLAGS="--target_board=native-gdbserver" FORCE_PARALLEL=1 But you can't do that in the build/gdb/ dir: $ make check-parallel RUNTESTFLAGS="--target_board=native-gdbserver" make: *** No rule to make target `check-parallel'. Stop. I find check-parallel a bit more convenient, and more typo-proof, so this patch makes it work from the gdb build dir too. While documenting this in testsuite/README, I found that the parallel testing mode would better be pulled out to its own section and extended. gdb/ChangeLog: 2016-02-11 Pedro Alves <palves@redhat.com> * Makefile.in (check-parallel): New rule. gdb/testsuite/ChangeLog: 2016-02-11 Pedro Alves <palves@redhat.com> * README (Parallel testing): New section. (GDB_PARALLEL): Rewrite. (FORCE_PARALLEL): Document.
2015-11-26Add test for thread namesSimon Marchi1-0/+3
I couldn't find a test that verified the thread name functionality, so I created a new one. A target board can define gdb,no_thread_names if it doesn't support thread names and wants to skip the tests that uses them. This test has been made with Linux in mind. Not all platforms use pthread_setname_np to set the thread name, but some #ifdefs can be added later in order to support other platforms. Tested on x86-64 Ubuntu 14.04, native and remote. gdb/testsuite/ChangeLog: * gdb.threads/names.exp: New file. * gdb.threads/names.c: New file. * README: Mention gdb,no_thread_names.
2015-03-20Remove gdb.hpJan Kratochvil1-2/+1
gdb/ChangeLog 2015-03-20 Jan Kratochvil <jan.kratochvil@redhat.com> * config/djgpp/README: Remove gdb.hp. gdb/testsuite/ChangeLog 2015-03-20 Jan Kratochvil <jan.kratochvil@redhat.com> * Makefile.in (ALL_SUBDIRS): Remove gdb.hp. * README: Remove HP-UX and gdb.hp. (configuration): * configure: Regenerate. * configure.ac (AC_OUTPUT): Remove gdb.hp/Makefile, gdb.hp/gdb.objdbg/Makefile, gdb.hp/gdb.base-hp/Makefile, gdb.hp/gdb.aCC/Makefile, gdb.hp/gdb.compat/Makefile, gdb.hp/gdb.defects/Makefile. * gdb.hp/Makefile.in: File deleted. * gdb.hp/gdb.aCC/Makefile.in: File deleted. * gdb.hp/gdb.aCC/optimize.c: File deleted. * gdb.hp/gdb.aCC/optimize.exp: File deleted. * gdb.hp/gdb.aCC/run.c: File deleted. * gdb.hp/gdb.aCC/watch-cmd.exp: File deleted. * gdb.hp/gdb.base-hp/Makefile.in: File deleted. * gdb.hp/gdb.base-hp/callfwmall.c: File deleted. * gdb.hp/gdb.base-hp/callfwmall.exp: File deleted. * gdb.hp/gdb.base-hp/dollar.c: File deleted. * gdb.hp/gdb.base-hp/dollar.exp: File deleted. * gdb.hp/gdb.base-hp/genso-thresh.c: File deleted. * gdb.hp/gdb.base-hp/hwwatchbus.c: File deleted. * gdb.hp/gdb.base-hp/hwwatchbus.exp: File deleted. * gdb.hp/gdb.base-hp/pxdb.c: File deleted. * gdb.hp/gdb.base-hp/pxdb.exp: File deleted. * gdb.hp/gdb.base-hp/reg-pa64.exp: File deleted. * gdb.hp/gdb.base-hp/reg-pa64.s: File deleted. * gdb.hp/gdb.base-hp/reg.exp: File deleted. * gdb.hp/gdb.base-hp/reg.s: File deleted. * gdb.hp/gdb.base-hp/sized-enum.c: File deleted. * gdb.hp/gdb.base-hp/sized-enum.exp: File deleted. * gdb.hp/gdb.base-hp/so-thresh.exp: File deleted. * gdb.hp/gdb.base-hp/so-thresh.mk: File deleted. * gdb.hp/gdb.base-hp/so-thresh.sh: File deleted. * gdb.hp/gdb.compat/Makefile.in: File deleted. * gdb.hp/gdb.compat/average.c: File deleted. * gdb.hp/gdb.compat/sum.c: File deleted. * gdb.hp/gdb.compat/xdb.c: File deleted. * gdb.hp/gdb.compat/xdb0.c: File deleted. * gdb.hp/gdb.compat/xdb0.h: File deleted. * gdb.hp/gdb.compat/xdb1.c: File deleted. * gdb.hp/gdb.compat/xdb1.exp: File deleted. * gdb.hp/gdb.compat/xdb2.exp: File deleted. * gdb.hp/gdb.compat/xdb3.exp: File deleted. * gdb.hp/gdb.defects/Makefile.in: File deleted. * gdb.hp/gdb.defects/bs14602.c: File deleted. * gdb.hp/gdb.defects/bs14602.exp: File deleted. * gdb.hp/gdb.defects/solib-d.c: File deleted. * gdb.hp/gdb.defects/solib-d.exp: File deleted. * gdb.hp/gdb.defects/solib-d1.c: File deleted. * gdb.hp/gdb.defects/solib-d2.c: File deleted. * gdb.hp/gdb.objdbg/Makefile.in: File deleted. * gdb.hp/gdb.objdbg/objdbg01.exp: File deleted. * gdb.hp/gdb.objdbg/objdbg01/x1.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg01/x2.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg01/x3.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg01/x3.h: File deleted. * gdb.hp/gdb.objdbg/objdbg02.exp: File deleted. * gdb.hp/gdb.objdbg/objdbg02/x1.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg02/x2.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg02/x3.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg03.exp: File deleted. * gdb.hp/gdb.objdbg/objdbg03/x1.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg03/x2.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg03/x3.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg04.exp: File deleted. * gdb.hp/gdb.objdbg/objdbg04/x.h: File deleted. * gdb.hp/gdb.objdbg/objdbg04/x1.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg04/x2.cc: File deleted. * gdb.hp/gdb.objdbg/tools/symaddr: File deleted. * gdb.hp/gdb.objdbg/tools/symaddr.pa64: File deleted. * gdb.hp/gdb.objdbg/tools/test-objdbg.cc: File deleted. * gdb.hp/tools/odump: File deleted.
2014-12-15 * Makefile.in (check-gdb.%): Restore.Jason Merrill1-1/+3
* README: Mention it.
2014-08-20Integrate PR 12649's race detector directly in the testsuite machineryPedro Alves1-0/+41
This integrates Jan Kratochvil's nice race reproducer from PR testsuite/12649 into the testsuite infrustructure directly. With this, one only has to do either 'make check-read1' or 'make check READ1="1"' to preload the read1.so library into expect. Currently only enabled for glibc/GNU systems, and if build==host==target. gdb/testsuite/ChangeLog: * Makefile.in (EXTRA_RULES, CC): New variables, get from configure. (EXPECT): Handle READ1 being set. (all): Depend on EXTRA_RULES. (check-read1, expect-read1, read1.so, read1): New rules. * README (Testsuite Parameters): Document the READ1 make variable. (Race detection): New section. * configure: Regenerate. * configure.ac: If build==host==target, and running under a GNU/glibc system, add read1 to the extra Makefile rules. (EXTRA_RULES): AC_SUBST it. * lib/read1.c: New file. gdb/ChangeLog: * Makefile.in (check-read1): New rule.
2014-07-12gdb/testsuite: Add a way to send multiple init commandsMaciej W. Rozycki1-0/+10
Right now we provide a board info entry, `gdb_init_command', that allows one to send a single command to GDB before the program to be debugged is started. This is useful e.g. for slow remote targets to change the default "remotetimeout" setting. Occasionally I found a need to send multiple commands instead, however this cannot be achieved with `gdb_init_command'. This change therefore extends the mechanism by adding a TCL list of GDB commands to send, via a board info entry called `gdb_init_commands'. There is no limit as to the number of commands put there. The old `gdb_init_command' mechanism remains supported for compatibility with existing people's environments. * lib/gdb-utils.exp: New file. * lib/gdb.exp (gdb_run_cmd): Call gdb_init_commands, replacing inline `gdb_init_command' processing. (gdb_start_cmd): Likewise. * lib/mi-support.exp (mi_run_cmd): Likewise. * README: Document `gdb_init_command' and `gdb_init_commands'.
2014-05-20Set timeout for gdb.reverse/*.exp test casesYao Qi1-0/+9
Hi, This patch is to add a new board setting gdb_reverse_timeout, which is used to set timeout for all gdb.reverse test cases, which are usually very slow and cause some TIMEOUT failures, for example, on some arm boards. We have some alternatives to this approach, but I am not satisfied with them: - Increase the timeout value. This is the global change, and it may cause some delay where actual failures happen. - Set timeout by gdb_reverse_timeout in every gdb.reverse/*.exp. Then, we have to touch every file under gdb.reverse. In this patch, we choose a central place to set timeout for all tests in gdb.reverse, which is convenient. gdb/testsuite: 2014-05-20 Yao Qi <yao@codesourcery.com> * lib/gdb.exp (gdb_init): Set timeout if test file is under gdb.reverse directory and gdb_reverse_timeout exists in board setting. * README: Document gdb_reverse_timeout.
2014-02-18New TESTS variable to run a subset of tests in parallel.Doug Evans1-0/+24
* Makefile.in (TESTS): New variable. (expanded_tests, expanded_tests_or_none): New variables (check-single): Pass $(expanded_tests_or_none) to runtest. (check-parallel): Only run tests in $(TESTS) if non-empty. (check/no-matching-tests-found): New rule. * README: Document TESTS makefile variable.
2013-11-06Mention perf test in testsuite/READMEYao Qi1-0/+27
gdb/testsuite: 2013-11-06 Yao Qi <yao@codesourcery.com> * README: Mention performance tests.
2013-10-02Teach the testsuite that GDBserver reliably reports program exits.Pedro Alves1-0/+9
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.
2013-09-12 * README: New file.Stan Shebs1-0/+382