aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.trace
AgeCommit message (Collapse)AuthorFilesLines
2016-04-28Add test for tracepoint enable/disableSimon Marchi2-0/+166
This patch adds a test for tracepoints enabling/disabling, which didn't work properly for fast tracepoints on big endian systems. gdb/testsuite/ChangeLog: * gdb.trace/trace-enable-disable.exp: New file. * gdb.trace/trace-enable-disable.c: New file.
2016-04-28ftrace tests: Use gdb_load_shlib result to lookup IPA in info sharedlibrarySimon Marchi6-12/+12
Some fast tracepoints tests make sure that the in-process agent library is properly loaded, by searching for the library name in "info sharedlibrary". Originally, it would search for the full path. Since patch "Make ftrace tests work with remote targets" [1], the "runtime" location of the IPA, in the standard output directory, is not the same as the original location, in the gdbserver build directory. Therefore, the patch changed the checks: gdb_test "info sharedlibrary" ".*${libipa}.*" "IPA loaded" to gdb_test "info sharedlibrary" ".*[file tail ${libipa}].*" "IPA loaded" so that only the "libinproctrace.so" part would be searched for. Antoine (in CC) pointed out that I missed some, so I have to update them. In the mean time, I noticed that I missed a few test failures: adding the SONAME to the IPA makes it possible for the test executable to erroneously pick up libinproctrace.so from /usr/lib if the test harness failed to put the libinproctrace.so we want to test in the right place. To mitigate that kind of error in the future, we can use the return value of gdb_load_shlib (the path of the "runtime" version of the library) and use that to search in the output of info sharedlibrary. When testing locally, gdb_load_shlib returns the full normalized path of the destination library, which the test executable should use e.g.: /path/to/gdb/testsuite/outputs/gdb.trace/thetest/libinproctrace.so My testing showed that it was the same path that gdb displayed in info sharedlibrary. If the test executable picks up another libinproctrace.so, the test will fail. When testing remotely, gdb_load_shlib/gdb_remote_download only returns us "libinproctrace.so", so the situation doesn't really change. If there is a rogue libinproctrace.so in /usr/lib on the target and we fail to download ours, it might cover up a test failure. But that situation is probably still better than the original one, where it wasn't possible to test remotely using the IPA at all. [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=6e774b13c3b81ac2599812adf058796948ce7e95 gdb/testsuite/ChangeLog: * gdb.arch/ftrace-insn-reloc.exp: Save gdb_load_shlib result, use it in info sharedlibrary test. * gdb.trace/ftrace-lock.exp: Likewise. * gdb.trace/ftrace.exp: Likewise. * gdb.trace/range-stepping.exp: Likewise. * gdb.trace/trace-break.exp: Likewise. * gdb.trace/trace-condition.exp: Likewise. * gdb.trace/trace-mt.exp: Likewise.
2016-04-27Rename gdb_load_shlibs to gdb_load_shlibSimon Marchi10-22/+22
Rename gdb_load_shlibs to gdb_load_shlib to reflect that it can only load a single shlib at the time. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_load_shlibs): Rename to... (gdb_load_shlib): ... this. * gdb.arch/ftrace-insn-reloc.exp: Adjust gdb_load_shlibs -> gdb_load_shlib. * gdb.base/catch-load.exp (one_catch_load_test): Likewise. * gdb.base/ctxobj.exp: Likewise. * gdb.base/dprintf-pending.exp: Likewise. * gdb.base/dso2dso.exp: Likewise. * gdb.base/fixsection.exp: Likewise. * gdb.base/gcore-relro.exp: Likewise. * gdb.base/gdb1555.exp: Likewise. * gdb.base/global-var-nested-by-dso.exp: Likewise. * gdb.base/gnu-ifunc.exp: Likewise. * gdb.base/hbreak-in-shr-unsupported.exp: Likewise. * gdb.base/jit-so.exp (one_jit_test): Likewise. * gdb.base/pending.exp: Likewise. * gdb.base/print-file-var.exp: Likewise. * gdb.base/print-symbol-loading.exp: Likewise. * gdb.base/shlib-call.exp: Likewise. * gdb.base/shreloc.exp: Likewise. * gdb.base/so-impl-ld.exp: Likewise. * gdb.base/solib-disc.exp: Likewise. * gdb.base/solib-nodir.exp: Likewise. * gdb.base/solib-overlap.exp: Likewise. * gdb.base/solib-symbol.exp: Likewise. * gdb.base/solib-weak.exp (do_test): Likewise. * gdb.base/sym-file.exp: Likewise. * gdb.base/symtab-search-order.exp: Likewise. * gdb.base/type-opaque.exp: Likewise. * gdb.base/unload.exp: Likewise. * gdb.base/watchpoint-solib.exp: Likewise. * gdb.compile/compile.exp: Likewise. * gdb.cp/gdb2384.exp: Likewise. * gdb.cp/infcall-dlopen.exp: Likewise. * gdb.cp/re-set-overloaded.exp: Likewise. * gdb.fortran/library-module.exp: Likewise. * gdb.opt/solib-intra-step.exp: Likewise. * gdb.python/py-finish-breakpoint.exp: Likewise. * gdb.python/py-shared.exp: Likewise. * gdb.reverse/solib-precsave.exp: Likewise. * gdb.reverse/solib-reverse.exp: Likewise. * gdb.server/solib-list.exp: Likewise. * gdb.threads/dlopen-libpthread.exp: Likewise. * gdb.threads/tls-shared.exp: Likewise. * gdb.threads/tls-so_extern.exp: Likewise. * gdb.trace/change-loc.exp: Likewise. * gdb.trace/ftrace-lock.exp: Likewise. * gdb.trace/ftrace.exp: Likewise. * gdb.trace/mi-tracepoint-changed.exp (test_reconnect): Likewise. * gdb.trace/pending.exp: Likewise. * gdb.trace/range-stepping.exp: Likewise. * gdb.trace/strace.exp (strace_remove_socket): Likewise. (strace_info_marker): Likewise. (strace_probe_marker): Likewise. (strace_trace_on_same_addr): Likewise. (strace_trace_on_diff_addr): Likewise. * gdb.trace/trace-break.exp: Likewise. * gdb.trace/trace-condition.exp: Likewise. * gdb.trace/trace-mt.exp: Likewise.
2016-04-22Fix fails in gdb.trace/unavailable.expYao Qi1-2/+2
I am seeing some test fails in gdb.trace/unavailable.exp on aarch64-linux, like this, print derived_whole^M $43 = (Derived) {<Middle> = {<Base> = {x = 2}, _vptr.Middle = 0x401860 <VTT for Derived>, y = 3}, _vptr.Derived = 0x401848 <vtable for Derived+32>, z = 4}^M (gdb) FAIL: gdb.trace/unavailable.exp: collect globals: print object on: print derived_whole print derived_whole^M $47 = {<Middle> = {<Base> = {x = 2}, _vptr.Middle = 0x401860 <VTT for Derived>, y = 3}, _vptr.Derived = 0x401848 <vtable for Derived+32>, z = 4}^M (gdb) FAIL: gdb.trace/unavailable.exp: collect globals: print object off: print derived_whole these fails are also found by recent x86_64-linux buildbot, https://sourceware.org/ml/gdb-testers/2016-q2/msg00622.html The fix is exactly the same as this one http://www.sourceware.org/ml/gdb-patches/2015-10/msg00252.html (the extra "VTT" after hex), in which we match extra things after $hex. gdb/testsuite: 2016-04-22 Yao Qi <yao.qi@linaro.org> * gdb.trace/unavailable.exp (gdb_collect_globals_test_1): Match more after $hex.
2016-04-22Deliver signal in hardware single stepYao Qi1-2/+10
GDBserver doesn't deliver signal when stepping over a breakpoint even hardware single step is used. When GDBserver started to step over (thread creation) breakpoint for mutlit-threaded debugging in 2002 [1], GDBserver behaves this way. This behavior gets trouble on conditional breakpoints on branch to self instruction like this, 0x00000000004005b6 <+29>: jmp 0x4005b6 <main+29> and I set breakpoint $(gdb) break branch-to-self.c:43 if counter > 3 and the variable counter will be set to 5 in SIGALRM signal handler. Since GDBserver keeps stepping over breakpoint, the SIGALRM can never be dequeued and delivered to the inferior, so the program can't stop. The test can be found in gdb.base/branch-to-self.exp. GDBserver didn't deliver signal when stepping over a breakpoint because a tracepoint is collected twice if GDBserver does so in the following scenario, which can be reproduced by gdb.trace/signal.exp. - program stops at tracepoint, and tracepoint is collected, - gdbserver starts a step-over, - a signal arrives, step-over is canceled, and signal should be passed, - gdbserver starts a new step-over again, pass the signal as well, - program stops at the entry of signal handler, step-over finished, - gdbserver proceeds, - program returns from the signal handler, again to the tracepoint, and thus is collected again. The spurious collection isn't that harmful, IMO, so it should be OK to let GDBserver deliver signal when stepping over a breakpoint. gdb/gdbserver: 2016-04-22 Yao Qi <yao.qi@linaro.org> * linux-low.c (lwp_signal_can_be_delivered): Don't deliver signal when stepping over breakpoint with software single step. gdb/testsuite: 2016-04-22 Yao Qi <yao.qi@linaro.org> * gdb.trace/signal.exp: Also pass if $tracepoint_hits($i) > $iterations.
2016-04-22New test case gdb.trace/signal.expYao Qi2-0/+247
This is to test whether GDBserver deliver signal to the inferior while doing the step over. Nowadays, GDBserver doesn't deliver signal, so there won't be spurious collection, however, if GDBserver does deliver signal, there might be spurious collection. gdb/testsuite: 2016-04-22 Yao Qi <yao.qi@linaro.org> * gdb.trace/signal.c: New file. * gdb.trace/signal.exp: New file.
2016-04-13Fix aarch64 ftrace JIT condition testcaseAntoine Tremblay1-1/+1
This patch fixes the following failure: FAIL: gdb.trace/trace-condition.exp: ftrace: -(21 << 1) == -42: check 10 frames were collected. This was due to aarch64_emit_sub using the wrong order in its operands, so the operation would end up being 42 - 0 rather than 0 - 42. This patch also fixes the order of aarch64_emit_add for clarity. The test case for emit_sub is fixed so that the proper order of the operands is needed for the test to pass. Tested on aarch64-native-extended-gdbserver. Note: trace-condition.exp was broken a bit so I had to modify it to run the test. A fix is coming for that in another patch. gdb/gdbserver/ChangeLog: * linux-aarch64-low.c (aarch64_emit_add): Switch x1 and x0. (aarch64_emit_sub): Likewise. gdb/testsuite/ChangeLog: * gdb.trace/trace-condition.exp (foreach): Fix emit_sub testcase.
2016-04-12Fix typo in ftrace.exp condition testingAntoine Tremblay1-1/+1
This obvious patch replaces "ond" wiht "cond" as the test prefix for conditional tests. gdb/testsuite/ChangeLog: * gdb.trace/ftrace.exp (proc): Change test prefix from "ond" to "cond".
2016-04-05Make ftrace tests work with remote targetsSimon Marchi2-2/+2
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.
2016-03-29gdbserver/s390: Switch on tracepoint support.Marcin Kościelnicki4-6/+41
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.
2016-03-09gdb: Add tracepoint support for powerpc.Marcin Kościelnicki4-2/+7
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.
2016-03-09gdb.trace/entry-values.exp: Fixes for powerpc64.Marcin Kościelnicki1-4/+9
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.
2016-03-09gdb.trace/tfind.exp: Force call via global entry point on ppc64le.Marcin Kościelnicki1-2/+7
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.
2016-03-09gdb.trace/change-loc.exp: Don't depend on tracepoint ordering.Marcin Kościelnicki1-4/+16
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.
2016-03-09gdb.trace: Use manually-defined start labels in unavailable-dwarf-piece.expMarcin Kościelnicki2-4/+6
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.
2016-03-01Fix gdb.trace/ftrace-lock.c compilationPedro Alves1-0/+1
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>.
2016-02-25[PR gdb/13808] gdb.trace: Pass tdesc selected in gdbserver to IPA.Marcin Kościelnicki1-1/+0
If gdbserver and IPA are using different tdesc, they will disagree about 'R' trace packet size. This results in mangled traces. To make sure they pick the same tdesc, gdbserver pokes the tdesc (specified as an index in a target-specific list) into a global variable in IPA. In theory, IPA could find out the tdesc on its own, but that may be complex (in particular, I don't know how to tell whether we have LAST_BREAK on s390 without messing with ptrace), and we'd have to duplicate the logic. Tested on i386 and x86_64. On i386, it fixes two FAILs in ftrace.exp. On x86_64, these failures have been KFAILed - one of them works now, but the other now fails due to an unrelated reason (ugh). gdb/gdbserver/ChangeLog: PR gdb/13808 * Makefile.in: Add i386-*-linux-ipa.o and amd64-*-linux-ipa.o. * configure.srv: Ditto. * linux-aarch64-ipa.c (get_ipa_tdesc): New function. (initialize_low_tracepoint): Remove ipa_tdesc assignment. * linux-amd64-ipa.c: Add "linux-x86-tdesc.h" include. (init_registers_amd64_linux): Remove prototype. (tdesc_amd64_linux): Remove declaration. (get_ipa_tdesc): New function. (initialize_low_tracepoint): Remove ipa_tdesc assignment, initialize remaining tdescs. * linux-i386-ipa.c: Add "linux-x86-tdesc.h" include. (init_registers_i386_linux): Remove prototype. (tdesc_i386_linux): Remove declaration. (get_ipa_tdesc): New function. (initialize_low_tracepoint): Remove ipa_tdesc assignment, initialize remaining tdescs. * linux-low.c (linux_get_ipa_tdesc_idx): New function. (linux_target_ops): wire in linux_get_ipa_tdesc_idx. * linux-low.h (struct linux_target_ops): Add get_ipa_tdesc_idx. * linux-x86-low.c: Move tdesc declarations to linux-x86-tdesc.h. (x86_get_ipa_tdesc_idx): New function. (the_low_target): Wire in x86_get_ipa_tdesc_idx. * linux-x86-tdesc.h: New file. * target.h (struct target_ops): Add get_ipa_tdesc_idx. (target_get_ipa_tdesc_idx): New macro. * tracepoint.c (ipa_tdesc_idx): New macro. (struct ipa_sym_addresses): Add addr_ipa_tdesc_idx. (symbol_list): Add ipa_tdesc_idx. (cmd_qtstart): Write ipa_tdesc_idx in the target. (ipa_tdesc): Remove. (ipa_tdesc_idx): New variable. (get_context_regcache): Use get_ipa_tdesc. (gdb_collect): Ditto. (gdb_probe): Ditto. * tracepoint.h (get_ipa_tdesc): New prototype. (ipa_tdesc): Remove. gdb/testsuite/ChangeLog: PR gdb/13808 * gdb.trace/ftrace.exp (test_fast_tracepoints): Remove kfail.
2016-02-25gdb.trace: Remove unnecessary target check from ftrace.exp.Marcin Kościelnicki1-69/+66
The check used hardcoded targets and wasn't doing anything useful anyway, since unsupported architectures blow up on link due to missing the IPA library before they ever get to that check. gdb/testsuite/ChangeLog: * gdb.trace/ftrace.exp: Remove unnecessary target check.
2016-02-25gdb.trace: Surround $call_insn with \y in entry-values.expMarcin Kościelnicki1-1/+3
The PPC64 tracepoint patch added \y at the end of the call_insn pattern - without that, it embarassed itself and matched the 'bl' in "Dump of assem*bl*er code for function" as the powerpc call opcode. Since that sounds like a generally good idea, I've added \y before and after call_insn for every target. As a result, I had to change x86_64's mnemonic to 'callq'. gdb/testsuite/ChangeLog: * gdb.trace/entry-values.exp: Surround $call_insn with '\y', change x86_64 call_insn to 'callq'.
2016-02-24Move tfile-avx.exp to tracefile-pseudo-reg.expAntoine Tremblay2-0/+0
As it is planned to add more architectures to this test, rename to a more generic name. gdb/testsuite/ChangeLog: * gdb.trace/tfile-avx.c: Move to... * gdb.trace/tracefile-pseudo-reg.c: Here. * gdb.trace/tfile-avx.exp: Move to... * gdb.trace/tracefile-pseudo-reg.exp: Here.
2016-02-22gdb.trace: Fix unavailable.exp if last register happens to be PC.Marcin Kościelnicki1-1/+1
unavailable.exp executes "info registers", expecting to find at least two instances of "<unavailable>". However, it uses "<unavailable>.*<unavailable>" as the pattern, which doesn't match when the last register happens to be available (eg. PC). Change it to ".*<unavailable>.*<unavailable>.*" instead. Noticed on s390, no regression on x86_64. gdb/testsuite/ChangeLog: * gdb.trace/unavailable.exp (gdb_unavailable_registers_test_1): Fix info registers pattern.
2016-02-18Determine the iteration count based on wallclock instead of user+system time.Wei-cheng Wang1-10/+6
gdb/testsuite/ChangeLog: 2016-02-18 Wei-cheng Wang <cole945@gmail.com> * gdb.trace/tspeed.c (myclock): Return wallclock instead of user+system time. (trace_speed_test): Determine the iteration count for a time between 15..30 seconds.
2016-02-16testsuite: Fix save-trace.exp writing outside standard output directorySimon Marchi1-1/+12
In save-trace.exp, we want to test loading of a tracepoint definition file with a relative path (I am not sure why in fact). We currently use "savetrace-relative.tr", which ends up directly in testsuite/. If we use [standard_output_file] on that path, it becomes absolute. I decided to just replace [pwd] with . (a dot) in the path given by standard_output_file to make it relative. However, this trick only works because [pwd] is a prefix of the standard output directory. So I added a check to verify that precondition. gdb/testsuite/ChangeLog: * gdb.trace/save-trace.exp: Change relative path to be in the standard output directory.
2016-02-12gdb.trace/tfile-avx.c: Change ymm15 to xmm15 for old gcc.Marcin Kościelnicki1-1/+3
gcc older than 4.9 doesn't understand ymm15 as a register name. Use xmm15 instead. gdb/testsuite/ChangeLog: * gdb.trace/tfile-avx.c (main): Change ymm15 to xmm15.
2016-02-11gdb.trace: Add a testcase for tdesc in tfile.Marcin Kościelnicki2-0/+124
This tests whether $ymm15 can be correctly collected and printed from tfile. It covers: - storing tdesc in tfile (without that, $ymm15 doesn't exist) - ax_pseudo_register_collect for x86 (without that, $ymm15 cannot be collected) - register order in tfile_fetch_registers (without that, $ymm15h is fetched from wrong position) - off-by-one in tfile_fetch_registers (without that, $ymm15h is incorrectly considered to be out of bounds) - using proper tdesc in encoding tracepoint actions (without that, internal error happens due to $ymm15h being considered unavailable) gdb/testsuite/ChangeLog: * gdb.trace/tfile-avx.c: New test. * gdb.trace/tfile-avx.exp: New test.
2016-02-08Always organize test artifacts in a directory hierarchySimon Marchi1-19/+0
When running tests in parallel, each test puts its generated files in a different directory, under "outputs". I think it would be nice if it was always the case, as it would isolate the test cases a bit more. An artifact created by a test wouldn't get overwritten by another test. Also, it makes it easier to clean up. A lot of executables are left all over the place because their names do not appear in gdb.*/Makefile. If everything is in "outputs", then we just have to delete that directory (which we already do). At the same time it makes the gdb.foo directories and their Makefiles useless in the build directory, since they are pretty much only used for cleaning. What do you think? gdb/testsuite/ChangeLog: * Makefile.in (ALL_SUBDIRS): Remove. (clean mostlyclean): Do not recurse in ALL_SUBDIRS. (distclean maintainer-clean realclean): Likewise. * configure.ac (AC_OUTPUT): Remove gdb.*/Makefile. * configure: Regenerate. * gdb.ada/Makefile.in: Delete. * gdb.arch/Makefile.in: Likewise. * gdb.asm/Makefile.in: Likewise. * gdb.base/Makefile.in: Likewise. * gdb.btrace/Makefile.in: Likewise. * gdb.cell/Makefile.in: Likewise. * gdb.compile/Makefile.in: Likewise. * gdb.cp/Makefile.in: Likewise. * gdb.disasm/Makefile.in: Likewise. * gdb.dlang/Makefile.in: Likewise. * gdb.dwarf2/Makefile.in: Likewise. * gdb.fortran/Makefile.in: Likewise. * gdb.gdb/Makefile.in: Likewise. * gdb.go/Makefile.in: Likewise. * gdb.guile/Makefile.in: Likewise. * gdb.java/Makefile.in: Likewise. * gdb.linespec/Makefile.in: Likewise. * gdb.mi/Makefile.in: Likewise. * gdb.modula2/Makefile.in: Likewise. * gdb.multi/Makefile.in: Likewise. * gdb.objc/Makefile.in: Likewise. * gdb.opencl/Makefile.in: Likewise. * gdb.opt/Makefile.in: Likewise. * gdb.pascal/Makefile.in: Likewise. * gdb.perf/Makefile.in: Likewise. * gdb.python/Makefile.in: Likewise. * gdb.reverse/Makefile.in: Likewise. * gdb.server/Makefile.in: Likewise. * gdb.stabs/Makefile.in: Likewise. * gdb.threads/Makefile.in: Likewise. * gdb.trace/Makefile.in: Likewise. * gdb.xml/Makefile.in: Likewise. * lib/gdb.exp (make_gdb_parallel_path): Add check for GDB_PARALLEL. (standard_output_file): Remove check for GDB_PARALLEL, always return path in outputs/$subdir/$testname.
2016-01-25gdb.trace/testsuite: Bump stack collection fudge factor.Marcin Kościelnicki2-2/+2
These two tests collect 64 words from $sp onwards, hoping that's enough to capture a few whole stack frames. Unfortunately, that's not enough for s390, which tends to have large frame sizes - minimum 24 words on s390, 20 on s390x (which just barely passes). Bump it to 128 words, let's hope no machine needs more. Tested on x86_64, s390, s390x. gdb/testsuite/ChangeLog: * gdb.trace/backtrace.exp: Bump stack collection fudge factor. * gdb.trace/entry-values.exp: Bump stack collection fudge factor.
2016-01-23gdb.trace: Fix unavailable-dwarf-piece.exp on big endian targetsMarcin Kościelnicki1-3/+17
The test constructs fake DWARF info for a C structure involving bitfields. DWARF bitfields are always counted from LSB, while the order in which bitfields are allocated in a C struct depends on the target endianness - thus the generated DWARF marks different bitfields as unavailable when target is big endian. Accordingly, we need different expected outputs. Tested on s390 and s390x, no regression on x86_64. gdb/testsuite/ChangeLog: * gdb.trace/unavailable-dwarf-piece.exp: Fix bitfield handling on big endian targets.
2016-01-23gdb.trace: Fix another expected message on continue.Marcin Kościelnicki1-1/+1
Missed one message in bd0a71fa16f668341a9361c695bc3ca44d27b322, since it didn't trigger on s390x or amd64 (fast tracepoint out of range due to shared library usage), noticed on s390. Pushed as obvious. gdb/testsuite/ChangeLog: * gdb.trace/pending.exp: Fix expected message on continue.
2016-01-20Fix missing IPA lib in tspeed.exp in some configurations.Antoine Tremblay1-1/+1
On Ubuntu 14.04 the following failure would be seen when running the tspeed.exp test on a target that supports fast tracepoints like x86_64: Target returns error code '.In-process agent library not loaded in process. Fast and static tracepoints unavailable.'. (gdb) FAIL: gdb.trace/tspeed.exp: start trace experiment This is because the default is to link with --as-needed and the gdb_compile for the test is using the libs argument instead of shlib which corrects this issue since 6ebea266fd0a7a56c90db3ab6237ff9f6c919747 by adding -Wl,--no-as-needed. This patch fixes the issue by passing the lib as the shlib argument to gdb_compile. Tested on Ubuntu 14.04 x86_64. gdb/testsuite/ChangeLog: * gdb.trace/tspeed.exp: Use shlib instead of libs in gdb_compile command.
2016-01-19testsuite/gdb.trace: Fix expected message on continue.Marcin Kościelnicki3-22/+35
This is fallout from f303dbd60d9c7984832446eeb9d4e4d89703c615. The testcases themselves are single-threaded, but they load the IPA library, which injects a thread in the inferior - making them multithreaded. This results in printing the thread numbers in breakpoint messages. gdb/testsuite/ChangeLog: * gdb.trace/ftrace.exp: Fix expected message on continue. * gdb.trace/pending.exp: Fix expected message on continue. * gdb.trace/trace-break.exp: Fix expected message on continue.
2016-01-01GDB copyright headers update after running GDB's copyright.py script.Joel Brobecker78-78/+78
gdb/ChangeLog: Update year range in copyright notice of all files.
2015-12-15Tweak gdb.trace/ftrace.exp for aarch64Yao Qi1-0/+2
Some tests are skipped on aarch64 unexpectedly because arg0exp isn't set. This patch is to set arg0exp to "$x0" for aarch64. gdb/testsuite: 2015-12-15 Yao Qi <yao.qi@linaro.org> * gdb.trace/ftrace.exp: Set arg0exp to "$x0" if target is aarch64*-*-*.
2015-12-14Target remote mode fork and exec test updatesDon Breazeal1-1/+1
This patch updates tests for fork and exec events in target remote mode. In the majority of cases this was a simple matter of removing some code that disabled the test for target remote. In a few cases the test needed to be disabled; in those cases the gdb_protocol was checked instead of using the [is_remote target] etc. In a couple of cases we needed to use clean_restart, since target remote doesn't support the run command, and in one case we had to modify an expect expression to allow for a "multiprocess-style" ptid. Tested with the patch that implemented target remote mode fork and exec event support. gdb/testsuite/ChangeLog: * gdb.base/execl-update-breakpoints.exp (main): Enable for target remote. * gdb.base/foll-exec-mode.exp (main): Disable for target remote. * gdb.base/foll-exec.exp (main): Enable for target remote. * gdb.base/foll-fork.exp (main): Likewise. * gdb.base/foll-vfork.exp (main): Likewise. * gdb.base/multi-forks.exp (main): Likewise, and use clean_restart. (proc continue_to_exit_bp_loc): Use clean_restart. * gdb.base/pie-execl.exp (main): Disable for target remote. * gdb.base/watch-vfork.exp (main): Enable for target remote. * gdb.mi/mi-nsthrexec.exp (main): Likewise. * gdb.threads/execl.exp (main): Likewise. * gdb.threads/fork-child-threads.exp (main): Likewise. * gdb.threads/fork-plus-threads.exp (main): Disable for target remote. * gdb.threads/fork-thread-pending.exp (main): Enable for target remote. * gdb.threads/linux-dp.exp (check_philosopher_stack): Allow pid.tid style ptids, instead of just tid. * gdb.threads/thread-execl.exp (main): Enable for target remote. * gdb.threads/watchpoint-fork.exp (main): Likewise. * gdb.trace/report.exp (use_collected_data): Allow pid.tid style ptids, instead of just tid.
2015-11-23Fix internal error when saving fast tracepoint definitionsSimon Marchi2-1/+9
When trying to save fast tracepoints to file, gdb returns internal failure: gdb/breakpoint.c:13446: internal-error: unhandled tracepoint type 27 A problem internal to GDB has been detected, further debugging may prove unreliable. And no file including the fast tracepoints definition is created. The patch also extends save-trace.exp to test saving tracepoint with a fast tracepoint in there. Note that because this test doesn't actually inserts the tracepoints in the program, we can run it with targets that don't actually support fast tracepoints (or tracepoints at all). gdb/ChangeLog: * breakpoint.c (tracepoint_print_recreate): Fix logic error if -> else if. gdb/testsuite/ChangeLog: * gdb.trace/actions.c: Include trace-common.h. (main): Add a location for a fast tracepoint. * gdb.trace/save-trace.exp: Set a fast tracepoint in addition to the normal tracepoints. (gdb_verify_tracepoints): Adjust number of expected tracepoints.
2015-11-23Refactor gdb.trace/save-trace.expSimon Marchi1-43/+47
Some code is duplicated, to run the test twice with absolute and relative paths, so I factored it out in a few procs. It uses with_test_prefix to differentiate between test runs. I replaced usages of "save-tracepoints" with "save tracepoint", since the former is deprecated. I also removed the "10.x", as it doesn't make much sense anymore. It isn't used in general in the testsuite, and I don't think it's really useful. gdb/testsuite/ChangeLog: * save-trace.exp: Factor out code to these... (gdb_save_tracepoints): New. (gdb_load_tracepoints): New. (do_save_load_test): New.
2015-11-17gdb/testsuite: Fix left shift of negative value.Dominik Vogt1-1/+1
This patch fixes all occurences of left-shifting negative constants in C cod which is undefined by the C standard. gdb/testsuite/ChangeLog: * lib/dwarf.exp (_note): Fix left shift of negative value. * gdb.trace/trace-condition.exp: Likewise.
2015-11-11gdb/testsuite/gdb.trace: Deduplicate set_point assembly.Marcin Kościelnicki9-181/+72
The assembly code for emitting the proper tracepointable instruction was duplicated in many places. Keep it in one place, to reduce work needed for new targets. gdb/testsuite/ChangeLog: * gdb.trace/change-loc.h: include "trace-common.h", remove SYMBOL macro. (func5): Removed. (func4): Use FAST_TRACEPOINT_LABEL. * gdb.trace/ftrace-lock.c: include "trace-common.h", remove SYMBOL macro. (func): Removed. (thread_function): Use FAST_TRACEPOINT_LABEL. * gdb.trace/ftrace.c: include "trace-common.h", remove SYMBOL macro. (func): Remove. (marker): Use FAST_TRACEPOINT_LABEL. * gdb.trace/pendshr1.c: include "trace-common.h", remove SYMBOL macro. (pendfunc1): Remove. (pendfunc): Use FAST_TRACEPOINT_LABEL. * gdb.trace/pendshr2.c: include "trace-common.h", remove SYMBOL macro. (foo): Remove. (pendfunc2): Use FAST_TRACEPOINT_LABEL. * gdb.trace/trace-break.c: include "trace-common.h", remove SYMBOL macro. (func): Remove. (marker): Use FAST_TRACEPOINT_LABEL. * gdb.trace/trace-common.h: New header. * gdb.trace/trace-condition.c: include "trace-common.h", remove SYMBOL macro. (func): Remove. (marker): Use FAST_TRACEPOINT_LABEL. * gdb.trace/trace-mt.c: include "trace-common.h", remove SYMBOL macro. (func): Remove. (thread_function): Use FAST_TRACEPOINT_LABEL.
2015-11-10gdb/testsuite/gdb.trace: Deduplicate pcreg/spreg/fpreg.Marcin Kościelnicki11-145/+5
These variables were used in many gdb.trace tests. Keep them in one place, to reduce work needed for new targets. gdb/testsuite/ChangeLog: * gdb.trace/backtrace.exp: Use global fpreg/spreg definition, add $ in front. * gdb.trace/change-loc.exp: Use global pcreg definition. * gdb.trace/collection.exp: Use global pcreg/fpreg/spreg definition. * gdb.trace/entry-values.exp: Use global spreg definition, add $ in front. * gdb.trace/mi-trace-frame-collected.exp: Use global pcreg definition. * gdb.trace/pending.exp: Likewise. * gdb.trace/report.exp: Use global pcreg/fpreg/spreg definition. * gdb.trace/trace-break.exp: Likewise. * gdb.trace/trace-condition.exp: Use global pcreg definition, add $ in front. * gdb.trace/unavailable.exp: Use global pcreg/fpreg/spreg definition. * gdb.trace/while-dyn.exp: Use global fpreg definition, add $ in front. * lib/trace-support.exp: Define fpreg, spreg, pcreg variables.
2015-10-21Remove checking vCont;s in exec_cmd_expect_vCont_countYao Qi1-2/+2
Nowadays, in the range-stepping tests, we check not only the number of vCont;r packets but also the number of vCont;s packets, because we think the remote target which can do range stepping must support single step. However, if we turn displaced stepping on, the remote target (GDBserver) can do range stepping, and support single step, but GDB may decide to resume instructions in the scratchpad rather than single step them one by one for displaced stepping. For example, when aarch64 GDB debugs arm linux program with aarch64 GDBserver, GDBserver supports both range stepping and single step, but GDB (with the gdbarch for arm-linux) decides resume instructions in the scratchpad, so in the RSP traffic, there is no vCont;s packet at all, and some range-stepping.exp tests fail, FAIL: gdb.base/range-stepping.exp: multi insns: next: vCont;s=1 vCont;r=1 This patch is to get rid of the checking to the number of vCont;s in exec_cmd_expect_vCont_count. gdb/testsuite: 2015-10-21 Yao Qi <yao.qi@linaro.org> * lib/range-stepping-support.exp (exec_cmd_expect_vCont_count): Remove argument exp_vCont_s. * gdb.base/range-stepping.exp: Callers updated. * gdb.trace/range-stepping.exp: Likewise.
2015-09-21Add a test case for fast tracepoints' locking mechanismPierre Langlois2-0/+194
When installing a fast tracepoint, we create a jump pad with a spin-lock. This way, only one thread can collect a given tracepoint at any time. This test case checks that this lock actually works as expected. This test works by creating a function which overrides the in-process agent library's gdb_collect function. On start up, GDBserver will ask GDB with the 'qSymbol' packet about symbols present in the inferior. GDB will reply with the gdb_agent_gdb_collect function from the test case instead of the one from the agent. gdb/testsuite/ChangeLog: * gdb.trace/ftrace-lock.c: New file. * gdb.trace/ftrace-lock.exp: New file.
2015-09-21Enable fast tracepoint testsPierre Langlois10-1/+21
gdb/testsuite/ChangeLog: * gdb.trace/change-loc.h (func4) [__aarch64__]: Add a nop instruction. * gdb.trace/pendshr1.c (pendfunc): Likewise. * gdb.trace/pendshr2.c (pendfunc2): Likewise. * gdb.trace/range-stepping.c: Likewise. * gdb.trace/trace-break.c: Likewise. * gdb.trace/trace-mt.c (thread_function): Likewise. * gdb.trace/ftrace.c (marker): Likewise. * gdb.trace/trace-condition.c (marker): Likewise. * gdb.trace/ftrace.exp: Enable ftrace test if is_aarch64_target. * gdb.trace/trace-condition.exp: Set pcreg to "\$pc" if is_aarch64_target.
2015-09-17Add test case for tracepoints with conditionsPierre Langlois2-0/+234
This patch adds a test case for tracepoints with a condition expression. Each case will test a condition against the number of frames that should have been traced. Some of these tests fail on x86_64 and others on i386, which have been marked as known failures for now, see PR/18955. gdb/testsuite/ChangeLog: 2015-09-17 Pierre Langlois <pierre.langlois@arm.com> Yao Qi <yao.qi@linaro.org> * gdb.trace/trace-condition.c: New file. * gdb.trace/trace-condition.exp: New file.
2015-09-16Fix argument to compiled_cond, and add cases for compiled-condition.Wei-cheng Wang1-0/+64
This patch fixes the argument passed to compiled_cond. It should be regs buffer instead of tracepoint_hit_ctx. Test case is added as well for testing compiled-cond. gdb/gdbserver/ChangeLog 2015-09-16 Wei-cheng Wang <cole945@gmail.com> * tracepoint.c (eval_result_type): Change prototype. (condition_true_at_tracepoint): Fix argument to compiled_cond. gdb/testsuite/ChangeLog 2015-09-16 Wei-cheng Wang <cole945@gmail.com> * gdb.trace/ftrace.exp: (test_ftrace_condition) New function for testing bytecode compilation.
2015-08-21Warn when accessing binaries from remote targetsGary Benson1-4/+4
GDB provides no indicator of progress during file operations, and can appear to have locked up during slow remote transfers. This commit updates GDB to print a warning each time a file is accessed over RSP. An additional message detailing how to avoid remote transfers is printed for the first transfer only. gdb/ChangeLog: * target.h (struct target_ops) <to_fileio_open>: New argument warn_if_slow. Update comment. All implementations updated. (target_fileio_open_warn_if_slow): New declaration. * target.c (target_fileio_open): Renamed as... (target_fileio_open_1): ...this. New argument warn_if_slow. Pass warn_if_slow to implementation. Update debug printing. (target_fileio_open): New function. (target_fileio_open_warn_if_slow): Likewise. * gdb_bfd.c (gdb_bfd_iovec_fileio_open): Use new function target_fileio_open_warn_if_slow. gdb/testsuite/ChangeLog: * gdb.trace/pending.exp: Cope with remote transfer warnings.
2015-08-17Move strace -m/explicit location test to strace.expKeith Seitz1-0/+5
One of the build slaves shows this error running explicit.exp: (gdb) strace -m gdbfoobarbaz Remote failure reply: E.In-process agent library not loaded in process. Fast and static tracepoints unavailable. (gdb) FAIL: gdb.linespec/explicit.exp: strace -m gdbfoobarbaz There are two big problems with this test: 1) The expected output is actually not what the test is meant to test for. 2) This test should really only run where it is supported. This is most easily fixed by moving the test to gdb.trace/strace.exp. gdb/testsuite/ChangeLog * gdb.linespec/explicit.exp: Move strace test from here ... * gdb.trace/strace.exp: ... to here.
2015-07-15[testsuite] Skip gdb.trace/range-stepping.exp test case if not supportedPierre Langlois1-0/+5
Tracepoints and range stepping are independent features. This patch skips the gdb.trace/range-stepping.exp test case if the target does not support range stepping. gdb/testsuite/ChangeLog: * gdb.base/range-stepping.exp (gdb_range_stepping_enabled): Move it to ... * lib/range-stepping-support.exp (gdb_range_stepping_enabled): ... here. * gdb.trace/range-stepping.exp: Check that the target supports range stepping.
2015-07-09[testsuite][AArch64] Port gdb.tracePierre Langlois8-0/+23
This patch adds support for AArch64 to the gdb.trace testsuite. Note that it does not add support for testing fast tracepoint as it isn't supported. Therefore the test cases with inline assembly are not ported in this patch, as we do not know what the conditions for inserting a fast tracepoint on AArch64 would be. gdb/testsuite/ChangeLog: * gdb.trace/backtrace.exp: Set registers for aarch64 target. * gdb.trace/collection.exp: Likewise. * gdb.trace/mi-trace-frame-collected.exp: Likewise. * gdb.trace/mi-trace-unavailable.exp: Likewise. * gdb.trace/report.exp: Likewise. * gdb.trace/trace-break.exp: Likewise. * gdb.trace/unavailable.exp: Likewise. * gdb.trace/while-dyn.exp: Likewise.
2015-07-08PR18617 - Incorrect expression bytecode generated for narrowing conversionsRobert O'Callahan1-0/+2
The existing code preserves 'from' bits, which is incorrect. E.g. (gdb) maint agent-eval (char)255L Scope: 0x4008d6 Reg mask: 00 0 const16 255 3 ext 64 5 end 'ext 64' should be 'ext 8'; this bytecode evaluates to 255 instead of the correct result of -1. The fix is simple. I ran the entire test suite on x86-64 and there were no new test failures. gdb/ChangeLog: 2015-07-08 Robert O'Callahan <robert@ocallahan.org> PR exp/18617 * ax-gdb.c (gen_conversion): Extend to 'to' bits, not 'from'. gdb/testsuite/ChangeLog: 2015-07-08 Robert O'Callahan <robert@ocallahan.org> PR exp/18617 * gdb.trace/ax.exp: Add test.
2015-04-08Fix gdb.trace/{actions,infotrace,while-stepping}.exp with extended-remotePedro Alves3-3/+25
The recent actions.exp change to check gdb_run_cmd succeeded caught further problems. The test now fails like this with --target_board=native-extended-gdbserver: FAIL: gdb.trace/actions.exp: Can't run to main gdb.log shows: (gdb) run Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.trace/actions Running the default executable on the remote target failed; try "set remote exec-file"? (gdb) FAIL: gdb.trace/actions.exp: Can't run to main The problem is that a gdb_load call is missing. Grepping around for similar problems in other tests, I found that infotrace.exp and while-stepping.exp should be likewise affected. And indeed this is what we get today: FAIL: gdb.trace/infotrace.exp: tstart FAIL: gdb.trace/infotrace.exp: continue to end (the program is no longer running) FAIL: gdb.trace/infotrace.exp: tstop FAIL: gdb.trace/infotrace.exp: 2.6: info tracepoints (trace buffer usage) FAIL: gdb.trace/while-stepping.exp: tstart FAIL: gdb.trace/while-stepping.exp: tstop FAIL: gdb.trace/while-stepping.exp: tfile: info tracepoints FAIL: gdb.trace/while-stepping.exp: ctf: info tracepoints while-stepping.exp even has the same race bug actions.exp had. After this, {actions,infotrace,while-stepping}.exp all pass cleanly with the native-extended-gdbserver board. gdb/testsuite/ChangeLog: 2015-04-08 Pedro Alves <palves@redhat.com> * gdb.trace/actions.exp: Use gdb_load before gdb_run_cmd. * gdb.trace/infotrace.exp: Use gdb_load before gdb_run_cmd. Use gdb_breakpoint instead of gdb_test that doesn't expect anything. Return early if running to main fails. * gdb.trace/while-stepping.exp: Likewise.