aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2016-02-11arm-tdep.c: Remove unused arm_displaced_step_copy_insnSimon Marchi4-28/+16
This function is never used, since it is superseded by arm_linux_displaced_step_copy_insn. gdb/ChangeLog: * arm-tdep.c (arm_displaced_step_copy_insn): Remove. (ARM displaced stepping support): Remove reference to arm_displaced_step_copy_insn in comment. * arm-tdep.h (arm_displaced_step_copy_insn): Remove. * arm-linux-tdep.c (arm_linux_displaced_step_copy_insn): Remove reference to arm_displaced_step_copy_insn in comment.
2016-02-11arm-tdep.c: Change type of insn parametersSimon Marchi2-5/+13
Almost obvious... change the type of some insn parameters, so that it matches the rest of the code. gdb/ChangeLog: * arm-tdep.c (thumb_copy_unmodified_16bit): Change type of insn. (thumb_copy_b): Likewise. (arm_decode_b_bl_ldmstm): Likewise. (thumb_copy_16bit_ldr_literal): Likewise. (thumb_copy_pop_pc_16bit): Likewise.
2016-02-11gdb.trace: Add a testcase for tdesc in tfile.Marcin Kościelnicki3-0/+129
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-11Use the target architecture when encoding tracepoint actionsAntoine Tremblay2-6/+11
This patch uses the target architecture rather then the objfile architecture when encoding tracepoint actions. The target architecture may contain additional registers. E.g. ARM VFP registers. This information is needed to allow their collection. Since we can never know whether the registers numbers in the target match the binary's we have to use tdesc here. One note about combined debuggers / multi-inferior from Pedro Alves: In the combined debugger case taking Cell as the practical example that gdb supports currently: In that case, the main target_gdbarch() will be powerpc, but you may have set a tracepoint on _spu_ code, which has a different gdbarch. so for that case, target_gdbarch would be wrong. I think that in that case, we'd need to find __the_ target/tdesc gdbarch that is (bfd) compatible with the objfile's gdbarch. I think cell/spu gdbserver doesn't support tracepoints, so we can ignore this for now. The multi-inferior/process case is somewhat related, but its simpler. each inferior has its own gdbarch. That is, target_gdbarch depends on the current inferior selected. In fact, that just returns inferior->gdbarch nowaways. No regressions, tested on ubuntu 14.04 ARMv7 and x86. With gdbserver-{native,extended} / { -marm -mthumb } gdb/ChangeLog: * tracepoint.c (encode_actions_1): Use target_gdbarch () rather than loc->gdbarch.
2016-02-10gdb.trace: Read XML target description from tfile.Marcin Kościelnicki2-1/+67
gdb/ChangeLog: * tracefile-tfile.c (trace_tdesc): New static variable. (tfile_open): Clear trace_tdesc, call target_find_description. (tfile_interp_line): Recognize tdesc lines. (tfile_close): Clear trace_tdesc. (tfile_xfer_partial_features): New function. (tfile_xfer_partial): Call tfile_xfer_partial_features. (tfile_append_tdesc_line): New function.
2016-02-10gdb.trace: Save XML target description in tfile.Marcin Kościelnicki7-0/+101
gdb/ChangeLog: * ctf.c (ctf_write_tdesc): New function. (ctf_write_ops): Wire in ctf_write_tdesc. * tracefile-tfile.c (tfile_write_tdesc): New function. (tfile_write_ops): Wire in tfile_write_tdesc. * tracefile.c (trace_save): Call write_tdesc method. * tracefile.h (struct trace_file_write_ops): Add write_tdesc method. * xml-tdesc.c (target_fetch_description_xml): New function. * xml-tdesc.h: Add target_fetch_description_xml prototype.
2016-02-10Clear *VAL in regcache_raw_read_unsignedYao Qi2-0/+5
We have function regcache_raw_read_unsigned defined in both GDB and GDBserver, so that it is used in common like this, ULONGEST value; status = regcache_raw_read_unsigned (regcache, regnum, &value); 'value' is correctly set in GDB side, but may not be correctly set in GDBserver, because &value is passed in regcache_raw_read_unsigned but collect_register may only set part of the whole variable. In my test, I see the top half of 'value' is garbage. This patch fixes this problem by clearing *VAL before calling collect_register. gdb/gdbserver: 2016-02-10 Yao Qi <yao.qi@linaro.org> * regcache.c (regcache_raw_read_unsigned): Clear *VAL.
2016-02-10arm-tdep.c: Fix typoSimon Marchi2-3/+8
unpriveleged -> unprivileged gdb/ChangeLog: * arm-tdep.c (arm_copy_extra_ld_st): Fix "unpriveleged" typo. (arm_decode_dp_misc): Likewise.
2016-02-10gdb/x86: Implement ax_pseudo_register_collect hook.Marcin Kościelnicki4-6/+130
Makes "collect $ymm15" action work. gdb/ChangeLog: * amd64-tdep.c (amd64_ax_pseudo_register_collect): New function. (amd64_init_abi): Fill ax_pseudo_register_collect hook. * gdb/i386-tdep.c (i386_pseudo_register_read_into_value): Remove misleading comment. (i386_pseudo_register_write): Ditto. (i386_ax_pseudo_register_collect): New function. (i386_gdbarch_init): Fill ax_pseudo_register_collect hook. * i386-tdep.h: Add i386_ax_pseudo_register_collect prototype.
2016-02-10gdb.trace: Use g packet order in tfile_fetch_registers.Marcin Kościelnicki4-7/+17
tfile_fetch_registers currently wrongly fetches registers using gdb order instead of g packet order. On x86_64 with AVX, this causes problems with ymm*h and orig_rax registers: gdb has ymm*h first, while g packet has orig_rax first. gdb/ChangeLog: * tracefile-tfile.c (tfile_fetch_registers): Use g packet order instead of gdb order. gdb/doc/ChangeLog: * gdb.texinfo (Trace File Format): Remove misleading information about register block ordering.
2016-02-10gdb.trace: Fix off-by-one in tfile_fetch_registers.Marcin Kościelnicki2-1/+6
This resulted in the last register being considered unavailable. On plain x86_64 (without AVX), this happened to be orig_rax. gdb/ChangeLog: * tracefile-tfile.c (tfile_fetch_registers): Fix off-by-one in bounds check.
2016-02-10Update NEWS post GDB 7.11 branch creation.Joel Brobecker2-1/+9
gdb/ChangeLog: * NEWS: Create a new section for the next release branch. Rename the section of the current branch, now that it has been cut.
2016-02-10Bump version to 7.11.50.DATE-git.Joel Brobecker2-1/+6
Now that the GDB 7.11 branch has been created, we can bump the version number. gdb/ChangeLog: GDB 7.11 branch created (9ef9e6a6a0dd8f948708cb67c9afcfd0be40cb0a): * version.in: Bump version to 7.11.50.DATE-git.
2016-02-09breakpoints/19546: Fix crash after updating breakpointsgdb-7.11-branchpointKeith Seitz6-2/+122
One of the last checks update_breakpoints_after_exec does while looping over the list of breakpoints is check that the breakpoint has a valid location spec. It uses event_location_empty_p to check if the location spec is "empty", and if it is, the breakpoint is deleted. momentary_breakpoint types rely on setting the breakpoint structure's location spec to NULL, thereby causing an update to delete the breakpoint. However, event_location_empty_p assumed that locations were never NULL. As a result, GDB would crash dereferencing a NULL pointer whenever update_breakpoints_after_exec would encounter a momentary_breakpoint. This patch creates a new wrapper/helper function which tests that the given breakpoint's location spec is non-NULL and if it is not "empty" or "unspecified." gdb/ChangeLog PR breakpoints/19546 * breakpoint.c (breakpoint_event_location_empty_p): New function. (update_breakpoints_after_exec, bkpt_re_set): Use this new function instead of event_location_empty_p. gdb/testsuite/ChangeLog PR breakpoints/19546 * gdb.base/infcall-exec.c: New file. * gdb.base/infcall-exec2.c: New file. * gdb.base/infcall-exec.exp: New file.
2016-02-09Enable/update legacy linespecs in MI.Keith Seitz2-1/+6
MI is currently using string_to_event_location to enable the use of legacy linespecs, but using this function (until this patchset) had the (as yet unnoticed) side effect of allowing both MI and CLI representation for explicit locations. This patch simply changes MI to use the same legacy linespec functions that the python and guile interpreters use. This eliminates the CLI syntax for explicit locations (in MI). gdb/ChangeLog * mi/mi-cmd-break.c (mi_cmd_break_insert_1): Use string_to_event_location_basic instead of string_to_event_location.
2016-02-09Use string_to_event_location_basic in guile.Keith Seitz4-2/+26
This patch, analogous to the previous python patch, implements proper legacy linespec support in guile code using the newly introduced string_to_event_location_basic. gdb/ChangeLog * guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Skip leading whitespace and use string_to_event_location_basic instead of new_linespec_location. gdb/testsuite/ChangeLog * gdb.guile/scm-breakpoint.exp (test_bkpt_address): New procedure. (toplevel): Call test_bkpt_address.
2016-02-09python/19506 -- gdb.Breakpoint address location regressionKeith Seitz4-2/+48
Now that "legacy" linespecs benefit from consolidated support in string_to_event_location_basic, python's Breakpoint command should use this function to turn strings into event locations. As a result, this patch fixes python/19506. Before: (gdb) python gdb.Breakpoint("*main") Traceback (most recent call last): File "<string>", line 1, in <module> RuntimeError: Function "*main" not defined. Error while executing Python code. After: (gdb) python gdb.Breakpoint("*main") Breakpoint 1 at 0x4005fb: file ../../../src/gdb/testsuite/gdb.python/py-breakpoint.c, line 32. gdb/ChangeLog PR python/19506 * python/py-breakpoint.c (bppy_init): Use string_to_event_location_basic instead of new_linespec_location. gdb/testsuite/ChangeLog PR python/19506 * gdb.python/py-breakpoint.exp (test_bkpt_address): New procedure. (toplevel): Call test_bkpt_address.
2016-02-09Refactor string_to_event_location for legacy linespec support.Keith Seitz3-37/+74
This patch refactors string_to_event_location, breaking it into two separate functions: 1) string_to_event_location_basic A "basic" string parser that implements support for "legacy" linespecs (linespec, address, and probe locations). This function is intended to be used by any UI wishing/needing to support this legacy behavior. 2) string_to_event_location This is now intended as a CLI-only function which adds explicit location parsing in a CLI-appropriate manner (in the form of traditional option/value pairs). Together these patches serve to simplify string-to-event location parsing for all existing non-CLI interfaces (MI, guile, and python). gdb/ChangeLog * location.c (string_to_explicit_location): Note that "-p" is reserved for probe locations and return NULL for any input that starts with that. (string_to_event_location): Move "legacy" linespec code to ... (string_to_event_location_basic): ... here. * location.h (string_to_event_location): Update comment. (string_to_event_location_basic): New function.
2016-02-09Modernize configure.ac'sSimon Marchi9-15/+46
Using AC_OUTPUT with arguments has been deprecated for some time in autoconf, even in version 2.64, which we are using. This change should not affect functionality. I also removed the "exit 0"'s, they shouldn't be necessary. gdb/ChangeLog: * configure.ac: Use AC_CONFIG_FILES instead of passing arguments to AC_OUTPUT. Remove "exit 0" at the end. * configure: Regenerate. gdb/testsuite/ChangeLog: * configure.ac: Use AC_CONFIG_FILES instead of passing arguments to AC_OUTPUT. * configure: Regenerate. gdb/gdbserver/ChangeLog: * configure.ac: Use AC_CONFIG_FILES instead of passing arguments to AC_OUTPUT. * configure: Regenerate.
2016-02-09Fix PR19548: Breakpoint re-set inserts breakpoints when it shouldn'tPedro Alves5-17/+66
PR19548 shows that we still have problems related to 13fd3ff34329: [PR17431: following execs with "breakpoint always-inserted on"] https://sourceware.org/ml/gdb-patches/2014-09/msg00733.html The problem this time is that we currently update the global location list and try to insert breakpoint locations after re-setting _each_ breakpoint in turn. Say: - We have _more_ than one breakpoint set. Let's assume 2. - There's a breakpoint with a pre-exec address that ends up being an unmapped address after the exec. - That breakpoint is NOT the first in the breakpoint list. Then when handling an exec, and we re-set the first breakpoint in the breakpoint list, we mistakently try to install the old pre-exec / un-re-set locations of the other breakpoint, which fails: (gdb) continue Continuing. process 28295 is executing new program: (...)/execl-update-breakpoints2 Error in re-setting breakpoint 1: Warning: Cannot insert breakpoint 2. Cannot access memory at address 0x1000764 Breakpoint 1, main (argc=1, argv=0x7fffffffd368) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/execl-update-breakpoints.c:34 34 len = strlen (argv[0]); (gdb) Fix this by deferring the global location list update till after all breakpoints are re-set. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ChangeLog: 2016-02-09 Pedro Alves <palves@redhat.com> PR breakpoints/19548 * breakpoint.c (create_overlay_event_breakpoint): Don't update global location list here. (create_longjmp_master_breakpoint) (create_std_terminate_master_breakpoint) (create_exception_master_breakpoint, create_jit_event_breakpoint) (update_breakpoint_locations): (breakpoint_re_set): Update global location list after all breakpoints are re-set. gdb/testsuite/ChangeLog: 2016-02-09 Pedro Alves <palves@redhat.com> PR breakpoints/19548 * gdb.base/execl-update-breakpoints.c (some_function): New function. (main): Call it. * gdb.base/execl-update-breakpoints.exp: Add a second breakpoint. Tighten expected GDB output.
2016-02-09Fix siginfo C++ build errorSimon Marchi5-5/+15
Change the signature of gdbserver's siginfo_fixup functions so that it's in line with gdb's. This gets rid of the following build error in C++: /home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c: In function ‘int x86_siginfo_fixup(siginfo_t*, void*, int)’: /home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c:694:21: error: invalid conversion from ‘void*’ to ‘gdb_byte* {aka unsigned char*}’ [-fpermissive] FIXUP_32); ^ In file included from /home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c:31:0: /home/emaisin/src/binutils-gdb/gdb/gdbserver/../nat/amd64-linux-siginfo.h:52:5: error: initializing argument 2 of ‘int amd64_linux_siginfo_fixup_common(siginfo_t*, gdb_byte*, int, amd64_siginfo_fixup_mode)’ [-fpermissive] int amd64_linux_siginfo_fixup_common (siginfo_t *native, gdb_byte *inf, ^ /home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c:698:20: error: invalid conversion from ‘void*’ to ‘gdb_byte* {aka unsigned char*}’ [-fpermissive] FIXUP_X32); ^ In file included from /home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c:31:0: /home/emaisin/src/binutils-gdb/gdb/gdbserver/../nat/amd64-linux-siginfo.h:52:5: error: initializing argument 2 of ‘int amd64_linux_siginfo_fixup_common(siginfo_t*, gdb_byte*, int, amd64_siginfo_fixup_mode)’ [-fpermissive] int amd64_linux_siginfo_fixup_common (siginfo_t *native, gdb_byte *inf, ^ gdb/gdbserver/ChangeLog: * linux-aarch64-low.c (aarch64_linux_siginfo_fixup): Change void * to gdb_byte *. * linux-low.c (siginfo_fixup): Likewise. (linux_xfer_siginfo): Likewise. * linux-low.h (struct linux_target_ops) <siginfo_fixup>: Likewise. * linux-x86-low.c (x86_siginfo_fixup): Likewise.
2016-02-09Revert "Fix build breakage"Walfred Tedeschi2-8/+4
This reverts commit 222cab58b7ed37df6e01dacb0932f400a2588137.
2016-02-09Fix build breakageWalfred Tedeschi2-4/+8
Add a cast to reinterpret a void* as a gdb_byte*. 2016-02-09 Walfred Tedeschi <walfred.tedeschi@intel.com> gdb/gdbserver/ChangeLog: * linux-x86-low.c (x86_siginfo_fixup): Add cast to gdb_byte*.
2016-02-08Always organize test artifacts in a directory hierarchySimon Marchi37-866/+51
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-02-08Fix in-tree, parallel running of Ada testsSimon Marchi2-1/+7
While testing the following patch, [PATCH] Always organize test artifacts in a directory hierarchy https://sourceware.org/ml/gdb-patches/2016-01/msg00133.html I noticed that it broke Ada testing. This lead me to think that parallel testing when building in-tree didn't work previously in Ada. It is confirmed by this test: $ make check TESTS="gdb.ada/fun_addr.exp" -j 2 ... Running ./gdb.ada/fun_addr.exp ... FAIL: gdb.ada/fun_addr.exp: compilation foo.adb ... This patch fixes in-tree parallel testing for Ada, and consequently serial and parallel testing when the aforementioned patch is applied. The problem originates from the fact that Ada support code cd's to the builddir before compiling. In itself it's not a problem, it allows to place intermediate auto-generated files in that directory. The Ada compilation refers to the source file, which is in another directory, only by its base name (e.g. foo.adb). In serial mode, that worked because builddir was the same as the source directory (e.g. gdb.ada/fun_addr/). In an out-of-tree build, it works because the source directory is added as an include directory (note: this is not the same $srcdir as autoconf's): set srcdir [file dirname $source] additional_flags=-I$srcdir which becomes: additional_flags=-I/home/emaisin/build/binutils-gdb/gdb/testsuite/gdb.ada/fun_addr However, when building in-tree, srcdir is relative: ./gdb.ada/fun_addr. When using parallel or always-in-outputs-directory mode, we are cd'ed in the outputs directory. So -I$srcdir is relative to the current directory, which is wrong. To fix it, I made the TCL variable srcdir (set in site.exp, from which everything else is derived) always absolute. It is done by assigning autoconf's abs_srcdir instead of autoconf's srcdir. This way -I$srcdir will always be good, regardless of where we cd'ed to. A small apparent change is that when running tests, DejaGnu will say: Running /tmp/binutils-gdb/gdb/testsuite/gdb.ada/fun_addr.exp ... instead of Running ./gdb.ada/fun_addr.exp ... I hope it's not too much of an annoyance. I think that it should make the testsuite a tiny bit more robust against other bugs of the same class. Regtested in & out of tree, only with native target. gdb/testsuite/ChangeLog: * Makefile.in (abs_srcdir): Assign @abs_srcdir@. (site.exp): Assign abs_srcdir to tcl's srcdir.
2016-02-08remote.c: Cleanup unused variablesSimon Marchi2-35/+25
I built remote.c with -Wunused, to check a function I was working on, turns out there is a bunch of unused variables. gdb/ChangeLog: * remote.c (remote_register_number_and_offset): Remove unused variable(s). (remote_thread_always_alive): Likewise. (remote_update_thread_list): Likewise. (process_initial_stop_replies): Likewise. (remote_start_remote): Likewise. (remote_check_symbols): Likewise. (discard_pending_stop_replies): Likewise. (process_stop_reply): Likewise. (putpkt_binary): Likewise. (getpkt): Likewise. (remote_add_target_side_condition): Likewise. (remote_insert_breakpoint): Likewise. (remote_supports_stopped_by_sw_breakpoint): Likewise. (remote_supports_stopped_by_hw_breakpoint): Likewise. (remote_xfer_partial): Likewise. (remote_read_btrace): Likewise. (remote_async_serial_handler): Likewise. (remote_thread_events): Likewise. (_initialize_remote): Likewise.
2016-02-07varobj: Cleanup dead codeSimon Marchi4-104/+39
This patch removes some dead code. I noticed that varobj_delete was always called with dellist == NULL, so I started removing that parameter. That allows removing a good chunk of the code in varobj_delete, making it almost trivial. We can also remove the resultp parameters in that whole trail. In turn, this shows that struct cpstack, cppush and cppop were only used fo that mechanism, so they can be removed as well. I also moved the function comment to the header file to comply with today's guideline, even though the rest of the file does not respect it (yet). gdb/ChangeLog: * varobj.h (varobj_delete): Remove dellist parameter, update and move documentation here. * varobj.c (struct cpstack, cppush, cppop): Remove. (delete_variable): Remove resultp (first) parameter. (delete_variable_1): Likewise. (varobj_delete): Remove dellist parameter and unused code. (update_dynamic_varobj_children): Adjust varobj_delete call. (update_type_if_necessary): Likewise. (varobj_set_visualizer): Likewise. (varobj_update): Likewise. (value_of_root): Likewise. (varobj_invalidate_iter): Likewise. * mi/mi-cmd-var.c (mi_cmd_var_delete): Likewise.
2016-02-04[testsuite] Remove BASEDIRYao Qi12-39/+130
BASEDIR was added by https://sourceware.org/ml/gdb-patches/2013-10/msg00587.html in order to handle the different directory layout in serial testing and parallel testing. BASEDIR is "gdb.base" in serial testing and is "outputs/gdb.base/TESTNAME" in parallel testing. However, it doesn't work if the GDBserver is in remote target, like this, $ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost foll-vfork.exp foll-exec.exp' FAIL: gdb.base/foll-exec.exp: continue to first exec catchpoint (the program exited) FAIL: gdb.base/foll-vfork.exp: exec: vfork and exec child follow, to main bp: continue to bp (the program exited) FAIL: gdb.base/foll-vfork.exp: exec: vfork child follow, finish after tcatch vfork: finish (the program exited) FAIL: gdb.base/foll-vfork.exp: exec: vfork relations in info inferiors: continue to bp (the program exited) these tests fail because the executable can't be found. With target board native-gdbserver, the program is spawned this way, spawn ../gdbserver/gdbserver --once :2347 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.base/foll-vfork so BASEDIR is correct. However, with target board remote-gdbserver-on-localhost, the program is spawned spawn /usr/bin/ssh -l yao localhost /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../gdbserver/gdbserver --once :2346 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.base/foll-vfork so BASEDIR (either "gdb.base" or "outputs/gdb.base/TESTNAME") makes no sense. I had a fix that pass absolute directory to BASEDIR, but it assumes that directory structure is the same on build and target, and it doesn't work in remote host case. The current fix in this patch is to get the directory from argv[0]. In any case, the program to be exec'ed is at the same directory with the main program. Note that these tests do "next N" to let program stop at the desired line, but it is fragile, because GDB for different targets may skip function prologue slightly differently, so I replace some of them by "tbreak on LINE NUMBER and continue". gdb/testsuite: 2016-02-04 Yao Qi <yao.qi@linaro.org> * gdb.base/foll-exec-mode.c: Include limits.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.base/foll-exec-mode.exp: Don't pass -DBASEDIR in compilation. * gdb.base/foll-exec.c: Include limits.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.base/foll-exec.exp: Don't pass -DBASEDIR in compilation. Adjust tests on the number of lines as source code changed. * gdb.base/foll-vfork-exit.c: Include limits.h. (main): Add one line of statement before vfork. * gdb.base/foll-vfork.c: Include limits.h and string.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.base/foll-vfork.exp: Don't pass -DBASEDIR in compilation. (setup_gdb): Set tbreak to skip some source lines. * gdb.multi/bkpt-multi-exec.c: Include limits.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.multi/bkpt-multi-exec.exp: Don't pass -DBASEDIR in compilation. * gdb.multi/multi-arch-exec.c: Include limits.h and string.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.multi/multi-arch-exec.exp: Don't pass -DBASEDIR in compilation.
2016-02-04waiting_for_stop_reply around remote_fileio_requestYao Qi2-0/+13
Hi, I see this error when GDB connects with qemu, (gdb) n .... Sending packet: $vCont;c#a8...Ack Packet received: Ffstat,00000001,f6fff038 Cannot execute this command while the target is running. Use the "interrupt" command to stop the target and then try again. looks we don't set rs->waiting_for_stop_reply to zero before handle fileio request, #10 0x00000000005edb64 in target_write (len=64, offset=4143968312, buf=0x7fffffffd570 "\375\377\377\377", annex=0x0, object=TARGET_OBJECT_MEMORY, ops=<optimised out>) at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:1922 #11 target_write_memory (memaddr=memaddr@entry=4143968312, myaddr=myaddr@entry=0x7fffffffd6a0 "", len=len@entry=64) at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:1500 #12 0x00000000004b2b41 in remote_fileio_func_fstat (buf=0x127b258 "") at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1037 #13 0x00000000004b1878 in do_remote_fileio_request (uiout=<optimised out>, buf_arg=buf_arg@entry=0x127b240) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1204 #14 0x00000000005b8c7c in catch_exceptions_with_msg (func_uiout=<optimised out>, func=func@entry=0x4b1800 <do_remote_fileio_request>, func_args=func_args@entry=0x127b240, gdberrmsg=gdberrmsg@entry=0x0, mask=mask@entry=RETURN_MASK_ALL) at /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:187 #15 0x00000000005b8dea in catch_exceptions (uiout=<optimised out>, func=func@entry=0x4b1800 <do_remote_fileio_request>, func_args=func_args@entry=0x127b240, mask=mask@entry=RETURN_MASK_ALL) at /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:167 #16 0x00000000004b2fff in remote_fileio_request (buf=0x127b240 "Xf6fff038,0:", ctrlc_pending_p=0) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1255 #17 0x0000000000496f12 in remote_wait_as (ptid=..., status=0x7fffffffdb20, options=1) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:6997 however, we did set rs->waiting_for_stop_reply to zero before Luis's patch https://sourceware.org/ml/gdb-patches/2015-10/msg00336.html In fact, Luis's patch v1 https://sourceware.org/ml/gdb-patches/2015-08/msg00809.html is about setting rs->waiting_for_stop_reply back to one after remote_fileio_request, which is correct. However during the review, the patch is changed and ends up with "not setting rs->waiting_for_stop_reply to zero". I manually test GDB, but I don't have a way to run regression tests. gdb: 2016-02-04 Yao Qi <yao.qi@linaro.org> * remote.c (remote_wait_as): Set rs->waiting_for_stop_reply to 0 before handling 'F' and set it back afterwards.
2016-02-02ui-out.c: Remove unused enumSimon Marchi2-6/+4
This is unused since 54eb231c4bca046e8b8cd73461f695e02c5620d5, where static arrays of ui_out_levels were replaced with vectors. gdb/ChangeLog: * ui-out.c (MAX_UI_OUT_LEVELS): Remove.
2016-02-02Adaptation of siginfo fixup for the new bnd fieldsWalfred Tedeschi3-102/+240
New bnds fields will be always present for x86 architecture. Fixup for compatibility layer 32bits has to be fixed. It was added the nat_siginfo to serving as intermediate step between kernel provided siginfo and the fix up routine. When executing compat_siginfo_from_siginfo or compat_x32_siginfo_from_siginfo first the buffer read from the kernel are converted into the nat_signfo for homogenization, then the fields of nat_siginfo are use to set the compat and compat_x32 siginfo fields. In other to make this conversion independent of the system where gdb is compiled the most complete version of the siginfo, named as native siginfo, is used internally as an intermediate step. Conversion using nat_siginfo is exemplified below: compat_siginfo_from_siginfo or compat_x32_siginfo_from_siginfo: buffer (from the kernel) -> nat_siginfo -> 32 / X32 siginfo (memcpy) (field by field) siginfo_from_compat_x32_siginfo or siginfo_from_compat_siginfo: 32 / X32 siginfo -> nat_siginfo -> buffer (to the kernel) (field by field) (memcpy) Caveat: No support for MPX on x32. 2016-02-02 Walfred Tedeschi <walfred.tedeschi@intel.com> gdb/ChangeLog: * amd64-linux-siginfo.c (nat_siginfo_t, nat_sigval_t, nat_timeval): New types. (compat_siginfo): New bound fields added. (compat_x32_siginfo): New field added. (cpt_si_addr_lsb): New define. (compat_siginfo_from_siginfo): Use nat_siginfo. (siginfo_from_compat_siginfo): Use nat_siginfo. (compat_x32_siginfo_from_siginfo): Likewise. (siginfo_from_compat_x32_siginfo): Likewise.
2016-02-02Add bound related fields to the siginfo structureWalfred Tedeschi2-2/+21
Both Linux and glibc have introduced bound related fields in the segmentation fault fields of the siginfo_t type. Add the new fields to our x86's siginfo_t type too. Kernel patch: http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=ee1b58d36aa1b5a79eaba11f5c3633c88231da83 Glibc patch: http://repo.or.cz/w/glibc.git/commit/d4358b51c26a634eb885955aea06cad26af6f696 2016-02-02 Walfred Tedeschi <walfred.tedeschi@intel.com> gdb/ChangeLog: * linux-tdep.c (linux_get_siginfo_type): Add the _addr_bnd structure to the siginfo if extra_fields contains LINUX_SIGINFO_FIELD_ADDR_BND.
2016-02-02Use linux_get_siginfo_type_with_fields for x86Walfred Tedeschi6-3/+34
Use linux_get_siginfo_type_with_fields for adding bound fields on segmentation fault for i386/amd64 siginfo. 2016-02-02 Walfred Tedeschi <walfred.tedeschi@intel.com> gdb/ChangeLog: * linux-tdep.h (linux_get_siginfo_type_with_fields): Make extern. * linux-tdep.c (linux_get_siginfo_type_with_fields): Make extern. * i386-linux-tdep.h (x86_linux_get_siginfo_type): New function. * amd64-linux-tdep.c (amd64_linux_init_abi_common): Add x86_linux_get_siginfo_type for the amd64 abi. * i386-linux-tdep.c (x86_linux_get_siginfo_type): New function. (i386_linux_init_abi): Add new function at the i386 ABI initialization.
2016-02-02Preparation for new siginfo on LinuxWalfred Tedeschi3-3/+32
First add new structure and function to allow architecture customization for the siginfo structure. 2016-01-15 Walfred Tedeschi <walfred.tedeschi@intel.com> gdb/ChangeLog: * linux-tdep.h (linux_siginfo_extra_field_values): New enum values. (linux_siginfo_extra_fields): New enum type. * linux-tdep.c (linux_get_siginfo_type_with_fields): New function. (linux_get_siginfo_type): Use new function.
2016-02-02Merge gdb and gdbserver implementations for siginfoWalfred Tedeschi10-844/+563
Extract the compatible siginfo handling from amd64-linux-nat.c and gdbserver/linux-x86-low to a new file nat/amd64-linux-siginfo.c. 2016-02-02 Walfred Tedeschi <walfred.tedeschi@intel.com> gdb/ChangeLog: * nat/amd64-linux-siginfo.c: New file. * nat/amd64-linux-siginfo.h: New file. * Makefile.in (HFILES_NO_SRCDIR): Add nat/amd64-linux-siginfo.h. (amd64-linux-siginfo.o): New rule. * config/i386/linux64.mh (NATDEPFILES): Add amd64-linux-siginfo.o. * amd64-linux-nat.c (nat/amd64-linux-siginfo.h): New include. (compat_siginfo_from_siginfo, siginfo_from_compat_siginfo) (compat_x32_siginfo_from_siginfo, siginfo_from_compat_x32_siginfo) (compat_timeval, compat_sigval, compat_x32_clock, cpt_si_pid) (cpt_si_uid, cpt_si_timerid, cpt_si_overrun, cpt_si_status) (cpt_si_utime, cpt_si_stime, cpt_si_ptr, cpt_si_addr, cpt_si_band) (cpt_si_fd, si_timerid, si_overrun): Move to nat/amd64-linux-siginfo.c. gdb/gdbserver/ChangeLog: * configure.srv (x86_64-*-linux*): Add amd64-linux-siginfo.o to srv_tgtobj. (i[34567]86-*-linux*): Add amd64-linux-siginfo.o to srv_tgtobj. * linux-x86-low.c [__x86_64__]: Include "nat/amd64-linux-siginfo.h". (compat_siginfo_from_siginfo, siginfo_from_compat_siginfo) (compat_x32_siginfo_from_siginfo, siginfo_from_compat_x32_siginfo) (compat_timeval, compat_sigval, compat_x32_clock, cpt_si_pid) (cpt_si_uid, cpt_si_timerid, cpt_si_overrun, cpt_si_status) (cpt_si_utime, cpt_si_stime, cpt_si_ptr, cpt_si_addr, cpt_si_band) (cpt_si_fd, si_timerid, si_overrun): Move from nat/amd64-linux-siginfo.c. * Makefile.in (amd64-linux-siginfo.o:): New rule.
2016-02-01gdb.texinfo (Value Sizes): Fix typo.Doug Evans2-1/+5
2016-02-01gdb.texinfo (Skipping Over Functions and Files): Fix typo.Doug Evans2-1/+5
2016-02-01gdb.base/skip.exp: Clean up multiple references to same test name.Doug Evans2-11/+18
2016-02-01Mention PR remote/19496 in gdb/testsuite/ChangeLog entryPedro Alves1-0/+1
2016-02-01Test gdb.threads/forking-threads-plus-breakpoint.exp with displaced stepping offPedro Alves2-5/+67
This exposes the internal error Don mentioned in PR19496: (1) internal error -- gdb/target.c:2713: internal-error: Can't determine the current address space of thread More analysis here: https://sourceware.org/ml/gdb-patches/2016-01/msg00685.html The (now kfailed) internal error looks like: continue & Continuing. (gdb) PASS: gdb.threads/forking-threads-plus-breakpoint.exp: cond_bp_target=1: detach_on_fork=on: displaced=off: continue & [New Thread 2846.2847] (...) [New Thread 2867.2867] /home/pedro/gdb/mygit/src/gdb/target.c:2723: internal-error: Can't determine the current address space of thread Thread 2846.2846 A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) KFAIL: gdb.threads/forking-threads-plus-breakpoint.exp: cond_bp_target=1: detach_on_fork=on: displaced=off: inferior 1 exited (GDB internal error) (PRMS: remote/19496) Resyncing due to internal error. gdb/testsuite/ChangeLog: 2016-02-01 Pedro Alves <palves@redhat.com> PR remote/19496 * gdb.threads/forking-threads-plus-breakpoint.exp (displaced_stepping_supported): New global. (probe_displaced_stepping_support): New procedure. (do_test): Add 'displaced' parameter, and use it. (top level): Check for displaced stepping support. Add displaced stepping on/off testing axis.
2016-02-01gdb: Guard against undefined behaviour in mi-vla-fortran.expAndrew Burgess2-16/+38
The test gdb.mi/mi-vla-fortran.exp reveals an issue with the DWARF generated by gfortran. In the test a pointer variable 'pvla2' is created: real, pointer :: pvla2 (:, :) Initially this variable will be unassociated, so something like this: l = associated(pvla2) should return false. In the test gdb stops at a point _before_ pvla2 is associated with anything, and we then try to print pvla2, the expectation is that gdb should reply <not associated>. The problem is that the data the DWARF directs gdb to read (to identify if the variable is associated or not) is not initialised until the first time pvla2 is accessed. As a result gdb ends up reading uninitialised memory, sometimes this uninitialised memory indicates the variable is associated (when it's not). This first mistake can lead to a cascade of errors, reading uninitialised memory, with the result that gdb builds an invalid type to associate with the variable pvla2. In some cases, this invalid type can be very large, which when we try to print pvla2 causes gdb to allocate a large amount of memory. A recent commit added a new gdb variable 'max-value-size', which prevents gdb from allocating values of extreme size. As a result directly trying to print pvla2 will now now error rather than allocate a large amount of memory. However, some of the later tests create a varobj for pvla2, and then ask for the children of that varobj to be displayed. In the case where an invalid type has been computed for pvla2 then the number of children can be wrong, and very big, in which case trying to display all of these children can cause gdb to consume an excessive amount of memory. This commit first detects if printing pvla2 triggers the max-value-size error, if it does then we avoid all the follow on tests relating to the unassociated pvla2, which avoids the second error printing the varobj children. gdb/testsuite/ChangeLog: * gdb.mi/mi-vla-fortran.exp: Add XFAIL for accessing unassociated pointer. Don't perform further tests on the unassociated pointer if the first test fails.
2016-02-01gdb: New set/show max-value-size command.Andrew Burgess9-4/+289
For languages with dynamic types, an incorrect program, or uninitialised variables within a program, could result in an incorrect, overly large type being associated with a value. Currently, attempting to print such a variable will result in gdb trying to allocate an overly large buffer. If this large memory allocation fails then the result can be gdb either terminating, or (due to memory contention) becoming unresponsive for the user. A new user visible variable in gdb helps guard against such problems, two new commands are available: set max-value-size show max-value-size The 'max-value-size' is the maximum size of memory in bytes that gdb will allocate for the contents of a value. Any attempt to allocate a value with a size greater than this will result in an error. The initial default for this limit is set at 64k, this is based on a similar limit that exists within the ada specific code. It is possible for the user to set max-value-size to unlimited, in which case the old behaviour is restored. gdb/ChangeLog: * value.c (max_value_size): New variable. (MIN_VALUE_FOR_MAX_VALUE_SIZE): New define. (show_max_value_size): New function. (check_type_length_before_alloc): New function. (allocate_value_contents): Call check_type_length_before_alloc. (set_value_enclosing_type): Likewise. (_initialize_values): Add set/show handler for max-value-size. * NEWS: Mention new set/show command. gdb/doc/ChangeLog: * gdb.texinfo (Value Sizes): New section. (Data): Add the 'Value Sizes' node to the menu. gdb/testsuite/ChangeLog: * gdb.base/max-value-size.c: New file. * gdb.base/max-value-size.exp: New file. * gdb.base/huge.exp: Disable max-value-size for this test.
2016-01-31Fix some comments in varobj.{c,h}Simon Marchi3-6/+13
A few typos. The comment about varobj_create has been misplaced since the dawn of time. gdb/ChangeLog: * varobj.h (struct varobj): Fix typos in comments. (struct lang_varobj_ops): Likewise. * varobj.c (VAROBJ_TABLE_SIZE): Likewise. (varobj_create): Move misplaced comment.
2016-01-29Fix two misleading indentation warningsSimon Marchi3-16/+23
Two small changes so everything builds with latest GCC and its -Wmisleading-indentation. In the aarch64-tdep.c case, the two misindented lines should actually be part of the for loop. It looks like the indentation is all done using spaces in that file though... I fixed it (changed for tabs + spaces) for the lines I touched. In the xcoffread.c case, we can simply remove the braces and fix the indentation. gdb/ChangeLog: * aarch64-tdep.c (aarch64_record_asimd_load_store): Add braces to for include additional lines. * xcoffread.c (scan_xcoff_symtab): Remove unnecessary braces.
2016-01-28Add ChangeLog entry for update to gdb.dlang demangle tests.Iain Buclaw1-0/+4
2016-01-28Align dlang demangle tests with libiberty.Iain Buclaw1-15/+18
gdb/testsuite/ChangeLog: * gdb.dlang/demangle.exp: Sync tests from libiberty testsuite.
2016-01-28Add rawmemchr to imported gnulib modulesSimon Marchi5-3/+12
rawmemchr is a dependency of strchrnul, so it should be explicitly listed. gdb/ChangeLog: * gnulib/import/Makefile.am: Regenerate. * gnulib/import/Makefile.in: Regenerate. * gnulib/import/m4/gnulib-cache.m4: Regenerate. * gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add rawmemchr.
2016-01-28Import strchrnul from gnulib and use itSimon Marchi18-42/+639
For a forthcoming patch, I need a "skip_to_colon" function. I noticed there are two skip_to_semicolon (one in gdb and one in gdbserver). I thought we could put it in common/, and generalize it for any character. It turns out that the strchrnul function does exactly that. I imported the corresponding module from gnulib, for those systems that do not have it. There are probably more places where this function can be used instead of doing the work by hand (I am looking at remote-utils.c::look_up_one_symbol). gdb/ChangeLog: * remote.c (skip_to_semicolon): Remove. (remote_parse_stop_reply): Use strchrnul instead of skip_to_semicolon. * gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add strchrnul. * gnulib/aclocal.m4: Regenerate. * gnulib/config.in: Regenerate. * gnulib/configure: Regenerate. * gnulib/import/Makefile.am: Regenerate. * gnulib/import/Makefile.in: Regenerate. * gnulib/import/m4/gnulib-cache.m4: Regenerate. * gnulib/import/m4/gnulib-comp.m4: Regenerate. * gnulib/import/m4/rawmemchr.m4: New file. * gnulib/import/m4/strchrnul.m4: New file. * gnulib/import/rawmemchr.c: New file. * gnulib/import/rawmemchr.valgrind: New file. * gnulib/import/strchrnul.c: New file. * gnulib/import/strchrnul.valgrind: New file. gdb/gdbserver/ChangeLog: * server.c (skip_to_semicolon): Remove. (process_point_options): Use strchrnul instead of skip_to_semicolon.
2016-01-28[testsuite] Fix tiemout fail in gdb.fortran/vla-value.expYao Qi2-3/+17
In vla.f90, this single line of source is compiled to many instructions, vla2(:, :, :) = 1311 ! vla2-allocated it is quite slow (about several minutes in my testing) to step over this source line without range stepping. This patch is to increase the timeout value by 15 times, which is a magic number to make sure timeout disappears in my testing with a slow arm-linux board. gdb/testsuite: 2016-01-28 Yao Qi <yao.qi@linaro.org> * gdb.fortran/vla-value.exp: Wrap test with with_timeout_factor.
2016-01-28Fix GDB crash in dprintf.expYao Qi2-9/+6
I see GDB crashes in dprintf.exp on aarch64-linux testing, (gdb) PASS: gdb.base/dprintf.exp: agent: break 29 set dprintf-style agent^M (gdb) PASS: gdb.base/dprintf.exp: agent: set dprintf style to agent continue^M Continuing. ASAN:SIGSEGV ================================================================= ==22475==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x000000494820 sp 0x7fff389b83a0 bp 0x62d000082417 T0) #0 0x49481f in remote_add_target_side_commands /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:9190^M #1 0x49e576 in remote_add_target_side_commands /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:9174^M #2 0x49e576 in remote_insert_breakpoint /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:9240^M #3 0x5278b7 in insert_bp_location /home/yao/SourceCode/gnu/gdb/git/gdb/breakpoint.c:2734^M #4 0x52ac09 in insert_breakpoint_locations /home/yao/SourceCode/gnu/gdb/git/gdb/breakpoint.c:3159^M #5 0x52ac09 in update_global_location_list /home/yao/SourceCode/gnu/gdb/git/gdb/breakpoint.c:12686 the root cause of this problem in this case is about linespec and symtab which produces additional incorrect location and a NULL is added to bp_tgt->tcommands. I posted a patch https://sourceware.org/ml/gdb-patches/2015-12/msg00321.html to fix it in linespec (the fix causes regression), but GDB still shouldn't add NULL into bp_tgt->tcommands. The logic of build_target_command_list looks odd to me. If we get something wrong in parse_cmd_to_aexpr (it returns NULL), we shouldn't continue, instead we should set flag null_command_or_parse_error. This is what this patch does. In the meantime, we find build_target_condition_list has the same problem, so fix it too. gdb: 2016-01-28 Yao Qi <yao.qi@linaro.org> * breakpoint.c (build_target_command_list): Don't call continue if aexpr is NULL. (build_target_condition_list): Likewise.