binutils-gdb

Commit Graph

Author	SHA1	Message	Date
Simon Marchi	9080ac9d99	Add test for tracepoint enable/disable 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.	10 years ago
Simon Marchi	952ebca583	ftrace tests: Use gdb_load_shlib result to lookup IPA in info sharedlibrary 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.	10 years ago
Simon Marchi	d9019901f8	Rename gdb_load_shlibs to gdb_load_shlib 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.	10 years ago
Simon Marchi	fca4cfd9ec	Make gdb_load_shlibs return the destination path of the library This patch makes gdb_load_shlibs return the destination path of the copied library. To make the procedure implementation and interface more straightforward, it also changes it so that it accepts a single shared library path at the time. Therefore, calls that are passed multiple libraries: gdb_load_shlibs $lib1 $lib2 must be changed to separate calls: gdb_load_shlibs $lib1 gdb_load_shlibs $lib2 A subtle impact is the solib-search-path handling. In the former version, solib-search-path is set using the directory of the first passed lib (further calls overwrite the value). In the later version, the directory of the library passed to the last call to gdb_load_shlibs remnains. I don't think that's a problem in practice, since if we had tests that needed multiple different paths in solib-search-path, they wouldn't work in the first place. Changed in v2: * Split behavioural and rename changes in two separate patches. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_load_shlibs): Accept a single argument. Return result of gdb_remote_download. * gdb.base/ctxobj.exp: Split gdb_load_shlibs call. * gdb.base/dso2dso.exp: Likewise. * gdb.base/global-var-nested-by-dso.exp: Likewise. * gdb.base/print-file-var.exp: Likewise. * gdb.base/shlib-call.exp: Likewise. * gdb.base/shreloc.exp: Likewise. * gdb.base/solib-overlap.exp: Likewise. * gdb.base/solib-weak.exp (do_test): Likewise. * gdb.base/unload.exp: Likewise.	10 years ago
Yao Qi	11cf4ffb5e	Skip gdb.base/branch-to-self.exp if gdb,nosignals exists I get a timeout fail in branch-to-self.exp when it is compiled by a bare-mental target running qemu, which doesn't have signal. The test should be skipped if gdb,nosignals exists, and that is what this patch does. gdb/testsuite: 2016-04-27 Yao Qi <yao.qi@linaro.org> * gdb.base/branch-to-self.exp: Skip it if gdb,nosignals exists.	10 years ago
Keven Boell	3e2e34f862	fort_dyn_array: Use value constructor instead of raw-buffer manipulation. Instead of pre-computing indices into a fortran array re-use the value_* interfaces to subscript a fortran array. The benefit of using the new interface is that it takes care of dynamic types and resolve them when needed. This fixes issues when printing structures with dynamic arrays from toplevel. Before: (gdb) p twov $1 = ( (( ( 6352320, 0, -66, -1, 267) ( 343476, 1, -15, 1, 0) ( 5, 0, 5, 0, 1) ... After: (gdb) p twov $1 = ( (( ( 1, 1, 1, 1, 1) ( 1, 1, 321, 1, 1) ( 1, 1, 1, 1, 1) ... 2016-04-26 Sanimir Agovic <sanimir.agovic@intel.com> Keven Boell <keven.boell@intel.com> Bernhard Heckel <bernhard.heckel@intel.com> gdb/Changelog: * f-valprint.c (f77_create_arrayprint_offset_tbl): Remove function. (F77_DIM_SIZE, F77_DIM_OFFSET): Remove macro. (f77_print_array_1): Use value_subscript to subscript a value array. (f77_print_array): Remove call to f77_create_arrayprint_offset_tbl. (f_val_print): Use value_field to construct a field value. gdb/testsuite/Changelog: * vla-type.exp: Print structure from toplevel.	10 years ago
Bernhard Heckel	8f07e298b1	fort_dyn_array: Support evaluation of dynamic elements inside arrays. Resolve type of an array's element to be printed in case it is dynamic. Otherwise we don't use the correct boundaries nor the right location. Before: ptype fivearr(1) type = Type five Type one integer(kind=4) :: ivla(34196784:34196832,34197072:34197120,34197360:34197408) End Type one :: tone End Type five After: ptype fivearr(1) type = Type five Type one integer(kind=4) :: ivla(2,4,6) End Type one :: tone End Type five 2016-04-26 Bernhard Heckel <bernhard.heckel@intel.com> gdb/Changelog: * valarith.c (value_address): Resolve dynamic types. gdb/testsuite/Changelog: * gdb.fortran/vla-type.f90: Add test for static and dynamic arrays of dynamic types. * gdb.fortran/vla-type.exp: Add test for static and dynamic arrays of dynamic types.	10 years ago
Bernhard Heckel	9920b4348e	fort_dyn_array: Enable dynamic member types inside a structure. Fortran supports dynamic types for which bounds, size and location can vary during their lifetime. As a result of the dynamic behaviour, they have to be resolved at every query. This patch will resolve the type of a structure field when it is dynamic. 2016-04-26 Bernhard Heckel <bernhard.heckel@intel.com> 2016-04-26 Keven Boell <keven.boell@intel.com> Before: (gdb) print threev%ivla(1) Cannot access memory at address 0x3 (gdb) print threev%ivla(5) no such vector element After: (gdb) print threev%ivla(1) $9 = 1 (gdb) print threev%ivla(5) $10 = 42 gdb/Changelog: * NEWS: Add new supported features for fortran. * gdbtypes.c (remove_dyn_prop): New. (resolve_dynamic_struct): Keep type length for fortran structs. * gdbtypes.h: Forward declaration of new function. * value.c (value_address): Return dynamic resolved location of a value. (set_value_component_location): Adjust the value address for single value prints. (value_primitive_field): Support value types with a dynamic location. (set_internalvar): Remove dynamic location property of internal variables. gdb/testsuite/Changelog: * gdb.fortran/vla-type.f90: New file. * gdb.fortran/vla-type.exp: New file.	10 years ago
Yao Qi	f3abeff575	New test case gdb.base/branch-to-self.exp gdb/testsuite: 2016-04-25 Yao Qi <yao.qi@linaro.org> * gdb.base/branch-to-self.c: New file. * gdb.base/branch-to-self.exp: New file.	10 years ago
Yao Qi	0a5d52f0ec	Fix fails in gdb.trace/unavailable.exp 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.	10 years ago
Yao Qi	495346f6f0	Fix fail in gdb.base/annota1.exp and gdb.base/annota3.exp Hi, I am seeing the fail below on aarch64-linux with gcc 4.9.2, break main Breakpoint 1 at 0x4006e8: file binutils-gdb/gdb/testsuite/gdb.base/annota1.c, line 14.^M (gdb) FAIL: gdb.base/annota1.exp: breakpoint main the test expects the breakpoint is set on line 15. Let us look at the main function, 12 int 13 main (void) 14 { 15 int my_array[3] = { 1, 2, 3 }; /* break main / 16 17 value = 7; 18 19 #ifdef SIGUSR1 20 signal (SIGUSR1, handle_USR1); 21 #endif (gdb) disassemble main Dump of assembler code for function main: 0x00000000004006e0 <+0>: stp x29, x30, [sp,#-48]! 0x00000000004006e4 <+4>: mov x29, sp 0x00000000004006e8 <+8>: adrp x0, 0x411000 <signal@got.plt> 0x00000000004006ec <+12>: add x0, x0, #0x40 the breakpoint is set on the right address after skipping prologue, but 0x00000000004006e8 is mapped to the line 14, as shown below, (gdb) maintenance info line-table objfile: /home/yao.qi/source/build-aarch64/gdb/testsuite/outputs/gdb.base/annota1/annota1 ((struct objfile ) 0x2b0e1850) compunit_symtab: ((struct compunit_symtab ) 0x2b0ded50) symtab: /home/yao.qi/source/binutils-gdb/gdb/testsuite/gdb.base/annota1.c ((struct symtab ) 0x2b0dedd0) linetable: ((struct linetable ) 0x2b12c8b0): INDEX LINE ADDRESS 0 7 0x00000000004006d0 1 8 0x00000000004006d8 2 14 0x00000000004006e0 3 14 0x00000000004006e8 4 15 0x00000000004006fc so GDB does nothing wrong. Program hits breakpoint on either line 14 or line 15 is right to me. With anther gcc (4.9.3), the line-table looks correct, and no test fail. Instead of setting breakpoint on main and assuming the line is what we get from the source, we can set breakpoint on that line. On the other hand, the test prints the values of the array and check, so we need to set breakpoint on the line setting the values of array and "next", rather than setting the breakpoint on main. gdb/testsuite: 2016-04-22 Yao Qi <yao.qi@linaro.org> gdb.base/annota1.exp: Set breakpoint on line $main_line. * gdb.base/annota3.exp: Likewise.	10 years ago
Yao Qi	4a7e075c3f	Tweak gdb.reverse/step-precsave.exp and gdb.reverse/step-reverse.exp I see the following test fail in arm-linux with -marm and -fomit-frame-pointer, step callee () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/step-reverse.c:27 27 } /* RETURN FROM CALLEE / (gdb) step main () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/step-reverse.c:58 58 callee(); / STEP INTO THIS CALL / (gdb) FAIL: gdb.reverse/step-precsave.exp: reverse step into fn call As we can see, the "step" has already stepped into the function callee, but in the last line. The second "step" attempts to step to function body, but it goes out of callee, which isn't expected. The program is compiled with -marm and -fomit-frame-pointer, the function callee is prologue-less, because nothing needs to be saved on stack, (gdb) disassemble callee Dump of assembler code for function callee: 0x00010680 <+0>: movw r3, #2364 ; 0x93c 0x00010684 <+4>: movt r3, #2 0x00010688 <+8>: ldr r3, [r3] 0x0001068c <+12>: add r2, r3, #1 0x00010690 <+16>: movw r3, #2364 ; 0x93c 0x00010694 <+20>: movt r3, #2 0x00010698 <+24>: str r2, [r3] 0x0001069c <+28>: mov r3, #0 0x000106a0 <+32>: mov r0, r3 0x000106a4 <+36>: bx lr program stops at the 0x106a0 (passed the epilogue) after the first "step". When second "step" is executed, the stepping range is [0x10680-0x106a0], which starts from the first instruction of function callee (because it doesn't have prologue). infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [LWP 2461] at 0x1069c^M infrun: prepare_to_wait^M infrun: target_wait (-1.0.0, status) =^M infrun: 2461.2461.0 [LWP 2461],^M infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP^M infrun: TARGET_WAITKIND_STOPPED^M infrun: stop_pc = 0x10698^M infrun: stepping inside range [0x10680-0x106a0] When program goes out of the range, it stops at the caller of callee, and test fails. IOW, if function callee has prologue, the stepping range won't start from the first instruction of the function, and program stops at the prologue and test passes. IMO, GDB does nothing wrong, but test shouldn't expect the program stops in callee after the second "step". I decide to fix test rather than GDB. In this patch, I change to test to do one "step", and check the program is still in callee, then, do multiple "step" until program goes out of the callee. gdb/testsuite: 2016-04-22 Yao Qi <yao.qi@linaro.org> gdb.reverse/step-precsave.exp: Do one step and test program stops in "callee" and do multiple steps until program goes out of "callee". * gdb.reverse/step-reverse.exp: Likewise.	10 years ago
Yao Qi	5b061e9886	Deliver signal in hardware single step 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.	10 years ago
Yao Qi	5c5dc57fcf	New test case gdb.trace/signal.exp 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.	10 years ago
Doug Evans	a55411b9ff	* source.c (is_regular_file): New arg errno_ptr. gdb/ChangeLog: * source.c (is_regular_file): New arg errno_ptr. All callers updated. gdb/testsuite/ChangeLog: * gdb.base/bad-file.exp: New file.	10 years ago
Martin Galvan	a22df60ad2	Fix gdb crash when trying to print the address of a synthetic C++ reference After compiling a program which uses C++ references some optimizations may convert the references into synthetic "pointers". Trying to print the address of one of such synthetic references causes gdb to crash with the following error: (gdb) print &ref /build/buildd/gdb-7.7.1/gdb/dwarf2loc.c:1624: internal-error: Should not be able to create a lazy value with an enclosing type A problem internal to GDB has been detected, further debugging may prove unreliable. Apparently, what was causing it was that value_addr returns a copy of the value that represents the reference with its type set to T* instead of T&. However, its enclosing_type is left untouched, which fails a check made in read_pieced_value. We only see the crash happen for references that are synthetic because they're treated as pieced values, thus the call to read_pieced_value. On a related note, it seems that in general there are all sorts of breakage when working with synthetic references. This is reported here: https://sourceware.org/bugzilla/show_bug.cgi?id=19893 gdb/ChangeLog: 2016-04-18 Martin Galvan <martin.galvan@tallertechnologies.com> * valops.c (value_addr): For C++ references, set the copied value's enclosing_type as well. gdb/testsuite/ChangeLog: 2016-04-18 Martin Galvan <martin.galvan@tallertechnologies.com> * gdb.dwarf2/implref.exp: New file.	10 years ago
Bernhard Heckel	0c13f7e559	fortran: Testsuite, fix different type naming across compilers. Gfortran and ifort have different names for data types. Encapsulate type names in a library to increase number of supported compilers. gfortran -4.2 : int4 gfortran>=4.3 : integer(kind=4) ifort : INTEGER(4) 2016-04-18 Bernhard Heckel <bernhard.heckel@intel.com> gdb/testsuite/Changelog: * gdb.fortran/common-block.exp: Use type naming defined in lib fortran. * gdb.fortran/derived-type.exp: Use type naming defined in lib fortran. * gdb.fortran/multi-dim.exp: Use type naming defined in lib fortran. * gdb.fortran/vla-datatypes.exp: Use type naming defined in lib fortran. * gdb.fortran/vla-ptype-sub.exp: Use type naming defined in lib fortran. * gdb.fortran/vla-ptype.exp: Use type naming defined in lib fortran. * gdb.fortran/whatis_type.exp: Use type naming defined in lib fortran. * lib/fortran.exp (fortran_int4): New procedure. (fortran_real4, fortran_real8, fortran_complex4): Likewise. (fortran_logical4): Likewise.	11 years ago
Bernhard Heckel	9b9b09e902	Testsuite: Fix compiling of shared libraries with ICC. We are missing "-fpic" flag when compiling shared libraries with ICC. 2016-04-18 Bernhard Heckel <bernhard.heckel@intel.com> gdb/Testsuite/Changelog: * lib/gdb.exp (gdb_compile_shlib): Add flag for ICC compiler.	10 years ago
Bernhard Heckel	a14d1f4dfc	testsuite: Support detection of Intel compilers via test_compiler_version. Add Intel specific preprocessor macros to query the version of the compiler. 2016-04-18 Bernhard Heckel <bernhard.heckel@intel.com> gdb/Testsuite/Changelog: * lib/compiler.c: Add Intel specific preprocessor macros. * lib/compiler.cc: Likewise.	10 years ago
Luis Machado	7d49b1d0b0	Test GDB connection to GDBserver with no symbol files This test exercises the scenarios where we attempt to connect GDB to GDBserver in standard remote mode, query the symbol file path, attempt to open said symbol file on GDB's end and fail, causing the connection to drop abruptly. Regression-tested on x86-64/Ubuntu. With an unpatched GDB we should see this: FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: action=permission: connection to GDBserver succeeded (the program is no longer running) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: action=delete: connection to GDBserver succeeded (the program is no longer running) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: connection to GDBserver succeeded (the program is no longer running) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=delete: connection to GDBserver succeeded (the program is no longer running) A patched GDB should have full passes. gdb/testsuite/ChangeLog: 2016-04-13 Luis Machado <lgustavo@codesourcery.com> * gdb.server/connect-with-no-symbol-file.c: New file. * gdb.server/connect-with-no-symbol-file.exp: New file.	10 years ago
Simon Marchi	8392fa22d6	Fix and improve comment in gdb_remote_download This patch fixes the current comment in gdb_remote_download, which is false (the "except if that's already where it is" part). It also improves it, by explaining why pass TOFILE through standard_output_file, even it is an absolute path. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_remote_download): Fix and extend comment.	10 years ago
Simon Marchi	8c4c4aeba6	gdbserver-base.exp: Copy file to standard output directory in ${board}_download gdbserver-base.exp is used as the base for both native-gdbserver.exp and native-extended-gdbserver.exp. (Despite its name, it should really be considered as a "local-gdbserver-base", as it's not really appropriate to implement a remote gdbserver board.) Currently, the _download procedure is implemented as a no-op (it returns the source file path). Because of the SONAME change, The fast tracepoint tests now require the executable and the IPA (libinproctrace.so) to be located in the same directory (see [1]). When using the native-gdbserver board, because _download returns the original file path, the executable does not end up in the same directory as the library, and it fails to execute. In more general terms, with the recent changes, the testsuite now assumes that when it does ${board}_download <source path 1> <destination path 1> ${board}_download <source path 2> <destination path 2> where the destination paths are relative (generally just the file name), both files will end up in the same base directory. That assumption does not hold for the current implementation in gdbserver-base.exp. The proper fix would be to make native-gdbserver non-remote, so that gdb_remote_download would not call DejaGnu's remote_download (see [2]). We could then get rid of ${board}_download in gdbserver-base.exp. However, that will likely take some time to complete. In the mean time, in order to make the fast tracepoint tests pass, we can simply copy the file to the standard output directory. Basically, it just mimics what gdb_remote_download would do if the board wasn't flagged as remote. Note that I missed these failures originally because I had a libinproctrace.so in /usr/local/lib. So, even though libinproctrace.so wasn't copied to the test output directory, it did find the one in /usr/local/lib. It would be nice to find a way to protect against this, as it could easily happen again... Regtested with unix, native-gdbserver and native-extended-gdbserver, and didn't see anything notable, except the ftrace tests now passing for native-gdbserver. [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=6e774b13c3b81ac2599812adf058796948ce7e95 [2] https://sourceware.org/ml/gdb-patches/2016-04/msg00112.html gdb/testsuite/ChangeLog: * boards/gdbserver-base.exp (${board}_download): Copy source file to standard output directory.	10 years ago
Antoine Tremblay	45e3745ed0	Fix aarch64 ftrace JIT condition testcase 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.	10 years ago
Markus Metzger	e26b7e4165	btrace: fix test build error in gdb.btrace/instruction_history.c On systems with a newer version of GCC the gdb.btrace/instruction_history.exp test fails to build like this: Running .../gdb.btrace/instruction_history.exp ... gdb compile failed, .../gdb.btrace/instruction_history.c: In function 'main': .../gdb.btrace/instruction_history.c:24:3: warning: implicit declaration of function 'loop' [-Wimplicit-function-declaration] loop (); ^ Declare loop to fix it. testsuite/ * gdb.btrace/instruction_history.c (loop): Add declaration.	10 years ago
Antoine Tremblay	8ce0946295	Fix typo in ftrace.exp condition testing 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".	10 years ago
Simon Marchi	2e88a1ea30	gdb.python/py-mi-events-gdb.py: Add parentheses to print Required for Python 3 gdb/testsuite/ChangeLog: * gdb.python/py-mi-events-gdb.py (signal_stop_handler): Add parentheses to print. (continue_handler): Likewise.	11 years ago
Simon Marchi	f48e22e3f2	Make gdb.server/solib-list.exp work for remote targets There are a few small changes needed to make it work with a real remote target. - Remove the [is_remote target] check. - Remove soname setting when building the lib, it's done by default now anyway. - In the compilation of the executable, pass the shared lib using the shlib option, so that RPATH is set. - Download the program to the target using gdb_remote_download, and record the remote path. Remove loading of the program using gdb_load_shlibs, which was not really appropriate anyway. - Run the remote path through readlink (see comment in the code). - Start gdbserver with the remote path. Also, don't set executable and objfile variables, as they are unused. Tested with native, native-gdbserver, native-extended-gdbserver, and a remote gdbserver. gdb/testsuite/ChangeLog: * gdb.server/solib-list.exp: Remove is_remote check. Pass shlib= to gdb_compile. Don't link shared library with -soname. Call gdb_remote_download instead of gdb_load_shlibs. Run binary filename through "readlink -f" on the target.	11 years ago
Pedro Alves	096be756aa	Fix gdb.server/solib-list.exp regression Commit `7817ea4614` (Improve gdb_remote_download, remove gdb_download) caused: FAIL: gdb.server/solib-list.exp: non-stop 0: target extended-remote (timeout) FAIL: gdb.server/solib-list.exp: non-stop 0: continue (the program is no longer running) FAIL: gdb.server/solib-list.exp: non-stop 0: p libvar FAIL: gdb.server/solib-list.exp: non-stop 1: target extended-remote (timeout) FAIL: gdb.server/solib-list.exp: non-stop 1: continue (the program is no longer running) FAIL: gdb.server/solib-list.exp: non-stop 1: p libvar gdb.log shows: system interpreter is: /lib64/ld-linux-x86-64.so.2 ... spawn ../gdbserver/gdbserver --once :2347 /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.server/solib-list/ld-linux-x86-64.so.2 /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.server/solib-list/solib-list Process /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.server/solib-list/ld-linux-x86-64.so.2 created; pid = 18637 Cannot exec /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.server/solib-list/ld-linux-x86-64.so.2: No such file or directory. ... The test copied the interpreter to the outputs directory, however ld-linux-x86-64.so.2 is a relative symlink that when copied points nowhere: $ ls -l testsuite/outputs/gdb.server/solib-list/ total 52 -rwxrwxr-x. 1 pedro pedro 13450 Apr 7 10:52 gdb.log -rw-rw-r--. 1 pedro pedro 1512 Apr 7 10:52 gdb.sum lrwxrwxrwx. 1 pedro pedro 10 Apr 7 11:39 ld-linux-x86-64.so.2 -> ld-2.22.so -rwxrwxr-x. 1 pedro pedro 9464 Apr 7 11:39 solib-list -rw-rw-r--. 1 pedro pedro 3472 Apr 7 11:39 solib-list-lib.c.o -rw-rw-r--. 1 pedro pedro 2760 Apr 7 11:39 solib-list.o -rwxrwxr-x. 1 pedro pedro 9232 Apr 7 11:39 solib-list.so The copying comes from gdbserver_spawn -> gdbserver_download_current_prog -> gdb_remote_download. There's actually no need to download the interpreter to the target - it's part of the target system/environment. So fix this by making the test just not use gdb_load (and gdb_file_cmd as consequence) at all, and instead pass the interpreter filename to gdbserver as an argument. gdb/testsuite/ChangeLog: 2016-04-08 Pedro Alves <palves@redhat.com> * gdb.server/solib-list.exp: Don't use gdb_load. Instead pass the interpreter filename as argument to gdbserver_spawn. * lib/gdbserver-support.exp (gdbserver_download_current_prog): Return empty if $last_loaded_file does not exist.	11 years ago
Jan Kratochvil	0650053364	testsuite: Fix for gcc-4.8: gdb.base/jit.exp gdb.base/jit-so.exp on CentOS-7.2 I get Running /home/jkratoch/redhat/gdb-test-reg/gdb/testsuite/gdb.base/jit.exp ... FAIL: gdb.base/jit.exp: one_jit_test-1: continue to breakpoint: break here 2 (the program exited) FAIL: gdb.base/jit.exp: one_jit_test-2: continue to breakpoint: break here 2 (the program exited) FAIL: gdb.base/jit.exp: attach: one_jit_test-2: continue to breakpoint: break here 2 (the program exited) FAIL: gdb.base/jit.exp: attach: one_jit_test-2: break here 2: set var wait_for_gdb = 1 FAIL: gdb.base/jit.exp: attach: one_jit_test-2: break here 2: detach (the program is no longer running) FAIL: gdb.base/jit.exp: attach: one_jit_test-2: break here 2: attach FAIL: gdb.base/jit.exp: attach: one_jit_test-2: break here 2: set var wait_for_gdb = 0 FAIL: gdb.base/jit.exp: PIE: one_jit_test-1: continue to breakpoint: break here 2 (the program exited) Running /home/jkratoch/redhat/gdb-test-reg/gdb/testsuite/gdb.base/jit-so.exp ... FAIL: gdb.base/jit-so.exp: one_jit_test-1: continue to breakpoint: break here 2 (the program exited) FAIL: gdb.base/jit-so.exp: one_jit_test-2: continue to breakpoint: break here 2 (the program exited) since: `85af34ee02` is the first bad commit commit `85af34ee02` Author: Pedro Alves <palves@redhat.com> Date: Thu Mar 31 19:28:47 2016 +0100 Add regression test for PR gdb/19858 (JIT code registration on attach) The compiled code's .debug_line is wrong (for the simplistic approach of GDB to put a breakpoint on the first address belonging to that source line) and so GDB misses the breakpoint at the last line: WAIT_FOR_GDB; return 0; /* gdb break here 2 / Most of the patch is just about reindentation, no changes there. gdb/testsuite/ChangeLog 2016-04-08 Jan Kratochvil <jan.kratochvil@redhat.com> Fix compatibility with gcc-4.8.5-4.el7.x86_64. gdb.base/jit-main.c: Use exit after usage.	11 years ago
Jan Kratochvil	2d35e87127	testsuite: Fix false FAILs with .bashrc GDBHISTFILE=... $ GDBHISTFILE=/tmp/gdbhistfile runtest gdb.base/gdbhistsize-history.exp gdb.base/gdbinit-history.exp Running ./gdb.base/gdbinit-history.exp ... FAIL: gdb.base/gdbinit-history.exp: home=gdbinit-history/unlimited gdbhistsize=1000: show commands FAIL: gdb.base/gdbinit-history.exp: home=gdbinit-history/unlimited gdbhistsize=foo: show commands Running ./gdb.base/gdbhistsize-history.exp ... FAIL: gdb.base/gdbhistsize-history.exp: histsize=: show commands FAIL: gdb.base/gdbhistsize-history.exp: histsize=20: show commands FAIL: gdb.base/gdbhistsize-history.exp: histsize= 20 : show commands FAIL: gdb.base/gdbhistsize-history.exp: histsize=-5: show commands FAIL: gdb.base/gdbhistsize-history.exp: histsize=not_an_integer: show commands FAIL: gdb.base/gdbhistsize-history.exp: histsize=10zab: show commands FAIL: gdb.base/gdbhistsize-history.exp: histsize=-5ab: show commands FAIL: gdb.base/gdbhistsize-history.exp: histsize=99999999999999999999999999999999999: show commands FAIL: gdb.base/gdbhistsize-history.exp: histsize=50: show commands This happens for my setup due to my: $ grep GDB ~/.bashrc export GDBHISTFILE="$HOME/.gdb_history" gdb/testsuite/ChangeLog 2016-04-07 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.base/gdbhistsize-history.exp: Save and unset GDBHISTFILE and GDBHISTSIZE prior to the tests. * gdb.base/gdbinit-history.exp: Likewise.	11 years ago
Pedro Alves	9553661a5f	Fix gdb.compile/compile.exp shlib regression Commit `6e774b13c3` (Make ftrace tests work with remote targets) made a few gdb.compile/compile.exp tests disappear: -PASS: gdb.compile/compile.exp: call shared library function -PASS: gdb.compile/compile.exp: expect 1 -PASS: gdb.compile/compile.exp: modify shared library variable -PASS: gdb.compile/compile.exp: expect 15 This is because the test uses ldflags instead of using the shlib option, so it misses linking with -rpath, resulting in: (gdb) run Starting program: .../compile/compile-shlib .../compile/compile-shlib: error while loading shared libraries: compile-shlib.so: cannot open shared object file: No such file or directory [Inferior 1 (process 18014) exited with code 0177] We were missing a gdb_load_shlibs call, which is needed for remote testing. gdb/testsuite/ChangeLog: 2015-04-07 Pedro Alves <palves@redhat.com> * gdb.compile/compile.exp: Use gdb_compile with "shlib=" option instead of build_executable. Use gdb_load_shlibs.	11 years ago
Yao Qi	c8064e7e9b	Fix gdb.reverse/finish-reverse-bkpt.exp I see the following fail on aarch64-linux break void_func Breakpoint 2 at 0x4007a0: file gdb/testsuite/gdb.reverse/finish-reverse.c, line 44. (gdb) PASS: gdb.reverse/finish-reverse-bkpt.exp: set breakpoint on void_func continue Continuing. Breakpoint 2, void_func () at gdb/testsuite/gdb.reverse/finish-reverse.c:44^M 44 void_test = 1; /* VOID FUNC /^M (gdb) PASS: gdb.reverse/finish-reverse-bkpt.exp: continue to breakpoint: void_func break void_func^M Note: breakpoint 2 also set at pc 0x4007a0.^M Breakpoint 3 at 0x4007a0: file gdb/testsuite/gdb.reverse/finish-reverse.c, line 44. (gdb) PASS: gdb.reverse/finish-reverse-bkpt.exp: set breakpoint at void_func's entry reverse-finish^M Run back to call of #0 void_func () at gdb/testsuite/gdb.reverse/finish-reverse.c:44 main (argc=1, argv=0x7ffffffb78) at gdb/testsuite/gdb.reverse/finish-reverse.c:98 98 void_func (); /* call to void_func /^M (gdb) FAIL: gdb.reverse/finish-reverse-bkpt.exp: reverse-finish from void_func trips breakpoint at entry The test assumes that brekapoints on "void_func" and "void_func" are set on different places because of function prologue. However, on aarch64-linux, there is no prologue in void_func, so two breakpoints are set at the same place (0x4007a0). (gdb) disassemble void_func Dump of assembler code for function void_func: 0x00000000004007a0 <+0>: adrp x0, 0x410000 0x00000000004007a4 <+4>: add x0, x0, #0xc14 0x00000000004007a8 <+8>: mov w1, #0x1 0x00000000004007ac <+12>: str w1, [x0] 0x00000000004007b0 <+16>: ret The fix to this problem is to single step forward before setting breakpoint on void_func. gdb/testsuite: 2016-04-07 Yao Qi <yao.qi@linaro.org> gdb.reverse/finish-reverse-bkpt.exp: Use temporary breakpoint. Execute "si" command.	11 years ago
Yao Qi	bde475616e	Fix gdb.reverse/next-reverse-bkpt-over-sr.exp I see the fail on aarch64-linux, (gdb) reverse-next Breakpoint 2, callee () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/step-reverse.c:26^M 26 myglob++; return 0; /* ARRIVED IN CALLEE / (gdb) FAIL: gdb.reverse/next-reverse-bkpt-over-sr.exp: reverse-next over call trips user breakpoint at function entry The test expects program stops at line 25, but program stops at line 26. (gdb) maintenance info line-table objfile: /scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/testsuite/outputs/gdb.reverse/next-reverse-bkpt-over-sr/next-reverse-bkpt-over-sr ((struct objfile ) 0x613000002880) compunit_symtab: ((struct compunit_symtab ) 0x621000121760) symtab: /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/step-reverse.c ((struct symtab ) 0x6210001217e0) linetable: ((struct linetable ) 0x6210001520d0): INDEX LINE ADDRESS 0 25 0x0000000000400890 1 26 0x0000000000400890 2 27 0x00000000004008b0 (gdb) disassemble callee Dump of assembler code for function callee: 0x0000000000400890 <+0>: adrp x0, 0x410000 0x0000000000400894 <+4>: add x0, x0, #0xcac the line-table show that the first instruction of function callee is mapped line 25 and 26. I am not sure the line-table is correct, but it is not the point of this test. The goal of this test is to test program hits the breakpoint on the first instruction of function after 'reverse-next', so I change this test to expect the breakpoint number the program hits. gdb/testsuite: 2016-04-07 Yao Qi <yao.qi@linaro.org> gdb.reverse/next-reverse-bkpt-over-sr.exp: Match the breakpoint number instead of the comments on some line.	11 years ago
Don Breazeal	b16f8a3b1e	Optimized-out pointer: New test for error handling This patch implements a test that ensures that with "set print object on", -var-create returns "<optimized out>" for an optimized out pointer to structure, rather than throwing an error, while also ensuring that any attempt to dereference the pointer will throw an error. It uses the dwarf assembler to construct the appropriate debug info to represent a pointer-to-struct in the program as optimized out, and then accesses that pointer in various ways. The test uses both the console interpreter and the MI interpreter. gdb/testsuite/ChangeLog: 2016-04-06 Don Breazeal <donb@codesourcery.com> * gdb.dwarf2/dw2-opt-structptr.c: New test program. * gdb.dwarf2/dw2-opt-structptr.exp: New test script.	11 years ago
Simon Marchi	c2f901dfb6	Fix gdb.threads/dlopen-libpthread.exp crash Following, commit `6e774b13c3` Make ftrace tests work with remote targets the test gdb.threads/dlopen-libpthread.exp started to fail with: ERROR: error copying "/home/emaisin/build/binutils-gdb/gdb/testsuite/gdb.threads/dlopen-libpthread.so": no such file or directory This is because the library path is not computed using standard_output_file, so we try to gdb_load_shlibs an unexisting file. gdb/testsuite/ChangeLog: * gdb.threads/dlopen-libpthread.exp: Set binfile_lib using standard_output_file. Remove unused binfile variable.	11 years ago
Catalin Udma	ac17fda08b	testsuite: Update py-mi-objfile to expect console format print 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>	11 years ago
Simon Marchi	03a8c4dfc2	Fix IPA detection in ftrace-insn-reloc.exp 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.	11 years ago
Simon Marchi	6e774b13c3	Make ftrace tests work with remote targets 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.	11 years ago
Simon Marchi	7817ea4614	Improve gdb_remote_download, remove gdb_download 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.	11 years ago
Simon Marchi	7beb7f68a0	Fix gdb.mi/mi-breakpoint-changed.exp for remote targets 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.	11 years ago
Artemiy Volkov	cc63428a4c	gdb: allow enumeration constants as second operand of BINOP_REPEAT 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.	11 years ago
Pedro Alves	64cdf930d9	Add regression test for PR gdb/19858 (JIT code registration on attach) 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.	11 years ago
Pedro Alves	40dea8cbf6	Make gdb.base/jit.exp binaries unique 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.	11 years ago
Catalin Udma	e7ea3ec7c6	python: Use console format for output of gdb.execute command 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>	11 years ago
Yao Qi	e6359af3fd	Simplify gdb.reverse/until-reverse.c 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.html https://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.	11 years ago
Yao Qi	1e6697eab9	Move CL entries from gdb/ChangeLog to gdb/testsuite/ChangeLog Two ChangeLog entries in gdb/ChangeLog should be placed in gdb/testsuite/ChangeLog. This patch moves them to the right place.	11 years ago
Marcin Kościelnicki	a4105d04e1	gdbserver/s390: Switch on tracepoint support. 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.	11 years ago
Yao Qi	bfa6adb959	Compile gdb.arch/arm-neon.exp with debug info 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.	11 years ago
Andreas Arnez	64bcd522de	S390: Fix output path for s390-multiarch test case 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.	11 years ago
Don Breazeal	7868401b7b	PR remote/19496, interrupted syscall in forking-threads-plus-bkpt 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.	11 years ago

1 2 3 4 5 ...

5985 Commits (51f77c3704a6e5c28fdcdd6d6e0aeb97ebdb343f)