| Age | Commit message (Collapse) | Author |
|---|
|
This commit finally clears the "isremote" flag in the native-gdbserver
and native-stdio-gdbserver boards. The goal is to make all "native"
boards be considered not remote in DejaGnu terms, like the
native-extended-gdbserver board is too.
DejaGnu automatically considers boards remote if their names don't
match the local hostname. That means that native-gdbserver and
native-extended-gdbserver are considered remote by default by DejaGnu,
even though they run locally. native-extended-gdbserver, however,
overrides its isremote flag to force it to be not remote. So we are
in that weird state where native-gdbserver is considered remote, and
native-extended-gdbserver is considered not remote.
A recent set of commits fixed all the problems (and some more) exposed
by testing with --target_board=native-gdbserver and
--target_board=native-stdio-gdbserver with isremote forced off on
x86-64 GNU/Linux. I believe we're good to go now.
The native-stdio-gdbserver.exp/remote-stdio-gdbserver.exp boards
required deep non-obvious modifications unfortunately... The problem
is that if a board is not remote, then DejaGnu doesn't call
${board}_spawn / ${board}_exec at all, and the
native-stdio-gdbserver.exp board relies on those procedures being
called. To fix that, this commit redesigns how the stdio boards hook
into the testing framework to spawn gdbserver. IMO, this is a good
change anyway, because the way its done currently is a bit of a hack,
and the result turns out to be simpler, even. With this commit, they
now no longer load the "gdbserver" generic config, and hook at the
mi_gdb_target_load/gdb_reload level instead, making them more like
traditional board files.
To share code between native-stdio-gdbserver.exp and
remote-stdio-gdbserver.exp, a new shared stdio-gdbserver-base.exp file
is created.
Instead of having each native board clear isremote manually, boards
source the new "local-board.exp" file.
This also adds a new section to testsuite/README file discussing
local/remote/native, so that we can easily refer to it.
gdb/testsuite/ChangeLog:
2017-10-16 Pedro Alves <palves@redhat.com>
Simon Marchi <simon.marchi@polymtl.ca>
* README (Local vs Remote vs Native): New section.
* boards/local-board.exp: New file, with bits factored out from
...
* boards/native-extended-gdbserver.exp: ... here. Load
"local-board".
* boards/native-gdbserver.exp: Load "local-board".
(${board}_spawn, ${board}_exec): Delete.
* boards/native-stdio-gdbserver.exp: Most contents factored out to
...
* boards/stdio-gdbserver-base.exp: ... this new file.
* boards/native-stdio-gdbserver.exp: Reimplement, by loading
"stdio-gdbserver-base" and defining a get_target_remote_pipe_cmd
procedure.
* boards/remote-stdio-gdbserver.exp: Load stdio-gdbserver-base
instead of native-stdio-gdbserver. Don't set gdb_server_prog nor
stdio_gdbserver_command.
(${board}_get_remote_address, ${board}_get_comm_port)
(${board}_download, ${board}_upload): Delete.
(get_target_remote_pipe_cmd): New.
|
|
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.
|
|
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.
|
|
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.
|
|
gdb/testsuite/ChangeLog:
2016-02-11 Pedro Alves <palves@redhat.com>
* README (Parallel testing): Add missing double quotes.
|
|
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.
|
|
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.
|
|
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.
|
|
* README: Mention it.
|
|
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.
|
|
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'.
|
|
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.
|
|
* 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.
|
|
gdb/testsuite:
2013-11-06 Yao Qi <yao@codesourcery.com>
* README: Mention performance tests.
|
|
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.
|
|
|
