Starting with this commit:
commit e7ea3ec7c6
Author: Catalin Udma <catalin.udma@freescale.com>
Date: Mon Feb 29 16:16:19 2016 +0200
python: Use console format for output of gdb.execute command
the python script would use console format for gdb.execute output.
This patch fixes py-mi-objfile to expect the console format when is
checking for gdb.execute printing.
gdb/testsuite/ChangeLog:
2016-04-05 Catalin Udma <catalin.udma@freescale.com>
* gdb.python/py-mi-objfile-gdb.py: Use "list main" command.
* gdb.python/py-mi-objfile.exp: Match "list main" output
in console format.
Signed-off-by: Catalin Udma <catalin.udma@freescale.com>
In commit 6e774b13c3, I forgot to update this test.
gdb/testsuite/ChangeLog:
* gdb.arch/ftrace-insn-reloc.exp: Check for IPA basename instead of
absolute.
When we build a shared library for testing, it is built differently
whether it is meant for the local system or a remote one. When it is
for the local system, the library is built with no SONAME. So when the
executable is built, roughly in this way:
$ gcc testfile.c /path/to/library.so
the executable will contain an absolute reference to the library. For
example:
$ readelf -a testsuite/gdb.python/py-shared | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [/home/emaisin/build/binutils-gdb/gdb/testsuite/gdb.python/py-shared-sl.sl]
When testing is done remotely, the absolute path obviously doesn't work.
Therefore, we build the library with an SONAME:
$ readelf -a testsuite/gdb.python/py-shared-sl.sl | grep SONAME
0x000000000000000e (SONAME) Library soname: [py-shared-sl.sl]
which ends up in the executable's NEEDED field:
$ readelf -a testsuite/gdb.python/py-shared | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [py-shared-sl.sl]
The executable and the library are then uploaded side-by-side on the
remote system. To allow the dynamic linker to find the shared library,
we have to add the special RPATH value $ORIGIN, which tells it to search
in the executable's directory:
$ readelf -a testsuite/gdb.python/py-shared | grep ORIGIN
0x000000000000000f (RPATH) Library rpath: [$ORIGIN]
The problem with the IPA library is that it doesn't have an SONAME,
making it very difficult to do testing on a remote board. When a
test executable is linked with it, it contains an absolute reference to
the library path. Therefore, unless the paths on the target are the
same as on the build system, it won't work.
To make it possible for tests using the IPA library to run test on
remote boards, I suggest adding an SONAME to libinproctrace.so. I don't
think it should be a big problem for users. All the libraries installed
on my system have an SONAME, so it should be fine if libinproctrace.so
does too.
As a consequence, native testing does not work anymore, since
executables do not contain the absolute path to the library anymore. To
keep them working, we can have gdb_load_shlibs copy the library to the
test directory when testing natively. That's done by modifying
gdb_load_shlibs. We also have to add RPATH=$ORIGIN to executables, even
when testing natively.
I think it's a good change in general, as it reduces the differences
between testing a native and a remote target. To further reduce those
differences, we can also always build test shared libraries with an
SONAME.
ftrace.exp and ftrace-lock.exp need to be modified slightly. The code
checks that the IPA library is loaded using the absolute path on the
build machine. That obviously doesn't work if the test is done
remotely, as the path will be different. I changed the tests to only
search for the library basename (e.g. libinproctrace.so).
gdb/gdbserver/ChangeLog:
* Makefile.in ($(IPA_LIB)): Set SONAME of the IPA lib.
gdb/testsuite/ChangeLog:
* gdb.trace/ftrace-lock.exp: Check for IPA basename instead of
absolute.
* gdb.trace/ftrace.exp: Likewise.
* lib/gdb.exp (gdb_compile): Set rpath $ORIGIN for non-remote
targets as well.
(gdb_compile_shlib): Set SONAME for non-remote targets as well.
(gdb_load_shlibs): Copy libraries to test directory when testing
natively. Only set solib-search-path if testing remotely.
* lib/mi-support.exp (mi_load_shlibs): Likewise.
This patch removes gdb_download in favor of gdb_remote_download, since
they are very close in functionality. Also, in preparation for the
following patch about shared library handling during tests, it improves
gdb_remote_download so that it uses standard_output_file for any
destination board that is local, not only host.
If the destination board is remote, gdb_remote_download will use the
standard remote_download from DejaGnu, resulting in the file being
transferred on the remote system.
If the destination is local, gdb_remote_download will copy the file to
the standard test directory (found using standard_output_file). Tcl's
file copy seems to handle gracefully cases where the source file is the
same as the destination, so I don't think it's necessary to check for
that case ourselves, as a previous version of the patch did.
I'd prefer to keep the name gdb_download instead of gdb_remote_download,
since I don't like the fact that gdb_remote_download implies that the
destination is remote, when it's not always the case. However,
gdb_remote_download is used at many more places than gdb_download, so
it's easier to reuse that. Also, since it's a wrapper around DejaGnu's
remote_download, it might be better to keep that name. I don't know.
I ran the testsuite native, with native-gdbserver and with a
remote gdbserver, and didn't see any related failure.
gdb/testsuite/ChangeLog:
* gdb.base/jit-so.exp: Use gdb_remote_download instead of
gdb_download. Use it even if the target is not remote.
* gdb.base/jit.exp (compile_jit_test): Likewise.
* lib/gdb.exp (gdb_remote_download): Copy files to the standard
output directory if the destination board is local, otherwise use
the standard remote_download from DejaGnu.
(gdb_download): Remove.
(gdb_load_shlibs): Use gdb_remote_download instead of
gdb_download.
* lib/gdbserver-support.exp (gdbserver_download_current_prog):
Use gdb_remote_download instead of gdb_download. Use it even if
the target is not remote.
* lib/mi-support.exp (mi_load_shlibs): Use gdb_remote_download
instead of gdb_download.
The libraries are never downloaded to the target for the first test
(test_insert_delete_modify), so the executable can't run properly.
I also added some with_test_prefix to help differentiate between the
different test case phases.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-breakpoint-changed.exp: Add some with_test_prefix.
(test_insert_delete_modify): Call mi_load_shlibs before trying to
run.
This patch adds support for TYPE_CODE_ENUM values to be supplied
as right-hand side operand of the BINOP_REPEAT (@) operator. The
following should now work:
enum {
sz = 17
};
int
main ()
{
int arr[sz + 1] = { 0 };
return 0; /* line 9 here */
}
(gdb) b 9
(gdb) r
(gdb) p arr@sz
$1 = {0 <repeats 17 times>}
(gdb)
A couple of tests is also included in this patch to demonstrate that it is
working as intended.
gdb/Changelog:
2016-04-01 Artemiy Volkov <artemiyv@acm.org>
PR gdb/19820
* eval.c (evaluate_subexp_standard): Allow TYPE_CODE_ENUM to be
the type of BINOP_REPEAT's second operand.
gdb/testsuite/Changelog:
2016-04-01 Artemiy Volkov <artemiyv@acm.org>
PR gdb/19820
* gdb.base/printcmds.exp: Add artificial arrays tests.
This test would fail without the previous gdb/jit.c fix:
(gdb) attach 23031
Attaching to program: .../build/gdb/testsuite/outputs/gdb.base/jit/jit-main, process 23031
[...]
207 WAIT_FOR_GDB; i = 0; /* gdb break here 1 */
(gdb) PASS: gdb.base/jit.exp: attach: one_jit_test-2: attach
set var wait_for_gdb = 0
(gdb) PASS: gdb.base/jit.exp: attach: one_jit_test-2: set var wait_for_gdb = 0
info function ^jit_function
All functions matching regular expression "^jit_function":
(gdb) FAIL: gdb.base/jit.exp: attach: one_jit_test-2: info function ^jit_function
gdb/testsuite/ChangeLog:
2016-03-31 Pedro Alves <palves@redhat.com>
PR gdb/19858
* gdb.base/jit-main.c: Include unistd.h.
(ATTACH): Define to 0 if not already defined.
(wait_for_gdb, mypid): New globals.
(WAIT_FOR_GDB): New macro.
(MAIN): Set an alarm. Store the process's pid. Wait for GDB at
some breakpoint locations.
* gdb.base/jit.exp (clean_reattach, continue_to_test_location):
New procedures.
(one_jit_test): Add REATTACH parameter, and handle it. Use
continue_to_test_location.
(top level): Test attach, and adjusts calls to one_jit_test.
This testcase compiles the same program and library differently
multiple times using the same file names. Make them unique, to make
it easier to debug test problems.
gdb/testsuite/ChangeLog:
2016-03-31 Pedro Alves <palves@redhat.com>
PR gdb/19858
* gdb.base/jit.exp (compile_jit_test): Add intro comment. Add
BINSUFFIX parameter, and handle it.
(top level): Adjust calls compile_jit_test.
When gdb is started in MI mode, the output of gdb.execute
command is in MI-format in case when it is executed from python stop
handler while for all other cases the output is in console-format.
To assure consistent output format, this is fixed by using the console
format for all python gdb command executions.
PR python/19743
gdb/ChangeLog:
2016-03-31 Catalin Udma <catalin.udma@freescale.com>
PR python/19743
* python/python.c (execute_gdb_command): Use console uiout
when executing gdb command.
* utils.c (restore_ui_out_closure): New structure.
(do_restore_ui_out): New function.
(make_cleanup_restore_ui_out): Likewise.
* utils.h (make_cleanup_restore_ui_out): Declare.
gdb/testsuite/ChangeLog:
2016-03-31 Catalin Udma <catalin.udma@freescale.com>
PR python/19743
* gdb.python/py-mi-events-gdb.py: New file.
* gdb.python/py-mi-events.c: New file.
* gdb.python/py-mi-events.exp: New file.
Signed-off-by: Catalin Udma <catalin.udma@freescale.com>
Nowadays, functions fprintf, printf and malloc are executed in
gdb.reverse/until-reverse.c, so that it takes much time to record
instructions inside them. This may cause timeout, and we had several
fixes to bump the timeout,
https://sourceware.org/ml/gdb-patches/2012-02/msg00038.htmlhttps://sourceware.org/ml/gdb-patches/2015-08/msg00186.html
also I still see this on arm-linux,
continue
Continuing.
Do you want to auto delete previous execution log entries when record/replay buffer becomes full (record full stop-at-limit)?([y] or n) n
Process record: stopped by user.
Program stopped.
0xf77021e6 in __linkin_atfork (newp=0xf7751748 <atfork_mem>) at ../nptl/sysdeps/unix/sysv/linux/register-atfork.c:117
117 ../nptl/sysdeps/unix/sysv/linux/register-atfork.c: No such file or directory.
(gdb) FAIL: gdb.reverse/until-precsave.exp: run to end of main (got interactive prompt)
however, I can't figure out how these functions (fprintf, printf and
malloc) are related to the test itself. marker1 is a function from
shared library too so we don't need these complicated libc functions
at all. IMO, recording the instructions in these libc functions has
nothing to do with the test itself except slow down the test. This
patch is to remove the usage of fprintf and printf, and also move
malloc to a dead code path.
gdb/testsuite:
2016-03-30 Yao Qi <yao.qi@linaro.org>
* gdb.reverse/until-precsave.exp: Match function name only.
* gdb.reverse/until-reverse.c (main): Don't call fprintf nor printf.
Move malloc to a condition block.
* gdb.reverse/until-reverse.exp: Match function name only.
Also adds s390 support to gdb.trace testsuite.
gdb/gdbserver/ChangeLog:
* linux-s390-low.c (s390_supports_tracepoints): New function.
(struct linux_target_ops): Fill supports_tracepoints hook.
gdb/testsuite/ChangeLog:
* gdb.trace/ftrace.exp: Set arg0exp for s390.
* gdb.trace/mi-trace-frame-collected.exp: Expect 4 registers on s390.
* gdb.trace/mi-trace-unavailable.exp: Set pcnum for s390, add gpr0num
variable for GPR 0 instead of assuming it is register 0.
* gdb.trace/trace-common.h: Add s390 fast tracepoint placeholder.
* lib/trace-support.exp: Add s390 registers.
Pass "debug" to prepare_for_testing otherwise, some tests fail.
gdb/testsuite:
2016-03-29 Yao Qi <yao.qi@linaro.org>
* gdb.arch/arm-neon.exp: Pass debug to prepare_for_testing.
I happen to see a quotation mark is missing the following test,
gdb_test "break $end_location" \
"Breakpoint $decimal at .* line $end_location\." \
set breakpoint at end of main"
so the test result is
PASS: gdb.reverse/break-reverse.exp: set
This patch is to add the missing quotation mark back, and the test
result becomes
PASS: gdb.reverse/break-reverse.exp: set breakpoint at end of main
gdb/testsuite:
2016-03-24 Yao Qi <yao.qi@linaro.org>
* gdb.reverse/break-reverse.exp: Add quotation mark in the
test message.
Since test artifacts are organized in a directory hierarchy, the
s390-multiarch test case is not executed correctly any more. This is
because it uses an obsolete way of constructing the output paths.
This fix invokes standard_testfile instead.
gdb/testsuite/ChangeLog:
* gdb.arch/s390-multiarch.exp: Use standard_testfile instead of
maintaining separate logic for constructing the output path.
This patch addresses "fork:Interrupted system call" (or wait:) failures
in gdb.threads/forking-threads-plus-breakpoint.exp.
The test program spawns ten threads, each of which do ten fork/waitpid
sequences. The cause of the problem was that when one of the fork
children exited before the corresponding fork parent could initiate its
waitpid for that child, a SIGCHLD and/or SIGSTOP was delivered and
interrupted a fork or waitpid in another thread.
The fix was to wrap the system calls in a loop to retry the call if
it was interrupted, like:
do
{
pid = fork ();
}
while (pid == -1 && errno == EINTR);
Since this is a Linux-only test I figure it is OK to use errno and EINTR.
I tried a number of alternative fixes using SIG_IGN, SA_RESTART,
pthread_sigblock, and bsd_signal, but none of these worked as well.
Tested on Nios II Linux target with x86 Linux host.
gdb/testsuite/ChangeLog:
2016-03-16 Don Breazeal <donb@codesourcery.com>
* gdb.threads/forking-threads-plus-breakpoint.c (thread_forks):
Retry fork and waitpid on interrupted system call errors.
* gdb.threads/forking-threads-plus-breakpoint.exp: (do_test):
Use with_timeout_factor to increase timeout to 90.
lookup_symbol is often called with user input. Consequently, any
function called from lookup_symbol{,_in_language} should attempt to
deal with malformed input gracefully. After all, malformed user
input is not a programming/API error.
This patch does not attempt to find/correct all instances of this. It
only fixes locations in the code that trigger test suite failures.
This patch fixes PR breakpoints/18303, "Assertion: -breakpoint-insert
with windows paths of file in non-current directory".
The patch includes three new tests related to this. One is just
gdb.linespec/ls-errs.exp copied and converted to use C++ instead of C, and
to add a case using a file name containing a Windows-style logical drive
specifier. The others include an MI test to provide a regression test for
the specific case reported in PR 18303, and a C++ test for proper error
handling of access to a program variable when using a file scope specifier
that refers to a non-existent file.
Tested on x86_64 native Linux.
gdb/ChangeLog
2016-01-28 Keith Seitz <keiths@redhat.com>
PR breakpoints/18303
* cp-namespace.c (cp_lookup_bare_symbol): Change assertion to
look for "::" instead of simply ":".
(cp_search_static_and_baseclasses): Return null_block_symbol for
malformed input.
Remove assertions.
* cp-support.c (cp_find_first_component_aux): Do not return
a prefix length for ':' unless the next character is also ':'.
gdb/testsuite/ChangeLog
2016-01-28 Don Breazeal <donb@codesourcery.com>
* gdb.cp/scope-err.cc: New test program.
* gdb.cp/scope-err.exp: New test script.
* gdb.linespec/ls-errs.c (myfunction): Expanded to have multiple
lines and "set breakpoint here" comment.
* gdb.linespec/ls-errs.exp: Added C++ testing and new test case.
Fixed some whitespace and format issues.
* gdb.mi/mi-linespec-err-cp.cc: New test program.
* gdb.mi/mi-linespec-err-cp.exp: New test script.
When adding the $_as_string convenience function, I missed a new test
failure in default.exp. The tests lists the convenience functions, so
$_as_string should be added to the expected list.
Fixes:
+FAIL: gdb.base/default.exp: show convenience ($_caller_is = <internal function _caller_is> not found)
gdb/testsuite/ChangeLog:
* gdb.base/default.exp: Add $_as_string to the list of expected
convenience functions.
Add a new command 'maint info line-table' to display the contents of
GDB's internal line table structure. Useful when trying to understand
problems (within gdb) relating to line tables.
gdb/ChangeLog:
* symmisc.c (maintenance_info_line_tables): New function.
(maintenance_print_one_line_table): New function.
(_initialize_symmisc): Register 'maint info line-table' command.
* NEWS: Mention new command.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Document new 'maint info line-table'
command.
gdb/testsuite/ChangeLog:
* gdb.base/maint.exp: New tests for 'maint info line-table'.
This patch is a follow-up to "Add printf format specifier for printing
enumerator":
https://sourceware.org/ml/gdb-patches/2016-02/msg00144.html
Instead of having a solution specific to the printf command, Pedro
suggested adding a general purpose function $_as_string() that would
cover this use case and more.
So, in order to print the textual label of an enum, one can use:
(gdb) printf "Visiting node of type %s\n", $_as_string(node)
Visiting node of type NODE_INTEGER
gdb/ChangeLog:
* data-directory/Makefile.in (PYTHON_FILE_LIST): Install
gdb/function/as_string.py.
* python/lib/gdb/function/as_string.py: New file.
* NEWS: Mention the new $_as_string function.
gdb/testsuite/ChangeLog:
* gdb.python/py-as-string.exp: New file.
* gdb.python/py-as-string.c: New file.
gdb/doc/ChangeLog:
* gdb.texinfo (Convenience Functions): Document $_as_string.
These tests should have been adjusted by f303dbd60d (Fix PR
threads/19422 - show which thread caused stop), but clearly I had
missed grepping for potential-fail cases.
gdb/testsuite/ChangeLog
2016-03-09 Pedro Alves <palves@redhat.com>
* gdb.threads/attach-into-signal.exp: Adjust to "Program received
signal" -> "Thread NN received signal" output change.
* gdb.threads/ia64-sigill.exp: Likewise.
* gdb.threads/linux-dp.exp: Likewise.
* gdb.threads/manythreads.exp: Likewise.
* gdb.threads/pending-step.exp: Likewise.
* gdb.threads/print-threads.exp: Likewise.
* gdb.threads/sigstep-threads.exp: Likewise.
* gdb.threads/staticthreads.exp: Likewise.
* gdb.threads/tls.exp: Likewise.
I happened to break this locally and the testsuite didn't notice it.
Add some tests.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* gdb.base/command-line-input.exp: New file.
gdb/gdbserver/ChangeLog:
* linux-ppc-low.c (ppc_supports_tracepoints): New function.
(struct linux_target_ops): Wire in the above.
gdb/testsuite/ChangeLog:
* gdb.trace/ftrace.exp: Set arg0exp for ppc.
* gdb.trace/mi-trace-unavailable.exp: Set pcnum for ppc.
* gdb.trace/pending.exp: Accept leading dot before function name.
* gdb.trace/trace-common.h: Add fast tracepoint dummy insn for ppc.
* lib/trace-support.exp: Set registers for ppc.
On powerpc64, "disassemble foo" doesn't work properly on object files
(it can't process the relocations in .opd section) - instead, let's
link it into an executable and load that.
Also, backtrace displays .main, not main. Accept both.
gdb/testsuite/ChangeLog:
* gdb.trace/entry-values.exp: Link ${binfile}1.o to ${binfile}1 and
use it for disassembly; accept .main in addition to main in backtrace.
tfind.exp sets a breakpoint on *gdb_recursion_test, which is the global
entry point on ppc64le, and won't be hit, since the call uses
the local entry. Fix by calling the function via a pointer in a global
variable, forcing use of the global entry.
This patch is a slightly modified hunk extracted from
https://sourceware.org/ml/gdb-patches/2015-07/msg00353.html
gdb/testsuite/ChangeLog:
2016-03-09 Wei-cheng Wang <cole945@gmail.com>
Marcin Kościelnicki <koriakin@0x04.net>
* gdb.trace/actions.c (gdb_recursion_test_fp): New typedef.
(gdb_recursion_test_ptr): New global variable.
(gdb_recursion_test): Call gdb_recursion_test_ptr instead of
gdb_recursion_test.
(gdb_c_test): Ditto.
powerpc (32-bit) loads shared libraries below the main executable, so
the PENDING location is the first one, which the current regex doesn't
match. Split it into two tests instead, one looking for the pending
tracepoint location, and the other for two installed locations.
gdb/testsuite/ChangeLog:
* gdb.trace/change-loc.exp: Don't depend on tracepoint location
ordering.
On powerpc64, foo/bar point to a function descriptor, not to function code.
Since there are no global labels pointing at the actual function code,
let's make our own.
Regression-tested on x86_64.
gdb/testsuite/ChangeLog:
* gdb.trace/unavailable-dwarf-piece.c (foo): Add foo_start_lbl label.
(bar): Add bar_start_lbl label.
* gdb.trace/unavailable-dwarf-piece.exp: Use foo/bar_start_lbl instead
of foo/bar for emitting DWARF and tracing.
I forgot to do it in my previous commit. This is necessary because we
execute the script directly on gdb/testsuite/Makefile.in.
gdb/testsuite/ChangeLog:
2016-03-06 Sergio Durigan Junior <sergiodj@redhat.com>
* analyze-racy-logs.py: Set executable bit.
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.
This patch adds a new test for stepping over clone syscall.
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/step-over-syscall.exp (step_over_syscall): Kfail.
Invoke step_over_syscall "clone" and break_cond_on_syscall
"clone".
* gdb.base/step-over-clone.c: New file.
disp-step-syscall.exp is extended for stepping over syscall instruction
in different cases, with or without displaced stepping, and stepping
over by GDBserver.
This patch rename disp-step-syscall.exp to step-over-syscall.exp to
reflect this.
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-fork.c: Rename to ...
* gdb.base/step-over-fork.c: ... it. New file.
* gdb.base/disp-step-vfork.c: Rename to ...
* gdb.base/step-over-vfork.c: ... it. New file.
* gdb.base/disp-step-syscall.exp: Rename to ...
* gdb.base/step-over-syscall.exp: ... it. New file.
(disp_step_cross_syscall): Rename to ...
(step_over_syscall): ... it.
We can also extend disp-step-syscall.exp to test GDBserver step over
breakpoint on syscall instruction. That is, we set a breakpoint
with a false condition on syscall instruction, so that GDBserver will
step over it.
This test triggers a GDBserver internal error, which can be fixed by
this series.
(gdb) PASS: gdb.base/disp-step-syscall.exp: fork: break cond on target: break on syscall insns
continue^M
Continuing.^M
Remote connection closed^M
(gdb) FAIL: gdb.base/disp-step-syscall.exp: fork: break cond on target: continue to fork again
In GDBserver, there is an internal error,
/home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/linux-low.c:1922: A problem internal to GDBserver has been detected.
unsuspend LWP 25554, suspended=-1
the simplified reproducer is like,
$ ./gdb ./testsuite/outputs/gdb.base/disp-step-syscall/disp-step-fork
(gdb) b main
(gdb) c
(gdb) disassemble fork // in order to find the address of insn 'syscall'
....
0x00007ffff7ad6023 <+179>: syscall
(gdb) b *0x00007ffff7ad6023 if main == 0
(gdb) c
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-syscall.exp (break_cond_on_syscall): New.
If target supports condition evaluation on target, invoke
break_cond_on_syscall for fork and vfork.
disp-step-syscall.exp was added to test displaced stepping over syscall
instructions, in which we set breakpoint on syscall instruction, and
step over it. In fact, we can extend the test to non-displaced-stepping
case. This patch wraps the test with displaced stepping on and off.
Note that the indentation and format isn't adjusted here to make this
patch easy to read. The following patch will fix the format separately.
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-syscall.exp: Don't invoke
support_displaced_stepping.
(disp_step_cross_syscall): Test with displaced stepping off and
on if supported.
This patch moves some code out of disp_step_cross_syscall to a new proc
check_pc_after_cross_syscall and setup. Procedure setup is to start a
fresh GDB and compute the syscall instruction address.
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-syscall.exp (check_pc_after_cross_syscall): New
proc.
(setup): New proc.
(disp_step_cross_syscall): Move code to check_pc_after_cross_syscall
and setup.
Printing and resolving of dynamic array's causes sporadic timeout issues on loaded systems.
2016-03-02 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/testsuite/Changelog:
* gdb.fortran/vla-history.exp: Lookup array elements and printing exceeds timeout.
Adding a dummy assignment as a new breakpoint anchor because
breakpoint on return statement doesn't work for GCC 5.x.
2016-03-02 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/testsuite/Changelog:
* gdb.cp/vla-cxx.cc: Insert dummy assignment as anchor for an breakpoint.
Nullify pointers to avoid an undefined association status.
2016-03-02 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/testsuite/Changelog:
* gdb.mi/vla.f90: Nullify pointer after declaration.
Fixes, on F23:
.../src/gdb/testsuite/gdb.trace/ftrace-lock.c: In function 'gdb_agent_gdb_collect':
.../src/gdb/testsuite/gdb.trace/ftrace-lock.c:50:3: warning: implicit declaration of function 'sleep' [-Wimplicit-function-declaration]
sleep (1);
^
gdb/testsuite/ChangeLog:
2016-03-01 Pedro Alves <palves@redhat.com>
* gdb.trace/ftrace-lock.c: Include <unistd.h>.
This testcase currently fails to compile on Fedora 23:
.../src/gdb/testsuite/gdb.threads/watchpoint-fork-mt.c: In function 'start':
.../src/gdb/testsuite/gdb.threads/watchpoint-fork-mt.c:70:11: warning: implicit declaration of function 'pthread_yield' [-Wimplicit-function-declaration]
i = pthread_yield ();
^
.../src/gdb/testsuite/gdb.threads/watchpoint-fork-child.c: In function 'forkoff':
.../src/gdb/testsuite/gdb.threads/watchpoint-fork-child.c:114:8: warning: implicit declaration of function 'pthread_yield' [-Wimplicit-function-declaratio
n]
i = pthread_yield ();
^
/tmp/ccUkNIsI.o: In function `start':
.../src/gdb/testsuite/gdb.threads/watchpoint-fork-mt.c:70: undefined reference to `pthread_yield'
(...)
collect2: error: ld returned 1 exit status
UNSUPPORTED: gdb.threads/watchpoint-fork.exp: child: multithreaded: Couldn't compile watchpoint-fork-child.c: unrecognized error
UNTESTED: gdb.threads/watchpoint-fork.exp: child: multithreaded: watchpoint-fork.exp
testcase .../src/gdb/testsuite/gdb.threads/watchpoint-fork.exp completed i
The glibc manual says, on _GNU_SOURCE:
"You should define these macros by using ‘#define’ preprocessor
directives at the top of your source code files. These directives must
come before any #include of a system header file."
I instead put it in the header all the .c files of the testcase must
include anyway.
gdb/testsuite/ChangeLog:
2016-03-01 Pedro Alves <palves@redhat.com>
* gdb.threads/watchpoint-fork-child.c: Include "watchpoint-fork.h"
before anything else.
* gdb.threads/watchpoint-fork-mt.c: Likewise. Don't define
_GNU_SOURCE here.
* gdb.threads/watchpoint-fork-st.c: Include "watchpoint-fork.h"
before anything else.
* gdb.threads/watchpoint-fork.h: Define _GNU_SOURCE.
This patch fixes the following error,
ERROR: (/scratch/yao/gdb/build-git/arm-linux-gnueabihf/gdb/testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step) No such file or directory
FAIL: gdb.arch/arm-disp-step.exp: Can't run to main
gdb/testsuite:
2016-03-01 Yao Qi <yao.qi@linaro.org>
* gdb.arch/arm-disp-step.exp: Use standard_testfile and
prepare_for_testing.
When we compile gdb.arch/arm-neon.c with options that don't enable NEON,
there are many error/warnings emitted into gdb.sum, which is annoying.
This patch fixes it by passing quiet to prepare_for_testing.
gdb/testsuite:
2016-03-01 Yao Qi <yao.qi@linaro.org>
* gdb.arch/arm-neon.exp: Pass quiet to prepare_for_testing.
Since test artifacts are always organized in a directory hierarchy, the
s390-tdbregs test case is not executed correctly any more. This is
because it uses an obsolete way of constructing the executable's path.
This change invokes prepare_for_testing instead.
gdb/testsuite/ChangeLog:
* gdb.arch/s390-tdbregs.exp: Use prepare_for_testing instead of
manually constructing the output path.
This fixes a GDB internal error that may occur when the inferior has no
valid stack pointer in r15.
gdb/testsuite/ChangeLog:
* gdb.arch/s390-stackless.S: New.
* gdb.arch/s390-stackless.exp: New.
gdb/ChangeLog:
* s390-linux-tdep.c (s390_backchain_frame_unwind_cache): Avoid
exception when attempting to access the inferior's backchain.
Given two or more modules that import each other's scope, the current symbol
lookup routines would go round in circles looking through each import from
each module, possibly checking the same module twice or more until all possible
paths are marked as "searched".
Given enough modules, this causes an exponential slowdown in time taken to find
symbols that do exist, and infinite recursion when they don't.
gdb/ChangeLog:
* d-namespace.c (d_lookup_symbol_imports): Avoid recursive lookups from
cyclic imports.
gdb/testsuite/ChangeLog:
* gdb.dlang/circular.c: New file.
* gdb.dlang/circular.exp: New file.
