aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2016-05-03Fix "-Wl,--dynamic-list" gdb/configure testPedro Alves3-2/+14
The -Wl,--dynamic-list test is currently broken on Fedora 23, when you configure with --with-python=python3.4. We see: configure:13741: checking for the dynamic export flag configure:13796: gcc -o conftest -g3 -O0 -fno-strict-aliasing -DNDEBUG -fwrapv -Wl,--dynamic-list=/home/pedro/gdb/mygit/src/gdb/proc-service.list conftest.c -ldl -lncurses -lm -ldl -lpthread -ldl -lutil -lm -lpython3.4m -Xlinker -export-dynamic >&5 conftest.c:182:30: fatal error: python3.4/Python.h: No such file or directory compilation terminated. configure:13796: $? = 1 The correct -I path is in PYTHON_CPPFLAGS: PYTHON_CPPFLAGS='-I/usr/include/python3.4m -I/usr/include/python3.4m' (Other Python-related tests in the file are already doing this.) gdb/ChangeLog: 2016-05-03 Pedro Alves <palves@redhat.com> * configure.ac (checking for the dynamic export flag): Add $PYTHON_CPPFLAGS to CPPFLAGS. * configure: Regenerate.
2016-05-03[gdb] Fix -Wparentheses warningsKyrylo Tkachov2-37/+50
2016-05-03 Kyrylo Tkachov <kyrylo.tkachov@arm.com> * symfile.c (find_pc_overlay): Add braces to avoid -Wparentheses warning. (find_pc_mapped_section): Likewise. (list_overlays_command): Likewise.
2016-05-02Fix detach.exp remote checkSimon Marchi2-5/+4
This test seems to work with both native-gdbserver and native-extended-gdbserver, so I removed the remote check. When running with native-gdbserver (a stub-like target), detach makes gdbserver stop and gdb disconnect. runto_main just spawns a brand new gdbserver. So it tests the exact same thing twice. It doesn't hurt though. With native-extended-gdbserver, the test is probably a bit more useful (and similar to native). It tests running/detaching twice using the same gdb/gdbserver instances, since with extended-remote, you can detach/attach/run all you want, unlike with remote. gdb/testsuite/ChangeLog: * gdb.base/detach.exp: Remove is_remote check.
2016-05-02Fix annota-input-while-running.exp remote checkSimon Marchi2-19/+12
The comment says that we can't use runto_main here becore it doesn't know how to handle annotation. Instead, the test puts a breakpoint at main and calls run by hand. Therefore, it can't work with stub targets, since they can't "run". The check should be then changed to check the use_gdb_stub variable instead of [is_remote target]. But as an alternative, we can just use runto_main and enable annotations after, since the "run to main" part is not really part of what we want to test. I also removed the "set test..." line that is unused. gdb/testsuite/ChangeLog: * gdb.base/annota-input-while-running.exp: Don't check for [is_remote target]. Enable annotations after running to main. Remove unused "set test..." line.
2016-05-02Fix startup on MS-Windows when 'gdb.ini' is found in $HOMEEli Zaretskii2-3/+11
* windows-nat.c (_initialize_check_for_gdb_ini): Fix off-by-one error in allocation of space for "$HOME/.gdbinit" string. This caused GDB to abort on startup whenever a '~/gdb.ini' file was actually found, because xsnprintf would hit an assertion violation.
2016-04-28Don't show deprecated commands in helpSimon Marchi2-1/+9
Just like completion doesn't show deprecated commands, I think that help should not list them, so that we don't incite users to use them. gdb/ChangeLog: * cli/cli-decode.c (help_cmd_list): Do not list commands that are deprecated.
2016-04-28Add test for tracepoint enable/disableSimon Marchi3-0/+171
This patch adds a test for tracepoints enabling/disabling, which didn't work properly for fast tracepoints on big endian systems. gdb/testsuite/ChangeLog: * gdb.trace/trace-enable-disable.exp: New file. * gdb.trace/trace-enable-disable.c: New file.
2016-04-28Fix write endianness/size problem for fast tracepoint enabled flagPar Olsson2-1/+14
I am sending this fix on behalf of Par Olsson, as a follow-up of this one: https://www.sourceware.org/ml/gdb-patches/2015-10/msg00196.html This problem is exposed when enabling/disabling fast tracepoints on big endian machines. The flag is defined as an int8_t, but is written from gdbserver as an integer (usually 32 bits). When the agent code reads it as an int8_t, it only considers the most significant byte, which is always 0. Also, we were writing 32 bits in an 8 bits field, so the write would overflow, but since the following bytes are padding (the next field is an uint64_t), it luckily didn't cause any issue on little endian systems. The fix was originally tested on ARM big endian systems, but I don't have access to such a system. However, thanks to Marcin's PowerPC fast tracepoint patches and gcc110 (big endian Power7) on the gcc compile farm, I was able to reproduce the problem, test the fix and write a test (the following patch). gdb/gdbserver/ChangeLog: YYYY-MM-DD Par Olsson <par.olsson@windriver.com> * tracepoint.c (write_inferior_int8): New function. (cmd_qtenable_disable): Write enable flag using write_inferior_int8.
2016-04-28ftrace tests: Use gdb_load_shlib result to lookup IPA in info sharedlibrarySimon Marchi8-14/+25
Some fast tracepoints tests make sure that the in-process agent library is properly loaded, by searching for the library name in "info sharedlibrary". Originally, it would search for the full path. Since patch "Make ftrace tests work with remote targets" [1], the "runtime" location of the IPA, in the standard output directory, is not the same as the original location, in the gdbserver build directory. Therefore, the patch changed the checks: gdb_test "info sharedlibrary" ".*${libipa}.*" "IPA loaded" to gdb_test "info sharedlibrary" ".*[file tail ${libipa}].*" "IPA loaded" so that only the "libinproctrace.so" part would be searched for. Antoine (in CC) pointed out that I missed some, so I have to update them. In the mean time, I noticed that I missed a few test failures: adding the SONAME to the IPA makes it possible for the test executable to erroneously pick up libinproctrace.so from /usr/lib if the test harness failed to put the libinproctrace.so we want to test in the right place. To mitigate that kind of error in the future, we can use the return value of gdb_load_shlib (the path of the "runtime" version of the library) and use that to search in the output of info sharedlibrary. When testing locally, gdb_load_shlib returns the full normalized path of the destination library, which the test executable should use e.g.: /path/to/gdb/testsuite/outputs/gdb.trace/thetest/libinproctrace.so My testing showed that it was the same path that gdb displayed in info sharedlibrary. If the test executable picks up another libinproctrace.so, the test will fail. When testing remotely, gdb_load_shlib/gdb_remote_download only returns us "libinproctrace.so", so the situation doesn't really change. If there is a rogue libinproctrace.so in /usr/lib on the target and we fail to download ours, it might cover up a test failure. But that situation is probably still better than the original one, where it wasn't possible to test remotely using the IPA at all. [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=6e774b13c3b81ac2599812adf058796948ce7e95 gdb/testsuite/ChangeLog: * gdb.arch/ftrace-insn-reloc.exp: Save gdb_load_shlib result, use it in info sharedlibrary test. * gdb.trace/ftrace-lock.exp: Likewise. * gdb.trace/ftrace.exp: Likewise. * gdb.trace/range-stepping.exp: Likewise. * gdb.trace/trace-break.exp: Likewise. * gdb.trace/trace-condition.exp: Likewise. * gdb.trace/trace-mt.exp: Likewise.
2016-04-28Remove need_step_over from struct lwp_infoYao Qi2-20/+0
Hi, I happen to see that field need_step_over in struct lwp_info is only used to print a debug info. need_step_over is set in linux_wait_1 when breakpoint_here is true, however, we check breakpoint_here too in need_step_over_p and do the step over. I think we don't need field need_step_over, and check breakpoint_here directly in need_step_over_p. This field was added in this patch https://sourceware.org/ml/gdb-patches/2010-03/msg00605.html and the code wasn't changed much since then. This patch is to remove it. gdb/gdbserver: 2016-04-28 Yao Qi <yao.qi@linaro.org> * linux-low.h (struct lwp_info) <need_step_over>: Remove. * linux-low.c (linux_wait_1): Update. (need_step_over_p): Likewise.
2016-04-27Rename gdb_load_shlibs to gdb_load_shlibSimon Marchi54-85/+147
Rename gdb_load_shlibs to gdb_load_shlib to reflect that it can only load a single shlib at the time. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_load_shlibs): Rename to... (gdb_load_shlib): ... this. * gdb.arch/ftrace-insn-reloc.exp: Adjust gdb_load_shlibs -> gdb_load_shlib. * gdb.base/catch-load.exp (one_catch_load_test): Likewise. * gdb.base/ctxobj.exp: Likewise. * gdb.base/dprintf-pending.exp: Likewise. * gdb.base/dso2dso.exp: Likewise. * gdb.base/fixsection.exp: Likewise. * gdb.base/gcore-relro.exp: Likewise. * gdb.base/gdb1555.exp: Likewise. * gdb.base/global-var-nested-by-dso.exp: Likewise. * gdb.base/gnu-ifunc.exp: Likewise. * gdb.base/hbreak-in-shr-unsupported.exp: Likewise. * gdb.base/jit-so.exp (one_jit_test): Likewise. * gdb.base/pending.exp: Likewise. * gdb.base/print-file-var.exp: Likewise. * gdb.base/print-symbol-loading.exp: Likewise. * gdb.base/shlib-call.exp: Likewise. * gdb.base/shreloc.exp: Likewise. * gdb.base/so-impl-ld.exp: Likewise. * gdb.base/solib-disc.exp: Likewise. * gdb.base/solib-nodir.exp: Likewise. * gdb.base/solib-overlap.exp: Likewise. * gdb.base/solib-symbol.exp: Likewise. * gdb.base/solib-weak.exp (do_test): Likewise. * gdb.base/sym-file.exp: Likewise. * gdb.base/symtab-search-order.exp: Likewise. * gdb.base/type-opaque.exp: Likewise. * gdb.base/unload.exp: Likewise. * gdb.base/watchpoint-solib.exp: Likewise. * gdb.compile/compile.exp: Likewise. * gdb.cp/gdb2384.exp: Likewise. * gdb.cp/infcall-dlopen.exp: Likewise. * gdb.cp/re-set-overloaded.exp: Likewise. * gdb.fortran/library-module.exp: Likewise. * gdb.opt/solib-intra-step.exp: Likewise. * gdb.python/py-finish-breakpoint.exp: Likewise. * gdb.python/py-shared.exp: Likewise. * gdb.reverse/solib-precsave.exp: Likewise. * gdb.reverse/solib-reverse.exp: Likewise. * gdb.server/solib-list.exp: Likewise. * gdb.threads/dlopen-libpthread.exp: Likewise. * gdb.threads/tls-shared.exp: Likewise. * gdb.threads/tls-so_extern.exp: Likewise. * gdb.trace/change-loc.exp: Likewise. * gdb.trace/ftrace-lock.exp: Likewise. * gdb.trace/ftrace.exp: Likewise. * gdb.trace/mi-tracepoint-changed.exp (test_reconnect): Likewise. * gdb.trace/pending.exp: Likewise. * gdb.trace/range-stepping.exp: Likewise. * gdb.trace/strace.exp (strace_remove_socket): Likewise. (strace_info_marker): Likewise. (strace_probe_marker): Likewise. (strace_trace_on_same_addr): Likewise. (strace_trace_on_diff_addr): Likewise. * gdb.trace/trace-break.exp: Likewise. * gdb.trace/trace-condition.exp: Likewise. * gdb.trace/trace-mt.exp: Likewise.
2016-04-27Make gdb_load_shlibs return the destination path of the librarySimon Marchi11-15/+38
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.
2016-04-27Workaround gdbserver<7.7 for setfsJan Kratochvil2-0/+23
With current FSF GDB HEAD and old FSF gdbserver I expected I could do: gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234' (supplying that unsupported qXfer:exec-file:read by "file") But that does not work because: Sending packet: $vFile:setfs:0#bf...Packet received: OK Packet vFile:setfs (hostio-setfs) is supported ... Sending packet: $vFile:setfs:104#24...Packet received: OK "target:/root/redhat/threadit": could not open as an executable file: Invalid argument GDB documentation says: The valid responses to Host I/O packets are: An empty response indicates that this operation is not recognized. This "empty response" vs. "OK" was a bug in gdbserver < 7.7. It was fixed by: commit e7f0d979dd5cc4f8b658df892e93db69d6d660b7 Author: Yao Qi <yao@codesourcery.com> Date: Tue Dec 10 21:59:20 2013 +0800 Fix a bug in matching notifications. Message-ID: <1386684626-11415-1-git-send-email-yao@codesourcery.com> https://sourceware.org/ml/gdb-patches/2013-12/msg00373.html 2013-12-10 Yao Qi <yao@codesourcery.com> * notif.c (handle_notif_ack): Return 0 if no notification matches. with unpatched old FSF gdbserver and patched FSF GDB HEAD: gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234' Sending packet: $vFile:setfs:0#bf...Packet received: OK Packet vFile:setfs (hostio-setfs) is NOT supported ... (gdb) info sharedlibrary From To Syms Read Shared Object Library 0x00007ffff7ddbae0 0x00007ffff7df627a Yes (*) target:/lib64/ld-linux-x86-64.so.2 0x00007ffff7bc48a0 0x00007ffff7bcf514 Yes (*) target:/lib64/libpthread.so.0 gdb/ChangeLog 2016-04-26 Jan Kratochvil <jan.kratochvil@redhat.com> * remote.c (remote_start_remote): Detect PACKET_vFile_setfs.support.
2016-04-27Skip gdb.base/branch-to-self.exp if gdb,nosignals existsYao Qi2-0/+10
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.
2016-04-27c_value_print: Revert 'val' to a reference for TYPE_CODE_STRUCTMartin Galvan2-8/+14
Currently c_value_print will turn struct reference values into pointers before doing a set of RTTI checks. This was introduced as a fix to PR c++/15401. If there's RTTI the pointer will be adjusted and converted back to a reference. However, if there's no RTTI the value will still be treated as a pointer during the remainder of the function. This patch moves the conversion down so that it's always performed when needed. Notice this currently has not user-visible effects, so can be seen as a small code cleanup. However, it'll be necessary for the bug-fix for handling synthetic C++ references. It causes no testsuite regressions. gdb/ChangeLog: 2016-04-26 Martin Galvan <martin.galvan@tallertechnologies.com> * c-valprint.c (c_value_print): Always convert val back to reference type if we converted it to a pointer type.
2016-04-27Tweak doc on command tfindYao Qi2-1/+7
Hi, command "tfind" will find the first trace snapshot if no trace snapshot is selected, but this behavior isn't documented. This patch completes the doc of command "tfind" without argument. gdb/doc: 2016-04-27 Yao Qi <yao.qi@linaro.org> * gdb.texinfo (tfind): Complete doc about tfind without argument.
2016-04-27Avoid non-C++-enabled babeltrace versionsAndreas Arnez3-0/+8
In some babeltrace versions before 1.2.0, the header file iterator.h declares the enum values `BT_SEEK_*' within the struct declaration of bt_iter_pos. The enum values are supposed to be globally-scoped, which works for C, but not for C++. Later babeltrace versions declare the enum outside the struct: https://lists.lttng.org/pipermail/lttng-dev/2013-September/021411.html Now that GDB is compiled with C++, the GDB build fails on a system with an affected babeltrace version: the compiler complains about a missing declaration of BT_SEEK_BEGIN in ctf.c. This patch enhances the configure check to recognize such babeltrace versions as unusable for GDB. gdb/ChangeLog: * configure.ac: Enhance configure check for babeltrace to reject non-C++-enabled versions. * configure: Regenerate.
2016-04-26fort_dyn_array: Use value constructor instead of raw-buffer manipulation.Keven Boell4-79/+58
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.
2016-04-26fort_dyn_array: Support evaluation of dynamic elements inside arrays.Bernhard Heckel5-2/+89
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.
2016-04-26fort_dyn_array: Enable dynamic member types inside a structure.Bernhard Heckel8-6/+292
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.
2016-04-25New test case gdb.base/branch-to-self.expYao Qi3-0/+114
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.
2016-04-25Resume the inferior with signal rather than stepping overYao Qi2-3/+21
When GDBserver steps over a breakpoint using software single step, it enqueues the signal, single step and deliver the signal in the next resume if step over is not needed. In this way, the program won't receive the signal if the conditional breakpoint is set a branch to self instruction, because the step over is always needed. This patch removes the restriction that don't deliver the signal to the inferior if we are trying to reinsert a breakpoint for software single step and change the decision on resume vs. step-over when the LWP has pending signals to deliver. gdb/gdbserver: 2016-04-25 Yao Qi <yao.qi@linaro.org> * linux-low.c (lwp_signal_can_be_delivered): Adjust. (need_step_over_p): Return zero if the LWP has pending signals can be delivered on software single step target.
2016-04-25[GDBserver] Don't error in reinsert_raw_breakpoint if bp->insertedYao Qi2-1/+6
GDBserver steps over a breakpoint while the single step breakpoint is inserted at the same address, there are two breakpoint objects using single raw breakpoint, which is inserted (for single step). When step over is finished, GDBserver reinsert the breakpoint, but it finds the raw breakpoint is already inserted, and error out "Breakpoint already inserted at reinsert time." Even if I change the order to delete reinsert breakpoints first (which only decreases the refcount, but leave inserted flag unchanged), the error is still there. The fix is to remove the error and return instead. gdb/gdbserver: 2016-04-25 Yao Qi <yao.qi@linaro.org> * linux-low.c (reinsert_raw_breakpoint): If bp->inserted is true return instead of error.
2016-04-25Insert breakpoint even when the raw breakpoint is foundYao Qi2-20/+35
When GDBserver inserts a breakpoint, it looks for raw breakpoint, if the raw breakpoint is found, increase its refcount, and return. This doesn't work when it steps over a breakpoint using software single step and the underneath instruction of breakpoint is branch to self. When stepping over a breakpoint on ADDR using software single step, GDBserver uninsert the breakpoint, so the corresponding raw breakpoint RAW's 'inserted' flag is zero. Then, GDBserver insert single step breakpoint at the same address ADDR because the instruction is branch to self, the same raw brekapoint RAW is found, and increase the refcount. However, the raw breakpoint is not inserted, and the program won't stop. gdb/gdbserver: 2016-04-25 Pedro Alves <palves@redhat.com> Yao Qi <yao.qi@linaro.org> * mem-break.c (set_raw_breakpoint_at): Create a raw breakpoint object. Insert it if it is not inserted yet. Increase the refcount and link it into the proc's raw breakpoint list.
2016-04-25Force to insert software single step breakpointYao Qi6-8/+62
GDB doesn't insert software single step breakpoint if the instruction branches to itself, so that the program can't stop after command "si". (gdb) b 32 Breakpoint 2 at 0x8680: file git/gdb/testsuite/gdb.base/branch-to-self.c, line 32. (gdb) c Continuing. Breakpoint 2, main () at gdb/git/gdb/testsuite/gdb.base/branch-to-self.c:32 32 asm (".Lhere: " BRANCH_INSN " .Lhere"); /* loop-line */ (gdb) si infrun: clear_proceed_status_thread (Thread 3991.3991) infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: step-over queue now empty infrun: resuming [Thread 3991.3991] for step-over infrun: skipping breakpoint: stepping past insn at: 0x8680 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sending packet: $Z0,8678,4#f3...Packet received: OK infrun: skipping breakpoint: stepping past insn at: 0x8680 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sending packet: $Z0,b6fe86c8,4#82...Packet received: OK infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Thread 3991.3991] at 0x868 breakpoint.c:should_be_inserted thinks the breakpoint shouldn't be inserted, which is wrong. This patch restrict the condition that only skip the non-single-step breakpoints if they are inserted at the place we are stepping over, however we don't want to skip single-step breakpoint if its thread is the thread we are stepping over, so in this patch, I add a thread num in 'struct step_over_info' to record the thread we're stepping over. gdb: 2016-04-25 Yao Qi <yao.qi@linaro.org> * breakpoint.c (should_be_inserted): Return 0 if the location's owner is not single step breakpoint or single step breakpoint's thread isn't the thread which is stepping past a breakpoint. * gdbarch.sh (software_single_step): Update comments. * gdbarch.h: Regenerated. * infrun.c (struct step_over_info) <thread>: New field. (set_step_over_info): New argument 'thread'. Callers updated. (clear_step_over_info): Set field thread to -1. (thread_is_stepping_over_breakpoint): New function. * infrun.h (thread_is_stepping_over_breakpoint): Declaration.
2016-04-22Fix checks for VSX and Altivec availability on PowerEdjunior Barbosa Machado2-2/+9
gdb/ChangeLog * ppc-linux-nat.c (ppc_linux_read_description): Use PPC_FEATURE_HAS_VSX and PPC_FEATURE_HAS_ALTIVEC to check if such features are available.
2016-04-22Fix fails in gdb.trace/unavailable.expYao Qi2-2/+7
I am seeing some test fails in gdb.trace/unavailable.exp on aarch64-linux, like this, print derived_whole^M $43 = (Derived) {<Middle> = {<Base> = {x = 2}, _vptr.Middle = 0x401860 <VTT for Derived>, y = 3}, _vptr.Derived = 0x401848 <vtable for Derived+32>, z = 4}^M (gdb) FAIL: gdb.trace/unavailable.exp: collect globals: print object on: print derived_whole print derived_whole^M $47 = {<Middle> = {<Base> = {x = 2}, _vptr.Middle = 0x401860 <VTT for Derived>, y = 3}, _vptr.Derived = 0x401848 <vtable for Derived+32>, z = 4}^M (gdb) FAIL: gdb.trace/unavailable.exp: collect globals: print object off: print derived_whole these fails are also found by recent x86_64-linux buildbot, https://sourceware.org/ml/gdb-testers/2016-q2/msg00622.html The fix is exactly the same as this one http://www.sourceware.org/ml/gdb-patches/2015-10/msg00252.html (the extra "VTT" after hex), in which we match extra things after $hex. gdb/testsuite: 2016-04-22 Yao Qi <yao.qi@linaro.org> * gdb.trace/unavailable.exp (gdb_collect_globals_test_1): Match more after $hex.
2016-04-22Choose TARGET_OBJECT_STACK_MEMORY and TARGET_OBJECT_MEMORY in read_value_memoryYao Qi2-1/+10
Before this patch https://sourceware.org/ml/gdb-patches/2014-02/msg00709.html read_value_memory checks parameter 'stack', and call read_stack or read_memory respectively. However, 'stack' is not checked and TARGET_OBJECT_MEMORY is always used in target_xfer_partial, which is a mistake in the patch above. This patch checks parameter 'stack', and choose TARGET_OBJECT_MEMORY or TARGET_OBJECT_STACK_MEMORY accordingly. gdb: 2016-04-22 Yao Qi <yao.qi@linaro.org> * valops.c (read_value_memory): New local variable 'stack'. Set it to either TARGET_OBJECT_STACK_MEMORY or TARGET_OBJECT_MEMORY.
2016-04-22Centralize yacc interface names remapping (yyparse, yylex, yyerror, etc)Pedro Alves28-484/+203
This factors out all the yy-variables remapping to a single file, instead of each parser having to do the same, with different prefixes. With this, a parser just needs to define the prefix they want and include yy-remap.h, which does the dirty job. Note this renames the c_error, ada_error, etc. functions. Writing the remapping pattern as: #define yyerror GDB_YY_REMAP (error) instead of: #define yyerror GDB_YY_REMAP (yyerror) would have avoided the renaming. However, that would be problematic if we have a macro 'foo' in scope, when we write: #define yyfoo GDB_YY_REMAP (foo) as that would expand 'foo'. The c_yyerror etc. naming end ups indicating that this is a yacc related function more clearly, so feels like a good change, anyway. gdb/ChangeLog: 2016-04-22 Pedro Alves <palves@redhat.com> * ada-exp.y: Remove all yy symbol remappings. (GDB_YY_REMAP_PREFIX): Define. Include "yy-remap.h". * ada-lang.c (ada_language_defn): Adjust. * ada-lang.h (ada_error): Rename to ... (ada_yyerror): ... this. * c-exp.y: Remove all yy symbol remappings. (GDB_YY_REMAP_PREFIX): Define. Include "yy-remap.h". * c-lang.c (c_language_defn, cplus_language_defn) (asm_language_defn, minimal_language_defn): Adjust. * c-lang.h (c_error): Rename to ... (c_yyerror): ... this. * d-exp.y: Remove all yy symbol remappings. (GDB_YY_REMAP_PREFIX): Define. Include "yy-remap.h". * d-lang.c (d_language_defn): Adjust. * d-lang.h (d_error): Rename to ... (d_yyerror): ... this. * f-exp.y: Remove all yy symbol remappings. (GDB_YY_REMAP_PREFIX): Define. Include "yy-remap.h". * f-lang.c (f_language_defn): Adjust. * f-lang.h (f_error): Rename to ... (f_yyerror): ... this. * go-exp.y: Remove all yy symbol remappings. (GDB_YY_REMAP_PREFIX): Define. Include "yy-remap.h". * go-lang.c (go_language_defn): Adjust. * go-lang.h (go_error): Rename to ... (go_yyerror): ... this. * jv-exp.y: Remove all yy symbol remappings. (GDB_YY_REMAP_PREFIX): Define. Include "yy-remap.h". * jv-lang.c (java_language_defn): Adjust. * jv-lang.h (java_error): Rename to ... (java_yyerror): ... this. * m2-exp.y: Remove all yy symbol remappings. (GDB_YY_REMAP_PREFIX): Define. Include "yy-remap.h". * m2-lang.c (m2_language_defn): Adjust. * m2-lang.h (m2_error): Rename to ... (m2_yyerror): ... this. * objc-exp.y: Remove all yy symbol remappings. (GDB_YY_REMAP_PREFIX): Define. Include "yy-remap.h". * objc-lang.c (objc_language_defn): Adjust. * opencl-lang.c (opencl_language_defn): Adjust. * p-exp.y: Remove all yy symbol remappings. (GDB_YY_REMAP_PREFIX): Define. Include "yy-remap.h". * p-lang.c (pascal_language_defn): Adjust. * p-lang.h (pascal_error): Rename to ... (pascal_yyerror): ... this. * yy-remap.h: New file.
2016-04-22Switch gdb's TRY/CATCH to C++ try/catchPedro Alves2-5/+12
The exceptions-across-readline issue was fixed by the previous commit. Let's try this again. gdb/ChangeLog: 2016-04-22 Pedro Alves <palves@redhat.com> * common/common-exceptions.h (GDB_XCPT_TRY): Remove mention of the foreign frames issue. [__cplusplus] (GDB_XCPT): Define as GDB_XCPT_TRY.
2016-04-22Propagate GDB/C++ exceptions across readline using sj/lj-based TRY/CATCHPedro Alves4-38/+191
If we map GDB'S TRY/CATCH macros to C++ try/catch, GDB breaks on systems where readline isn't built with exceptions support. The problem is that readline calls into GDB through the callback interface, and if GDB's callback throws a C++ exception/error, the system unwinder won't manage to unwind past the readline frame, and ends up calling std::terminate(), which aborts the process: (gdb) whatever-command-that-causes-an-error terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR' Aborted $ This went unnoticed for so long because: - the x86-64 ABI requires -fasynchronous-unwind-tables, making it possible for exceptions to cross readline with no special handling. But e.g., on ARM or AIX, unless you build readline with -fexceptions, you trip on the problem. - TRY/CATCH was mapped to setjmp/longjmp, even in C++ mode, until quite recently. The fix is to catch and save any GDB exception that is thrown inside the GDB readline callback, and then once the callback returns back to the GDB code that called into readline in the first place, rethrow the saved GDB exception. This is similar in spirit to how we catch/map GDB exceptions at the GDB/Python and GDB/Guile API boundaries. The next question is then: if we intercept all exceptions within GDB's readline callback, should we simply return normally to readline? The callback prototype has no way to signal an error back to readline (*). The answer is no -- if we return normally, we'll be returning to a loop inside rl_callback_read_char that continues processing pending input, calling into GDB again, redisplaying the prompt, etc. Thus if we want to error out of rl_callback_read_char, we need to long jump across it, just like we always did before TRY/CATCH were ever mapped to C++ exceptions. My first approach built a specialized API to handle this, with a couple macros to hide the setjmp/longjmp and the struct gdb_exception saving/rethrowing. However, I realized that we need to: - Handle multiple active rl_callback_read_char invocations. If, while processing input something triggers a secondary prompt, we end up in a nested rl_callback_read_char call, through gdb_readline_wrapper. - Propagate a struct gdb_exception along with the longjmp. ... and that this is exactly what the setjmp/longjmp-based TRY/CATCH does. So the fix makes the setjmp/longjmp TRY/CATCH always available under new TRY_SJLJ/CATCH_SJLJ aliases, even when TRY/CATCH is mapped to C++ try/catch, and then uses TRY_SJLJ/CATCH_SJLJ to propagate GDB exceptions across the readline callback. This turns out to be a much better looking fix than my bespoke API attempt, even. We'll probably be able to simplify TRY_SJLJ/CATCH_SJLJ when we finally get rid of TRY/CATCH all over the tree, but until then, this reuse seems quite nice for avoiding a second parallel setjmp/longjmp mechanism. (*) - maybe we could propose a readline API change, but we still need to handle current readline, anyway. gdb/ChangeLog: 2016-04-22 Pedro Alves <palves@redhat.com> * common/common-exceptions.c (enum catcher_state, struct catcher) (current_catcher): Define in C++ mode too. (exceptions_state_mc_catch): Call throw_exception_sjlj instead of throw_exception. (throw_exception_sjlj, throw_exception_cxx): New functions, factored out from throw_exception. (throw_exception): Reimplement. * common/common-exceptions.h (exceptions_state_mc_init) (exceptions_state_mc_action_iter) (exceptions_state_mc_action_iter_1, exceptions_state_mc_catch): Declare in C++ mode too. (TRY): Rename to ... (TRY_SJLJ): ... this. (CATCH): Rename to ... (CATCH_SJLJ): ... this. (END_CATCH): Rename to ... (END_CATCH_SJLJ): ... this. [GDB_XCPT == GDB_XCPT_SJMP] (TRY, CATCH, END_CATCH): Map to SJLJ equivalents. (throw_exception): Update comments. (throw_exception_sjlj): Declare. * event-top.c (gdb_rl_callback_read_char_wrapper): Extend intro comment. Wrap body in TRY_SJLJ/CATCH_SJLJ and rethrow any intercepted exception. (gdb_rl_callback_handler): New function. (gdb_rl_callback_handler_install): Always install gdb_rl_callback_handler as readline callback.
2016-04-22Rename rl_callback_read_char_wrapper -> gdb_rl_callback_read_char_wrapperPedro Alves2-7/+14
Use the "gdb_rl_" prefix like other gdb readline function wrappers to make it clear this is a gdb function, not a readline function. gdb/ChangeLog: 2016-04-22 Pedro Alves <palves@redhat.com> * event-top.c (rl_callback_read_char_wrapper): Rename to ... (gdb_rl_callback_read_char_wrapper): ... this. (change_line_handler, gdb_setup_readline): Adjust.
2016-04-22[ARM] Clear reserved bits in CPSRYao Qi4-2/+19
Bits 20 ~ 23 of CPSR are reserved (RAZ, read as zero), but they are not zero if the arm program runs on aarch64-linux. AArch64 tracer gets PSTATE from arm 32-bit tracee as CPSR, but bits 20 ~ 23 are used in PSTATE. I think kernel should clear these bits when it is read through ptrace, but the fix in user space is still needed. This patch fixes these two fails, -FAIL: gdb.reverse/insn-reverse.exp: ext_reg_push_pop: compare registers on insn 0:vldr d7, [r11, #-12] -FAIL: gdb.reverse/insn-reverse.exp: ext_reg_push_pop: compare registers on insn 0:vldr d7, [r7] gdb: 2016-04-22 Yao Qi <yao.qi@linaro.org> * aarch32-linux-nat.c (aarch32_gp_regcache_supply): Clear CPSR bits 20 to 23. gdb/gdbserver: 2016-04-22 Yao Qi <yao.qi@linaro.org> * linux-aarch32-low.c (arm_store_gregset): Clear CPSR bits 20 to 23.
2016-04-22Fix fail in gdb.base/annota1.exp and gdb.base/annota3.expYao Qi3-11/+17
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.
2016-04-22Joel Brobecker stepping down as AIX MaintainerJoel Brobecker2-1/+4
gdb/ChangeLog: * MAINTAINERS: Remove myself as AIX Maintainer.
2016-04-22[obv] [PR gdb/19980] Typo in gdbserver/configure.srvWalfred Tedeschi1-1/+1
Simple exchange of mpx-avx for avx-mpx. Other occurrences were not found. 2016-04-22 Walfred Tedeschi <walfred.tedeschi@intel.com> gdb/gdbserver/ChangeLog: * configure.srv (srv_amd64_xmlfiles): Exchange i386/amd64-mpx-avx.xml for i386/amd64-avx-mpx.xml.
2016-04-22Tweak gdb.reverse/step-precsave.exp and gdb.reverse/step-reverse.expYao Qi3-16/+33
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.
2016-04-22Deliver signal in hardware single stepYao Qi4-5/+28
GDBserver doesn't deliver signal when stepping over a breakpoint even hardware single step is used. When GDBserver started to step over (thread creation) breakpoint for mutlit-threaded debugging in 2002 [1], GDBserver behaves this way. This behavior gets trouble on conditional breakpoints on branch to self instruction like this, 0x00000000004005b6 <+29>: jmp 0x4005b6 <main+29> and I set breakpoint $(gdb) break branch-to-self.c:43 if counter > 3 and the variable counter will be set to 5 in SIGALRM signal handler. Since GDBserver keeps stepping over breakpoint, the SIGALRM can never be dequeued and delivered to the inferior, so the program can't stop. The test can be found in gdb.base/branch-to-self.exp. GDBserver didn't deliver signal when stepping over a breakpoint because a tracepoint is collected twice if GDBserver does so in the following scenario, which can be reproduced by gdb.trace/signal.exp. - program stops at tracepoint, and tracepoint is collected, - gdbserver starts a step-over, - a signal arrives, step-over is canceled, and signal should be passed, - gdbserver starts a new step-over again, pass the signal as well, - program stops at the entry of signal handler, step-over finished, - gdbserver proceeds, - program returns from the signal handler, again to the tracepoint, and thus is collected again. The spurious collection isn't that harmful, IMO, so it should be OK to let GDBserver deliver signal when stepping over a breakpoint. gdb/gdbserver: 2016-04-22 Yao Qi <yao.qi@linaro.org> * linux-low.c (lwp_signal_can_be_delivered): Don't deliver signal when stepping over breakpoint with software single step. gdb/testsuite: 2016-04-22 Yao Qi <yao.qi@linaro.org> * gdb.trace/signal.exp: Also pass if $tracepoint_hits($i) > $iterations.
2016-04-22New test case gdb.trace/signal.expYao Qi3-0/+252
This is to test whether GDBserver deliver signal to the inferior while doing the step over. Nowadays, GDBserver doesn't deliver signal, so there won't be spurious collection, however, if GDBserver does deliver signal, there might be spurious collection. gdb/testsuite: 2016-04-22 Yao Qi <yao.qi@linaro.org> * gdb.trace/signal.c: New file. * gdb.trace/signal.exp: New file.
2016-04-22MIPS: Go back with the default Linux # of registers to 90Maciej W. Rozycki2-1/+11
Set the number of registers for non-XML-described Linux targets to 90, reverting a change made here with the addition of DSP register support: commit 1faeff088bbbd037d7769d214378b4faf805fa2e Author: Maciej W. Rozycki <macro@linux-mips.org> Date: Thu Mar 1 22:19:48 2012 +0000 and fixing a regression introduced for legacy `gdbserver' targets causing a "Remote 'g' packet reply is too long" error message where the amount of register data received with a `g' packet (90) exceeds the maximum number of registers expected (79). Update the setting for XML-described targets, reflecting the actual number of registers which have been assigned numbers, matching the: gdb_assert (gdbarch_num_regs (gdbarch) <= MIPS_RESTART_REGNUM); requirement in `mips_linux_init_abi'. gdb/ * mips-tdep.c (mips_gdbarch_init): For GDB_OSABI_LINUX set `num_regs' to 90 rather than 79. Where a target description is present adjust the setting appropriately.
2016-04-21Switch gdb's TRY/CATCH to sjlj againPedro Alves2-6/+10
We don't currently handle the case of gdb's readline callback throwing gdb C++ exceptions across a readline that wasn't built with -fexceptions. The end result is: (gdb) whatever-command-that-causes-an-error terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR' Aborted $ Until that is fixed, revert back to sjlj-based exceptions again. gdb/ChangeLog: 2016-04-21 Pedro Alves <palves@redhat.com> * common/common-exceptions.h (GDB_XCPT_TRY): Add comment. (GDB_XCPT): Always define as GDB_XCPT_SJMP.
2016-04-21Fix AIX gdb build with C++ compilerPedro Alves3-8/+16
We currently get: ../../src/gdb/aix-thread.c: In function 'int pdc_read_data(pthdb_user_t, void*, pthdb_addr_t, size_t)': ../../src/gdb/aix-thread.c:465:46: error: invalid conversion from 'void*' to 'gdb_byte* {aka unsigned char*}' [-fpermissive] status = target_read_memory (addr, buf, len); ^ ../../src/gdb/aix-thread.c: In function 'void aix_thread_resume(target_ops*, ptid_t, int, gdb_signal)': ../../src/gdb/aix-thread.c:1010:46: error: invalid conversion from 'void*' to 'int*' [-fpermissive] gdb_signal_to_host (sig), (void *) tid); ^ ../../src/gdb/aix-thread.c:243:1: error: initializing argument 5 of 'int ptrace64aix(int, int, long long int, int, int*)' [-fpermissive] ptrace64aix (int req, int id, long long addr, int data, int *buf) ../../src/gdb/rs6000-nat.c: In function 'gdb_byte* rs6000_ptrace_ldinfo(ptid_t)': ../../src/gdb/rs6000-nat.c:596:36: error: invalid conversion from 'void*' to 'gdb_byte* {aka unsigned char*}' [-fpermissive] gdb_byte *ldi = xmalloc (ldi_size); ^ ../../src/gdb/rs6000-nat.c:615:36: error: invalid conversion from 'void*' to 'gdb_byte* {aka unsigned char*}' [-fpermissive] ldi = xrealloc (ldi, ldi_size); ^ (and more instances of the same). gdb/ChangeLog: 2016-04-21 Pedro Alves <palves@redhat.com> * aix-thread.c (pdc_read_data, pdc_write_data): Add cast. (aix_thread_resume): Use PTRACE_TYPE_ARG5. * rs6000-nat.c (rs6000_ptrace64): Use PTRACE_TYPE_ARG5. (rs6000_ptrace_ldinfo): Change type of 'ldi' local to void pointer, and cast return to gdb_byte pointer.
2016-04-21Fix s390 GNU/Linux gdb and gdbserver buildsPedro Alves4-9/+21
Now that gdb/gdbserver compile as C++ programs by default, the s390 GNU/Linux build started failing with: In file included from ../../src/gdb/common/common-defs.h:64:0, from ../../src/gdb/defs.h:28, from ../../src/gdb/s390-linux-nat.c:22: ../../src/gdb/s390-linux-nat.c: In function ‘void fetch_regset(regcache*, int, int, int, const regset*)’: ../../src/gdb/../include/libiberty.h:711:38: error: invalid conversion from ‘void*’ to ‘gdb_byte* {aka unsigned char*}’ [-fpermissive] # define alloca(x) __builtin_alloca(x) ^ ../../src/gdb/s390-linux-nat.c:297:19: note: in expansion of macro ‘alloca’ gdb_byte *buf = alloca (regsize); ^ etc. gdb/ChangeLog: 2016-04-21 Pedro Alves <palves@redhat.com> * s390-linux-nat.c (fetch_regset, store_regset, check_regset): Use void * instead of gdb_byte *. gdb/gdbserver/ChangeLog: 2016-04-21 Pedro Alves <palves@redhat.com> * linux-s390-low.c (s390_collect_ptrace_register) (s390_supply_ptrace_register, s390_get_hwcap): Use gdb_byte * and add casts. (s390_check_regset): Use void * instead of gdb_byte *.
2016-04-21Add missing sentinel 'char *' casts in concat/reconcat callsPedro Alves10-16/+34
The wildebeest-debian-wheezy-i686 buildslave's build is broken due to: ../../binutils-gdb/gdb/python/python.c: In function void _initialize_python(): ../../binutils-gdb/gdb/python/python.c:1709:36: error: missing sentinel in function call [-Werror=format] Reproduced on Fedora 23 by sticking a few: #undef NULL #define 0 in build/gdb/build-gnulib/{stddef|signal|stdio}.h. Hopefully this caught all instances. gdb/ChangeLog: 2016-04-21 Pedro Alves <palves@redhat.com> * dwarf2read.c (try_open_dwop_file, open_dwo_file) (file_file_name, file_full_name): Add char * cast to sentinel in concat/reconcat calls. * event-top.c (top_level_prompt): Likewise. * guile/guile.c (initialize_scheme_side): Likewise. * linux-tdep.c (linux_fill_prpsinfo): Likewise. * macrotab.c (macro_source_fullname): Likewise. * main.c (get_init_files, captured_main): Likewise. * psymtab.c (psymtab_to_fullname): Likewise. * python/python.c (_initialize_python) (gdbpy_finish_initialization): Likewise. * source.c (symtab_to_fullname): Likewise.
2016-04-20Build GDB as a C++ program by defaultPedro Alves5-3/+12
This makes --enable-build-with-cxx be "yes" by default. One must now configure with --enable-build-with-cxx=no in order to build with a C compiler. gdb/ChangeLog: 2016-04-20 Pedro Alves <palves@redhat.com> * build-with-cxx.m4 (GDB_AC_BUILD_WITH_CXX): Default to yes. * configure: Renegerate. gdb/gdbserver/ChangeLog: 2016-04-20 Pedro Alves <palves@redhat.com> * configure: Renegerate.
2016-04-20Fix host signal vs gdb signal mixup in gdb/darwin-nat.cPedro Alves2-1/+5
Building in C++ mode caught a bug here: .../src/gdb/darwin-nat.c: In function 'ptid_t darwin_decode_message(mach_msg_header_t*, darwin_thread_t**, inferior**, target_waitstatus*)': .../src/gdb/darwin-nat.c:1016:25: error: invalid conversion from 'int' to 'gdb_signal' [-fpermissive] status->value.sig = WTERMSIG (wstatus); ^ gdb/ChangeLog: 2016-04-20 Pedro Alves <palves@redhat.com> * darwin-nat.c (darwin_decode_message): Use gdb_signal_from_host.
2016-04-20Fix "incompatible pointer type" warning in gdb/aarch64-tdep.cPedro Alves2-1/+7
Fixes, with x86_64-apple-darwin15-gcc (gcc 5.3.0): .../src/gdb/aarch64-tdep.c: In function 'aarch64_record_load_store': .../src/gdb/aarch64-tdep.c:3479:67: error: passing argument 3 of 'regcache_raw_read_unsigned' from incompatible pointer type [-Werror=incompatible-pointer-types] bits (aarch64_insn_r->aarch64_insn, 16, 20), &reg_rm_val); ^ In file included from .../src/gdb/regcache.h:23:0, from .../src/gdb/gdbarch.h:69, from .../src/gdb/defs.h:620, from .../src/gdb/aarch64-tdep.c:21: .../src/gdb/common/common-regcache.h:60:29: note: expected 'ULONGEST * {aka long unsigned int *}' but argument is of type 'uint64_t * {aka long long unsigned int *}' extern enum register_status regcache_raw_read_unsigned ^ gdb/ChangeLog: 2016-04-20 Pedro Alves <palves@redhat.com> * aarch64-tdep.c (aarch64_record_load_store): Change type of 'reg_rm_val' local to ULONGEST.
2016-04-20gdb/darwin-nat.c: Fix "cast to pointer from integer of different size" warningPedro Alves2-1/+5
Fixes, with gcc 5.3.0: .../src/gdb/darwin-nat.c: In function 'void darwin_resume_thread(inferior*, darwin_thread_t*, int, int)': .../src/gdb/darwin-nat.c:731:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] (caddr_t)thread->gdb_port, nsignal); ^ .../src/gdb/darwin-nat.c:84:35: note: in definition of macro 'PTRACE' darwin_ptrace(#CMD, CMD, (PID), (ADDR), (SIG)) ^ thread->gdb_port is an unsigned int, caddr_t is a void pointer. gdb/ChangeLog: 2016-04-20 Pedro Alves <palves@redhat.com> * darwin-nat.c (darwin_resume_thread): Add uintptr_t cast.
2016-04-20symmisc.c (dump_symtab_1): Print owning compunit for identical blockvectors.Doug Evans2-1/+11
* symmisc.c (dump_symtab_1): Print owning compunit for identical blockvectors.
2016-04-20Include arch/arm-linux.h in aarch32-linux-nat.cYao Qi2-0/+5
Fix the compilation failure by including arch/arm-linux.h in aarch32-linux-nat.c. gdb: 2016-04-20 Yao Qi <yao.qi@linaro.org> * aarch32-linux-nat.c: Include "arch/arm-linux.h".
generated by cgit v1.1 at 2024-11-24 15:07:41 +0000