aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2015-04-17solib-svr4.c (svr4_exec_displacement): Rename outer "displacement".Doug Evans2-6/+11
gdb/ChangeLog: * solib-svr4.c (svr4_exec_displacement): Rename outer "displacement" to "exec_displacement" to avoid confusion with inner use of the name.
2015-04-17gdbserver/xtensa: fix typo in XCHAL_HAVE_LOOPSMax Filippov2-2/+8
This fixes lbeg/lend/lcount registers handling through gdbserver. 2015-04-17 Max Filippov <jcmvbkbc@gmail.com> gdb/gdbserver/ * linux-xtensa-low.c (xtensa_fill_gregset) (xtensa_store_gregset): Check XCHAL_HAVE_LOOPS instead of XCHAL_HAVE_LOOP.
2015-04-17gdbserver/xtensa: drop xtensa_usrregs_infoMax Filippov2-7/+6
xtensa_usrregs_info refers to undefined variables xtensa_num_regs and xtensa_regmap. Drop xtensa_usrregs_info and replace pointer to usrregs in regs_info with NULL since all registers are read/set through regsets. 2015-04-17 Max Filippov <jcmvbkbc@gmail.com> gdb/gdbserver/ * linux-xtensa-low.c (xtensa_usrregs_info): Remove. (regs_info): Replace usrregs pointer with NULL.
2015-04-17return zero in arm_linux_can_use_hw_breakpoint if HW point isn't supportedYao Qi2-2/+15
This patch is to cherry-pick part of Pedro's patch here https://sourceware.org/ml/gdb-patches/2015-04/msg00527.html in which zero is returned if the HW point isn't supported. In arm-linux native gdb testing on a board doesn't support HW breakpoint, without this patch, the output in gdb.base/breakpoint-in-ro-region.exp is like: (gdb) hbreak *0x83bc^M Hardware breakpoints used exceeds limit.^M (gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: probe hbreak support (support) with this patch, the output becomes: (gdb) hbreak *0x83bc^M No hardware breakpoint support in the target.^M (gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: probe hbreak support (no support) As a result, the following fails are fixed. -FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: step in ro region (cannot insert hw break) -FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: thread advanced -FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw on: step in ro region (cannot insert hw break) -FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw on: thread advanced gdb: 2015-04-17 Pedro Alves <palves@redhat.com> * arm-linux-nat.c (arm_linux_can_use_hw_breakpoint): Return zero if HW point of TYPE isn't supported.
2015-04-17Update comments to target_can_use_hardware_watchpointYao Qi2-5/+14
The return value of target_can_use_hardware_watchpoint isn't well documented, so this patch is to update the comments to reflect the fact. This patch also removes a trailing ";" which is picked up from Pedro's patch https://sourceware.org/ml/gdb-patches/2015-04/msg00527.html gdb: 2015-04-17 Yao Qi <yao.qi@linaro.org> Pedro Alves <palves@redhat.com> * target.h (target_can_use_hardware_watchpoint): Update comments. Remove trailing ";".
2015-04-17Access executable from remote system when first inferior appearsGary Benson7-9/+49
This commit modifies remote_add_inferior to take an extra argument try_open_exec. If this is nonzero, remote_add_inferior will attempt to open this inferior's executable as the main executable if no main executable is open already. Callers are updated appropriately. With this commit, remote debugging can now be initiated using only a "target remote" or "target extended-remote" command; no "set sysroot" or "file" commands are required, e.g. bash$ gdb -q (gdb) target remote | gdbserver - /bin/sh Remote debugging using | gdbserver - /bin/sh Process /bin/sh created; pid = 32166 stdin/stdout redirected Remote debugging using stdio Reading symbols from target:/bin/bash... One testcase required updating as a result of this commit. The test checked that GDB's "info files" command does not crash if no main executable is open, and relied on GDB's inability to access the main executable over the remote protocol. The test was updated to inhibit this new behavior. gdb/ChangeLog: * remote.c (remote_add_inferior): New argument try_open_exec. If nonzero, attempt to open the inferior's executable file as the main executable if no main executable is open already. All callers updated. * NEWS: Mention that GDB now supports automatic location and retrieval of executable + files from remote targets. gdb/doc/ChangeLog: * gdb.texinfo (Connecting to a Remote Target): Mention that GDB can access program files from remote targets that support qXfer:exec-file:read and Host I/O packets. gdb/testsuite/ChangeLog: * gdb.server/server-exec-info.exp: Inhibit GDB from accessing the main executable over the remote protocol.
2015-04-17Implement qXfer:exec-file:read in gdbserverGary Benson4-0/+57
This commit implements the "qXfer:exec-file:read" packet in gdbserver. gdb/gdbserver/ChangeLog: * target.h (struct target_ops) <pid_to_exec_file>: New field. * linux-low.c (linux_target_ops): Initialize pid_to_exec_file. * server.c (handle_qxfer_exec_file): New function. (qxfer_packets): Add exec-file entry. (handle_query): Report qXfer:exec-file:read as supported packet.
2015-04-17Implement remote_pid_to_exec_file using qXfer:exec-file:readGary Benson6-1/+88
This commit adds a new packet "qXfer:exec-file:read" to the remote protocol that can be used to obtain the pathname of the file that was executed to create a process on the remote system. Support for this packet is added to GDB and remote_ops.to_pid_to_exec_file is implemented using it. gdb/ChangeLog: * target.h (TARGET_OBJECT_EXEC_FILE): New enum value. * remote.c (PACKET_qXfer_exec_file): Likewise. (remote_protocol_features): Register the "qXfer:exec-file:read" feature. (remote_xfer_partial): Handle TARGET_OBJECT_EXEC_FILE. (remote_pid_to_exec_file): New function. (init_remote_ops): Initialize to_pid_to_exec_file. (_initialize_remote): Register new "set/show remote pid-to-exec-file-packet" command. * NEWS: Announce new qXfer:exec-file:read packet. gdb/doc/ChangeLog: * gdb.texinfo (Remote Configuration): Document the "set/show remote pid-to-exec-file-packet" command. (General Query Packets): Document the qXfer:exec-file:read qSupported features. Document the qXfer:exec-file:read packet.
2015-04-17Introduce linux_proc_pid_to_exec_fileGary Benson4-9/+34
This commit introduces a new function linux_proc_pid_to_exec_file that shared Linux code can use to discover the filename of the executable that was run to create a process on the system. gdb/ChangeLog: * nat/linux-procfs.h (linux_proc_pid_to_exec_file): New declaration. * nat/linux-procfs.c (linux_proc_pid_to_exec_file): New function, factored out from... * linux-nat.c (linux_child_pid_to_exec_file): ...here.
2015-04-17Use gdb_sysroot for main executable on attachGary Benson5-16/+54
This commit updates exec_file_locate_attach to use exec_file_find to compute the full pathname of the main executable in some cases. The net effect of this is that the main executable's path will be prefixed with gdb_sysroot in the same way that shared library paths currently are. gdb/ChangeLog: * exec.c (solist.h): New include. (exec_file_locate_attach): Prefix absolute executable paths with gdb_sysroot if set. * NEWS: Mention that executable paths may be prepended with sysroot. gdb/doc/ChangeLog: * gdb.texinfo (set sysroot): Document that "set sysroot" also applies to executable paths if supplied to GDB as absolute.
2015-04-17Introduce exec_file_findGary Benson3-47/+110
This commit adds a new function, exec_file_find, which computes the full pathname of the main executable in much the same way solib_find does for pathnames of shared libraries. The bulk of the existing solib_find was moved into a new static function solib_find_1, with exec_file_find and solib_find being small wrappers for solib_find_1. gdb/ChangeLog: * solist.h (exec_file_find): New declaration. * solib.c (solib_find_1): New function, factored out from... (solib_find): ...here. (exec_file_find): New function.
2015-04-17Introduce exec_file_locate_attachGary Benson4-23/+47
This commit adds a new function, exec_file_locate_attach, which works like exec_file_attach except that, instead of a filename argument, it takes an integer process ID and attempts to determine the executable filename from that. gdb/ChangeLog: * gdbcore.h (exec_file_locate_attach): New declaration. * exec.c (exec_file_locate_attach): New function, factored out from... * infcmd.c (attach_command_post_wait): ...here.
2015-04-17gdb: add myself to blackfin/write-after-approvalMike Frysinger2-0/+6
2015-04-16Fix {mi-tracepoint-changed, mi-tsv-changed}.exp with native-extended-gdbserverPedro Alves2-2/+12
Fixes: -FAIL: gdb.trace/mi-tracepoint-changed.exp: reconnect: break-info 1 +PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: tracepoint created +PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: tracepoint on marker is installed +PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: break-info 1 -FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created -FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created +PASS: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created +PASS: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created These tests do something like this: #0 - start gdb/gdbserver normally #1 - setup some things in the debug session #2 - disconnect from gdbserver #3 - restart gdb #4 - reconnect to gdbserver The problem is that the native-extended-gdbserver board always spawns a new gdbserver instance in #3 (and has gdb connect to that). So when the test gets to #4, it connects to that new instance instead of the old one: (gdb) spawn ../gdbserver/gdbserver --multi :2354 Listening on port 2354 target extended-remote localhost:2354 Remote debugging using localhost:2354 ... spawn ../gdbserver/gdbserver --multi :2355 Listening on port 2355 47-target-select extended-remote localhost:2355 =tsv-created,name="trace_timestamp",initial="0"\n 47^connected (gdb) ... 47-target-select extended-remote localhost:2355 47^connected (gdb) FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created testsuite/ChangeLog: 2015-04-16 Pedro Alves <palves@redhat.com> * boards/native-extended-gdbserver.exp (mi_gdb_start): Don't start a new gdbserver if gdbserver_reconnect_p is set.
2015-04-16Fix gdbserver_reconnect_p handlingPedro Alves2-0/+13
Commit 6423214f (testsuite: Don't use expect_background to reap gdbserver) broke a couple tests that set gdbserver_reconnect_p and restart gdb before reconnecting, because a gdb_exit (e.g., through clean_restart) exits gdbserver unconditionally. Fixes, with --target_board=native-gdbserver: -FAIL: gdb.trace/mi-tracepoint-changed.exp: reconnect: break-info 1 +PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: tracepoint created +PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: tracepoint on marker is installed +PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: break-info 1 -FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created -FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created +PASS: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created +PASS: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created gdb/testsuite/ 2015-04-16 Pedro Alves <palves@redhat.com> * lib/gdbserver-support.exp (gdb_exit): If gdbserver_reconnect_p is set, don't exit gdbserver.
2015-04-16Honour software single step in fallback of displaced steppingYao Qi2-2/+11
Hi, When I run gdb.threads/non-stop-fair-events.exp on arm-linux target, I see the following message in the debugging log, displaced: breakpoint is gone: Thread 22518, step(1)^M Sending packet: $vCont;s:p57f3.57f6#9d... ^^^^^^^^^ GDB sends vCont;s by mistake, and GDBserver fails on assert. GDB doesn't consider software single step in infrun.c:displaced_step_fixup, /* Go back to what we were trying to do. */ step = currently_stepping (tp); if (debug_displaced) fprintf_unfiltered (gdb_stdlog, "displaced: breakpoint is gone: %s, step(%d)\n", target_pid_to_str (tp->ptid), step); target_resume (ptid, step, GDB_SIGNAL_0); The patch is to let GDB consider software single step here. It fixes fails in gdb.threads/non-stop-fair-events.exp on arm. gdb: 2015-04-16 Yao Qi <yao.qi@linaro.org> * infrun.c (maybe_software_singlestep): Declare. (displaced_step_fixup): Call maybe_software_singlestep.
2015-04-16s390-vregs.exp: Avoid compile errors with older GCCs and on 31-bit targetsAndreas Arnez3-3/+11
The test case s390-vregs.exp yields compile errors on 31-bit targets as well as when using a GCC that defaults to an older "-march=". This patch fixes these issues. gdb/testsuite/ChangeLog: * gdb.arch/s390-vregs.S (change_vrs): Replace exrl by an appropriate .insn, such that an older assembler can be used. * gdb.arch/s390-vregs.exp: Add the compile flag -mzarch, to enable the z/Architecture instruction set on 31-bit targets as well.
2015-04-16GDB tests for Go language support: remove unnecessary first breakpointAndreas Arnez9-40/+24
On s390x targets some of the Go test cases fail because the first breakpoint happens to be at the same spot as the breakpoint at main.main. When such a test case tries to continue to the first breakpoint, the program runs until the end instead, and the test fails like this: FAIL: gdb.go/handcall.exp: Going to first breakpoint (the program exited) This patch removes all the handling related to the first breakpoint in those cases. After applying the patch, the tests run successfully on s390x. gdb/testsuite/ChangeLog: * gdb.go/handcall.exp: Remove all logic related to the first breakpoint and rely on go_runto_main instead. * gdb.go/strings.exp: Likewise. * gdb.go/unsafe.exp: Likewise. * gdb.go/hello.exp: Likewise. Also rename the remaining breakpoint marker to "breakpoint 1". * gdb.go/handcall.go: Remove comment "set breakpoint 1 here". * gdb.go/strings.go: Likewise. * gdb.go/unsafe.go: Likewise. * gdb.go/hello.go: Likewise. Also remove the second occurrence of "set breakpoint 2 here" and rename the remaining breakpoint marker to "breakpoint 1".
2015-04-15Make info fun|var|types interruptable for psyms.Doug Evans2-0/+6
gdb/ChangeLog: * psymtab.c (psym_expand_symtabs_matching): Add QUIT call.
2015-04-15Make info fun|var|types interruptable.Doug Evans2-0/+8
"info fun foo" can be a pain when it's not interruptable, especially if you're not exactly sure of what you're looking for and provide something that matches too much. gdb/ChangeLog: * dwarf2read.c (dw2_expand_symtabs_matching): Add some QUIT calls.
2015-04-15gdbserver: fix uClibc build whithout MMU.Romain Naour2-1/+5
Since commit d86d4aafd4fa22fa4cccb83253fb187b03f97f48, the pid must be retrieved from current_thread. The change has not been made in the function linux_read_offsets(). Fixes: http://autobuild.buildroot.net/results/9e4/9e4df085319e346803c26c65478accb27eb950ae/build-end.log 2015-04-14 Romain Naour <romain.naour@openwide.fr> (tiny change) * linux-low.c (linux_read_offsets): Remove get_thread_lwp. Signed-off-by: Romain Naour <romain.naour@openwide.fr>
2015-04-15Some Python 3 fixesSimon Marchi7-10/+27
Some missing parentheses and one itertools.imap (Py2) vs map (Py3) issue. gdb/ChangeLog: * python/lib/gdb/command/unwinders.py: Add parentheses. gdb/testsuite/ChangeLog: * gdb.python/py-framefilter.py (ErrorFilter.filter): Use map function if itertools.imap is not present. * gdb.python/py-objfile.exp: Add parentheses. * gdb.python/py-type.exp: Same. * gdb.python/py-unwind-maint.py: Same.
2015-04-15[arm] Update displaced stepping debug messageYao Qi2-2/+5
When I "set debug displaced 1" to fix fail in gdb.base/disp-step-syscall.exp, the debug message is wrong. This patch is to fix it. gdb: 2015-04-15 Yao Qi <yao.qi@linaro.org> * arm-linux-tdep.c (arm_linux_copy_svc): Update debug message.
2015-04-15Fix code indentationYao Qi2-41/+46
gdb: 2015-04-15 Yao Qi <yao.qi@linaro.org> * arm-linux-tdep.c (arm_linux_copy_svc): Fix indentation.
2015-04-15[arm] Fix fails in gdb.base/disp-step-syscall.expYao Qi2-3/+8
Hi, I see this fail on arm-linux target, FAIL: gdb.base/disp-step-syscall.exp: fork: single step over fork final pc which is caused by the PC isn't expected after displaced stepping the svc instruction. The code is: => 0xb6ead9a4 <__libc_do_syscall+4>: svc 0 0xb6ead9a6 <__libc_do_syscall+6>: pop {r7, pc} 0xb6ead9a8: nop.w^M 0xb6ead9ac: nop.w after single step svc instruction, pc should be 0xb6ead9a6, but the actual value of pc is 0xb6ead9a8. The problem is illustrated by turning on debug message of displaced stepping, stepi^M displaced: stepping Thread 12031 now^M displaced: saved 0x8574: 02 bc 6a 46 04 b4 01 b4 df f8 10 c0 4d f8 04 cd 03 48 04 4b ff f7 d2 ef ff f7 e8 ef 0d 87 00 00 ^M displaced: process thumb insn df00 at b6ead9a4^M displaced: copying svc insn df00^M displaced: read r7 value 00000078^M displaced: sigreturn/rt_sigreturn SVC call not in signal trampoline frame^M displaced: writing insn df00 at 00008574^M displaced: copy 0xb6ead9a4->0x8574: displaced: check mode of b6ead9a4 instead of 00008574^M displaced: displaced pc to 0x8574^M displaced: run 0x8574: 00 df 01 de ^M displaced: restored Thread 12031 0x8574^M displaced: PC is apparently 00008576 after SVC step (within scratch space)^M displaced: writing pc b6ead9a8 <----- WRONG ADDRESS GDB writes the wrong address back to pc because GDB thinks the instruction size is 4, which isn't true for thumb instruction. This patch is to replace 4 with dsc->insn_size. gdb: 2015-04-15 Yao Qi <yao.qi@linaro.org> * arm-linux-tdep.c (arm_linux_cleanup_svc): Use dsc->insn_size instead of 4.
2015-04-15Fix fails in gdb.dwarf2/dynarr-ptr.expYao Qi2-1/+6
I see many fails in gdb.dwarf2/dynarr-ptr.exp on arm-linux target, started from this print foo.three_ptr.all^M Cannot access memory at address 0x107c8^M (gdb) FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr.all print foo.three_ptr.all(1)^M Cannot access memory at address 0x107c8 It turns out that ":$ptr_size" is used incorrectly. array_ptr_label: DW_TAG_pointer_type { {DW_AT_byte_size :$ptr_size } ^^^^^^^^^^ {DW_AT_type :$array_label} } Since the FORM isn't given, and it starts with the ":", it is regarded as a label reference by dwarf assembler. The generated asm file on x86_64 is .uleb128 6 /* Abbrev (DW_TAG_pointer_type) */ .4byte 8 - .Lcu1_begin <----- WRONG .4byte .Llabel2 - .Lcu1_begin Looks .Lcu1_begin is 0 on x86_64 and that is why this test passes on x86_64. On arm, .Lcu1_begin is an address somewhere, and the value of DW_AT_byte_size is a very large number, so memory read request of such large length failed. This patch is to remove ":" and set the form explicitly. The generated asm file on x86_64 becomes .uleb128 6 /* Abbrev (DW_TAG_pointer_type) */ .byte 8 .4byte .Llabel2 - .Lcu1_begin gdb/testsuite: 2015-04-15 Yao Qi <yao.qi@linaro.org> * gdb.dwarf2/dynarr-ptr.exp (assemble): Use $ptr_size instead of ":$ptr_size" and set its form explicitly.
2015-04-15Increase timeout in watch-bitfields.exp for software watchpointYao Qi6-54/+92
I see the following two timeout fails on pandaboard (arm-linux target), FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: continue until exit (timeout) FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: continue until exit (timeout) In this test, more than one watchpoint is used, so the following watchpoint requests fall back to software watchpoint, so that GDB will single step all the way and it is very slow. This patch is to copy the fix from [PATCH] GDB/testsuite: Correct gdb.base/watchpoint-solib.exp timeout tweak https://sourceware.org/ml/gdb-patches/2014-07/msg00716.html I find the left-over of this patch review is to factor out code into a procedure, so I do that in this patch. Re-run tests watch-bitfields.exp, watchpoint-solib.exp, sigall-reverse.exp, and until-precsave.exp on pandaboard, no regression. gdb/testsuite: 2015-04-15 Pedro Alves <palves@redhat.com> Yao Qi <yao.qi@linaro.org> * gdb.base/watch-bitfields.exp (test_watch_location): Increase timeout by factor of 4. (test_regular_watch): Likewise. * gdb.base/watchpoint-solib.exp: Use with_timeout_factor. * gdb.reverse/sigall-reverse.exp: Likewise. * gdb.reverse/until-precsave.exp: Likewise. * lib/gdb.exp (with_timeout_factor): New proc. (gdb_expect): Move some code to ... (get_largest_timeout): ... here. New procedure.
2015-04-14Harden gdb.base/bp-permanent.expLuis Machado2-1/+6
Reinstate test message and replace hardcoded test command with a variable. gdb/testsuite/ChangeLog: 2015-04-14 Luis Machado <lgustavo@codesourcery.com> * gdb.base/bp-permanent.exp (test): Reinstate correct test message.
2015-04-14Zero supplied stat buffers in functions that pretend to statGary Benson5-0/+11
GDB has five places where it pretends to stat for bfd_openr_iovec. Four of these only set the incoming buffer's st_size, leaving the other fields unchanged, which is to say very likely populated with random values from the stack. remote_bfd_iovec_stat was fixed in 0a93529c56714b1da3d7106d3e0300764f8bb81c; this commit fixes the other four. gdb/ChangeLog: * jit.c (mem_bfd_iovec_stat): Zero supplied buffer. * minidebug.c (lzma_stat): Likewise. * solib-spu.c (spu_bfd_iovec_stat): Likewise. * spu-linux-nat.c (spu_bfd_iovec_stat): Likewise.
2015-04-13 * MAINTAINERS: Update my email address.Stan Shebs2-2/+6
diff --git a/gdb/MAINTAINERS b/gdb/MAINTAINERS index a67a1a8..0fdd8e5 100644 --- a/gdb/MAINTAINERS +++ b/gdb/MAINTAINERS @@ -156,7 +156,7 @@ Doug Evans dje@google.com Daniel Jacobowitz drow@false.org Mark Kettenis kettenis@gnu.org Yao Qi yao.qi@arm.com -Stan Shebs stan@codesourcery.com +Stan Shebs stanshebs@google.com Ulrich Weigand Ulrich.Weigand@de.ibm.com Elena Zannoni elena.zannoni@oracle.com Eli Zaretskii eliz@gnu.org @@ -631,7 +631,7 @@ Keith Seitz keiths@redhat.com Carlos Eduardo Seo cseo@linux.vnet.ibm.com Ozkan Sezer sezeroz@gmail.com Marcus Shawcroft marcus.shawcroft@arm.com -Stan Shebs stan@codesourcery.com +Stan Shebs stanshebs@google.com Joel Sherrill joel.sherrill@oarcorp.com Mark Shinwell shinwell@codesourcery.com Craig Silverstein csilvers@google.com
2015-04-13Add support for the x86 XSAVE extended state on FreeBSD/x86.John Baldwin14-6/+456
Recognize NT_X86_XSTATE notes in FreeBSD process cores. Recent FreeBSD versions include a note containing the XSAVE state for each thread in the process when XSAVE is in use. The note stores a copy of the current XSAVE mask in a reserved section of the machine-defined XSAVE state at the same offset as Linux's NT_X86_XSTATE note. For native processes, use the PT_GETXSTATE_INFO ptrace request to determine if XSAVE is enabled, and if so the active XSAVE state mask (that is, the value of %xcr0 for the target process) as well as the size of XSAVE state area. Use the PT_GETXSTATE and PT_SETXSTATE requests to fetch and store the XSAVE state, respectively, in the BSD x86 native targets. In addition, the FreeBSD amd64 and i386 native targets now include "read_description" target methods to determine the correct x86 target description for the current XSAVE mask. On FreeBSD amd64 this also properly returns an i386 target description for 32-bit binaries which allows the 64-bit GDB to run 32-bit binaries. Note that the ptrace changes are in the BSD native targets, not the FreeBSD-specific native targets since that is where the other ptrace register accesses occur. Of the other BSDs, NetBSD and DragonFly use XSAVE in the kernel but do not currently export the extended state via ptrace(2). OpenBSD does not currently support XSAVE. bfd/ChangeLog: * elf.c (elfcore_grok_note): Recognize NT_X86_XSTATE on FreeBSD. (elfcore_write_xstatereg): Use correct note name on FreeBSD. gdb/ChangeLog: * amd64-tdep.c (amd64_target_description): New function. * amd64-tdep.h: Export amd64_target_description and tdesc_amd64. * amd64bsd-nat.c [PT_GETXSTATE_INFO]: New variable amd64bsd_xsave_len. (amd64bsd_fetch_inferior_registers) [PT_GETXSTATE_INFO]: Handle x86 extended save area. (amd64bsd_store_inferior_registers) [PT_GETXSTATE_INFO]: Likewise. * amd64bsd-nat.h: Export amd64bsd_xsave_len. * amd64fbsd-nat.c (amd64fbsd_read_description): New function. (_initialize_amd64fbsd_nat): Set "to_read_description" to "amd64fbsd_read_description". * amd64fbsd-tdep.c (amd64fbsd_core_read_description): New function. (amd64fbsd_supply_xstateregset): New function. (amd64fbsd_collect_xstateregset): New function. Add "amd64fbsd_xstateregset". (amd64fbsd_iterate_over_regset_sections): New function. (amd64fbsd_init_abi): Set "xsave_xcr0_offset" to "I386_FBSD_XSAVE_XCR0_OFFSET". Add "iterate_over_regset_sections" gdbarch method. Add "core_read_description" gdbarch method. * i386-tdep.c (i386_target_description): New function. * i386-tdep.h: Export i386_target_description and tdesc_i386. * i386bsd-nat.c [PT_GETXSTATE_INFO]: New variable i386bsd_xsave_len. (i386bsd_fetch_inferior_registers) [PT_GETXSTATE_INFO]: Handle x86 extended save area. (i386bsd_store_inferior_registers) [PT_GETXSTATE_INFO]: Likewise. * i386bsd-nat.h: Export i386bsd_xsave_len. * i386fbsd-nat.c (i386fbsd_read_description): New function. (_initialize_i386fbsd_nat): Set "to_read_description" to "i386fbsd_read_description". * i386fbsd-tdep.c (i386fbsd_core_read_xcr0): New function. (i386fbsd_core_read_description): New function. (i386fbsd_supply_xstateregset): New function. (i386fbsd_collect_xstateregset): New function. Add "i386fbsd_xstateregset". (i386fbsd_iterate_over_regset_sections): New function. (i386fbsd4_init_abi): Set "xsave_xcr0_offset" to "I386_FBSD_XSAVE_XCR0_OFFSET". Add "iterate_over_regset_sections" gdbarch method. Add "core_read_description" gdbarch method. * i386fbsd-tdep.h: New file.
2015-04-13Harden gdb.base/bp-permanent.expLuis Machado2-1/+17
This testcase does not work as expected in QEMU (aarch64 QEMU in my case). It fails when trying to manually write the breakpoint instruction to a certain PC address. (gdb) p /x addr_bp[0] = buffer[0]^M Cannot access memory at address 0x400834^M (gdb) PASS: gdb.base/bp-permanent.exp: always_inserted=off, sw_watchpoint=0: setup: p /x addr_bp[0] = buffer[0] p /x addr_bp[1] = buffer[1]^M Cannot access memory at address 0x400835^M (gdb) PASS: gdb.base/bp-permanent.exp: always_inserted=off, sw_watchpoint=0: setup: p /x addr_bp[1] = buffer[1] p /x addr_bp[2] = buffer[2]^M Cannot access memory at address 0x400836^M (gdb) PASS: gdb.base/bp-permanent.exp: always_inserted=off, sw_watchpoint=0: setup: p /x addr_bp[2] = buffer[2] p /x addr_bp[3] = buffer[3]^M Cannot access memory at address 0x400837^M (gdb) PASS: gdb.base/bp-permanent.exp: always_inserted=off, sw_watchpoint=0: setup: p /x addr_bp[3] = buffer[3] The following patch prevents a number of failures by detecting this and bailing out in case the target has such a restriction. Writing to .text from within the program isn't any better. It just leads to a SIGSEGV. Before the patch: === gdb Summary === After the patch: === gdb Summary === gdb/testsuite/ChangeLog: 2015-04-13 Luis Machado <lgustavo@codesourcery.com> * gdb.base/bp-permanent.exp (test): Handle the case of being unable to write to the .text section.
2015-04-13Harden gdb.base/coredump-filter.expLuis Machado2-0/+17
This testcase seems to assume the target is running Linux, so bare metal, simulators and other debugging stubs running different OS' will have a hard time executing some of the commands the testcase issues. Even restricting the testcase to Linux systems (which the patch below does), there are still problems with, say, QEMU not providing PID information when "info inferior" is issued. As a consequence, the subsequent tests will either fail or will not make much sense. The attached patch checks if PID information is available. If not, it just bails out and avoids running into a number of failures. gdb/testsuite/ChangeLog: 2015-04-13 Luis Machado <lgustavo@codesourcery.com> * gdb.base/coredump-filter.exp: Restrict test to Linux systems only. Handle the case of targets that do not provide PID information.
2015-04-13Catch exception in lib/gdbserver-support.exp:gdb_exitYao Qi2-9/+22
I see the error when I run gdb-sigterm.exp with native-gdbserver on x86_64-linux. infrun: prepare_to_wait^M Cannot execute this command while the target is running.^M Use the "interrupt" command to stop the target^M and then try again.^M gdb.base/gdb-sigterm.exp: expect eof #0: got eof gdb.base/gdb-sigterm.exp: expect eof #0: stepped 12 times ERROR OCCURED: : spawn id exp8 not open while executing "expect { -i exp8 -timeout 10 -re "$gdb_prompt $" { exp_continue } -i "$server_spawn_id" eof { wait -i $expect_out(spawn_id) unse..." ("uplevel" body line 1) invoked from within In gdb-sigterm.exp, SIGTERM is sent to GDB and it exits. However, Dejagnu or tcl doesn't know this. This patch is to catch the exception, but error messages are still shown in the console and gdb.log. In order to avoid this, we also replace gdb_expect with expect. gdb/testsuite: 2015-04-13 Yao Qi <yao.qi@linaro.org> * lib/gdbserver-support.exp (gdb_exit): Catch exception and use expect instead of gdb_expect.
2015-04-13Rename variable "addr" to "coredump_var_addr" in gdb.base/coredump-filter.expSergio Durigan Junior2-4/+9
This commit renames the global array variable "addr" to an unique name "coredump_var_addr" in the test gdb.base/coredump-filter.exp. This is needed because global arrays can have name conflicts between tests. For example, this specific test was conflicting with dmsym.exp, causing errors like: ERROR: tcl error sourcing ../../../../../binutils-gdb/gdb/testsuite/gdb.base/dmsym.exp. ERROR: can't set "addr": variable is array while executing "set addr "0x\[0-9a-zA-Z\]+"" (file "../../../../../binutils-gdb/gdb/testsuite/gdb.base/dmsym.exp" line 45) invoked from within "source ../../../../../binutils-gdb/gdb/testsuite/gdb.base/dmsym.exp" ("uplevel" body line 1) invoked from within "uplevel #0 source ../../../../../binutils-gdb/gdb/testsuite/gdb.base/dmsym.exp" invoked from within "catch "uplevel #0 source $test_file_name"" This problem was reported by Yao Qi at: <https://sourceware.org/ml/gdb-patches/2015-04/msg00373.html> Message-Id: <1428666671-12926-1-git-send-email-qiyaoltc@gmail.com> gdb/testsuite/ChangeLog: 2015-04-13 Sergio Durigan Junior <sergiodj@redhat.com> * gdb.base/coredump-filter.exp: Rename variable "addr" to "coredump_var_addr" to avoid naming conflict with other testcases.
2015-04-11Remove --xdbJan Kratochvil22-444/+53
Pedro Alves: The commands that enables aren't even documented in the manual. Judging from that, I assume that only wdb users would ever really be using the --xdb switch. I think it's time to drop "support" for the --xdb switch too. I looked through the commands that that exposes, the only that looked potentially interesting was "go", but then it's just an alias for "tbreak+jump", which can easily be done with "define go...end". I'd rather free up the "go" name for something potentially more interesting (either run control, or maybe even unrelated, e.g., for golang). gdb/ChangeLog 2015-04-11 Jan Kratochvil <jan.kratochvil@redhat.com> * NEWS (Changes since GDB 7.9): Add removed -xdb. * breakpoint.c (command_line_is_silent): Remove xdb_commands conditional. (_initialize_breakpoint): Remove xdb_commands for bc, ab, sb, db, ba and lb. * cli/cli-cmds.c (_initialize_cli_cmds): Remove xdb_commands for v and va. * cli/cli-decode.c (find_command_name_length): Remove xdb_commands conditional. * defs.h (xdb_commands): Remove declaration. * f-valprint.c (_initialize_f_valprint): Remove xdb_commands for lc. * guile/scm-cmd.c (command_classes): Remove xdb from comment. * infcmd.c (run_no_args_command, go_command): Remove. (_initialize_infcmd): Remove xdb_commands for S, go, g, R and lr. * infrun.c (xdb_handle_command): Remove. (_initialize_infrun): Remove xdb_commands for lz and z. * main.c (xdb_commands): Remove variable. (captured_main): Remove "xdb" from long_options. (print_gdb_help): Remove --xdb from help. * python/py-cmd.c (gdbpy_initialize_commands): Remove xdb from comment. * source.c (_initialize_source): Remove xdb_commands for D, ld, / and ?. * stack.c (backtrace_full_command, args_plus_locals_info) (current_frame_command): Remove. (_initialize_stack): Remove xdb_commands for t, T and l. * symtab.c (_initialize_symtab): Remove xdb_commands for lf and lg. * thread.c (_initialize_thread): Remove xdb_commands condition. * tui/tui-layout.c (tui_toggle_layout_command) (tui_toggle_split_layout_command, tui_handle_xdb_layout): Remove. (_initialize_tui_layout): Remove xdb_commands for td and ts. * tui/tui-regs.c (tui_scroll_regs_forward_command) (tui_scroll_regs_backward_command): Remove. (_initialize_tui_regs): Remove xdb_commands for fr, gr, sr, +r and -r. * tui/tui-win.c (tui_xdb_set_win_height_command): Remove. (_initialize_tui_win): Remove xdb_commands for U and w. * utils.c (pagination_on_command, pagination_off_command): Remove. (initialize_utils): Remove xdb_commands for am and sm. gdb/doc/ChangeLog 2015-04-11 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.texinfo (Mode Options): Remove -xdb.
2015-04-10Cleanup signal-while-stepping-over-bp-other-thread.expPedro Alves2-10/+15
gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.threads/signal-while-stepping-over-bp-other-thread.exp: Use gdb_test_sequence and gdb_assert.
2015-04-10step-over-trips-on-watchpoint.exp: Don't put addresses in test messagesPedro Alves2-2/+10
Diffing test results, I noticed: -PASS: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: next: b *0x0000000000400811 thread 1 +PASS: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: next: b *0x00000000004007d1 thread 1 gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.threads/step-over-trips-on-watchpoint.exp (do_test): Use test messages that don't include the breakpoint address.
2015-04-10[arm] watchpoint-reuse-slot.exp: skip setting HW points on some addressYao Qi2-0/+33
Hi, ARM linux kernel has some requirements on the address/length setting for HW breakpoints/watchpoints, but watchpoint-reuse-slot.exp doesn't consider them and sets HW points on various addresses. Many fails are causes as a result: stepi^M Warning:^M Could not insert hardware watchpoint 20.^M Could not insert hardware breakpoints:^M You may have requested too many hardware breakpoints/watchpoints.^M ^M (gdb) FAIL: gdb.base/watchpoint-reuse-slot.exp: always-inserted off: watch x watch: : width 2, iter 2: base + 1: stepi advanced watch *(buf.byte + 2 + 1)@2^M Hardware watchpoint 388: *(buf.byte + 2 + 1)@2^M Warning:^M Could not insert hardware watchpoint 388.^M Could not insert hardware breakpoints:^M You may have requested too many hardware breakpoints/watchpoints.^M ^M (gdb) FAIL: gdb.base/watchpoint-reuse-slot.exp: always-inserted on: watch x watch: : width 2, iter 2: base + 1: watch *(buf.byte + 2 + 1)@2 This patch is to reflect kernel requirements in watchpoint-reuse-slot.exp in order to skip some tests. gdb/testsuite: 2015-04-10 Yao Qi <yao.qi@linaro.org> * gdb.base/watchpoint-reuse-slot.exp (valid_addr_p): Return false for some offset and width combinations which aren't supported by linux kernel.
2015-04-10PPC64: Fix step-over-trips-on-watchpoint.exp with displaced stepping onPedro Alves2-7/+27
PPC64 currently fails this test like: FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: no thread-specific bp: step: step FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: no thread-specific bp: next: next FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: no thread-specific bp: continue: continue (the program exited) FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: step: step FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: next: next FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: continue: continue (the program exited) The problem is that PPC is a non-continuable watchpoints architecture and the displaced stepping code isn't coping with that correctly. On such targets/architectures, a watchpoint traps _before_ the instruction executes/completes. On a watchpoint trap, the PC points at the instruction that triggers the watchpoint (side effects haven't happened yet). In order to move past the watchpoint, GDB needs to remove the watchpoint, single-step, and reinsert the watchpoint, just like when stepping past a breakpoint. The trouble is that if GDB is stepping over a breakpoint with displaced stepping, and the instruction under the breakpoint triggers a watchpoint, we get the watchpoint SIGTRAP, expecting a finished (hard or software) step trap. Even though the thread's PC hasn't advanced yet (must remove watchpoint for that), since we get a SIGTRAP, displaced_step_fixup thinks the single-step finished successfuly anyway, and calls gdbarch_displaced_step_fixup, which then adjusts the thread's registers incorrectly. The fix is to cancel the displaced step if we trip on a watchpoint. handle_inferior_event then processes the watchpoint event, and starts a new step-over, here: ... /* At this point, we are stopped at an instruction which has attempted to write to a piece of memory under control of a watchpoint. The instruction hasn't actually executed yet. If we were to evaluate the watchpoint expression now, we would get the old value, and therefore no change would seem to have occurred. ... ecs->event_thread->stepping_over_watchpoint = 1; keep_going (ecs); return; ... but this time, since we have a watchpoint to step over, watchpoints are removed from the target, so the step-over succeeds. The keep_going/resume changes are necessary because if we're stepping over a watchpoint, we need to remove it from the target - displaced stepping doesn't help, the copy of the instruction in the scratch pad reads/writes to the same addresses, thus triggers the watchpoint too... So without those changes we keep triggering the watchpoint forever, never making progress. With non-stop that means we'll need to pause all threads momentarily, which we can't today. We could avoid that by removing the watchpoint _only_ from the thread that is moving past the watchpoint, but GDB is not prepared for that today either. For remote targets, that would need new packets, so good to be able to step over it in-line as fallback anyway. gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_fixup): Switch to the event ptid earlier. If the thread stopped for a watchpoint and the target/arch has non-continuable watchpoints, cancel the displaced step. (resume): Don't start a displaced step if in-line step-over info is valid.
2015-04-10Test step-over-{lands-on-breakpoint|trips-on-watchpoint}.exp with displaced ↵Pedro Alves3-10/+46
stepping These tests exercise the infrun.c:proceed code that needs to know to start new step overs (along with switch_back_to_stepped_thread, etc.). That code is tricky to get right in the multitude of possible combinations (at least): (native | remote) X (all-stop | all-stop-but-target-always-in-non-stop) X (displaced-stepping | in-line step-over). The first two above are properties of the target, but the different step-over-breakpoint methods should work with any target that supports them. This patch makes sure we always test both methods on all targets. Tested on x86-64 Fedora 20. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.threads/step-over-lands-on-breakpoint.exp (do_test): New procedure, factored out from ... (top level): ... here. Add "set displaced-stepping" testing axis. * gdb.threads/step-over-trips-on-watchpoint.exp (do_test): New parameter "displaced". Use it. (top level): Use foreach and add "set displaced-stepping" testing axis.
2015-04-10Make gdb.threads/step-over-trips-on-watchpoint.exp effective on !x86Pedro Alves3-6/+49
This test is currently failing like this on (at least) PPC64 and s390x: FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: step FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: next: next FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: with thread-specific bp: step: step FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: with thread-specific bp: next: next gdb.log: (gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: set scheduler-locking off step wait_threads () at ../../../src/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c:49 49 return 1; /* in wait_threads */ (gdb) FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: step The problem is that the test assumes that both the "watch_me = 1;" and the "other = 1;" lines compile to a single instruction each, which happens to be true on x86, but no necessarily true everywhere else. The result is that the test doesn't really test what it wants to test. Fix it by looking for the instruction that triggers the watchpoint. gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.threads/step-over-trips-on-watchpoint.c (child_function): Remove comment. * gdb.threads/step-over-trips-on-watchpoint.exp (do_test): Find both the address of the instruction that triggers the watchpoint and the address of the instruction immediately after, and use those addresses for the test. Fix comment.
2015-04-10Fix gdb.base/sigstep.exp with displaced stepping on software single-step targetsPedro Alves4-28/+114
TL;DR: When stepping over a breakpoint with displaced stepping, the core must be notified of all signals, otherwise the displaced step fixup code confuses a breakpoint trap in the signal handler for the expected trap indicating the displaced instruction was single-stepped normally/successfully. Detailed version: Running sigstep.exp with displaced stepping on, against my x86 software single-step branch, I got: FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue Turning on debug logs, we see: (gdb) step infrun: clear_proceed_status_thread (process 32147) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842 displaced: stepping process 32147 now displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 displaced: %rip-relative addressing used. displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00 displaced: displaced pc to 0x400622 displaced: run 0x400622: c7 81 1c 08 LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147 LLR: PTRACE_CONT process 32147, 0 (resume event thread) linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Alarm clock (stopped) LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle') LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) sigchld infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Trace/breakpoint trap (stopped) CSBB: process 32147 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 32147. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 32147.32147.0 [process 32147], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED displaced: restored process 32147 0x400622 displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ... displaced: restoring reg 2 to 0x3615eafd37 displaced: relocated %rip from 0x400717 to 0x400937 infrun: stop_pc = 0x400937 infrun: delayed software breakpoint trap, ignoring infrun: no line number info infrun: stop_waiting 0x0000000000400937 in __dso_handle () 1: x/i $pc => 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1 (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step What should have happened is that the breakpoint hit in the signal handler should have been presented to the user. But note that "preempt 'handle'" -- what happened instead is that displaced_step_fixup confused the breakpoint in the signal handler for the expected SIGTRAP indicating the displaced instruction was single-stepped normally/successfully. This should be affecting all software single-step targets in the same way. The fix is to make sure the core sees all signals when displaced stepping, just like we already must see all signals when doing an stepping over a breakpoint in-line. We now get: infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM infrun: TARGET_WAITKIND_STOPPED displaced: restored process 570 0x400622 infrun: stop_pc = 0x400842 infrun: random signal (GDB_SIGNAL_ALRM) infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x400842 infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842 LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570 LLR: PTRACE_CONT process 570, Alarm clock (resume event thread) infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore sigchld infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 570, No child processes LLW: waitpid 570 received Trace/breakpoint trap (stopped) CSBB: process 570 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 570. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400717 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_waiting Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; Hardware single-step targets already behave this way, because the Linux backends (both native and gdbserver) always report signals to the core if the thread was single-stepping. As mentioned in the new comment in do_target_resume, we can't fix this by instead making the displaced_step_fixup phase skip fixing up the PC if the single step stopped somewhere we didn't expect. Here's what the backtrace would look like if we did that: Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; 1: x/i $pc => 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done> (gdb) bt #0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 #1 <signal handler called> #2 0x0000000000400622 in _start () (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_in_progress): New function. (do_target_resume): Advise target to report all signals if displaced stepping. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp (breakpoint_to_handler) (breakpoint_to_handler_entry): New parameter 'displaced'. Use it. Test "backtrace" in handler. (breakpoint_over_handler): New parameter 'displaced'. Use it. (top level): Add new "displaced" test axis to breakpoint_to_handler, breakpoint_to_handler_entry and breakpoint_over_handler.
2015-04-10gdb/18216: displaced step+deliver signal, a thread needs step-over, crashPedro Alves4-8/+13
The problem is that with hardware step targets and displaced stepping, "signal FOO" when stopped at a breakpoint steps the breakpoint instruction at the same time it delivers a signal. This results in tp->stepped_breakpoint set, but no step-resume breakpoint set. When the next stop event arrives, GDB crashes. Irrespective of whether we should do something more/different to step past the breakpoint in this scenario (e.g., PR 18225), it's just wrong to assume there'll be a step-resume breakpoint set (and was not the original intention). gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> PR gdb/18216 * infrun.c (process_event_stop_test): Don't assume a step-resume is set if tp->stepped_breakpoint is true. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> PR gdb/18216 * gdb.threads/multiple-step-overs.exp: Remove expected eof.
2015-04-10[arm] Fix displaced stepping for thumb alu reg instructionYao Qi5-10/+83
Recent patch series "V2 All-stop on top of non-stop" causes a SIGSEGV in the test case, > -PASS: gdb.base/info-shared.exp: continue to breakpoint: library function #4 > +FAIL: gdb.base/info-shared.exp: continue to breakpoint: library function #4 > > continue^M > Continuing.^M > ^M > Program received signal SIGSEGV, Segmentation fault.^M > 0x40021564 in ?? () gdb/testsuite/gdb.base/info-shared-solib1.so^M > (gdb) FAIL: gdb.base/info-shared.exp: continue to breakpoint: library function #4 and an ARM displaced stepping bug is exposed. It can be reproduced by the modified gdb.arch/arm-disp-step.exp as below, continue^M Continuing.^M ^M Program received signal SIGSEGV, Segmentation fault.^M 0xa713cfcc in ?? ()^M (gdb) FAIL: gdb.arch/arm-disp-step.exp: continue to breakpoint: continue to test_add_rn_pc_end This patch is to fix it. gdb: 2015-04-10 Yao Qi <yao.qi@linaro.org> * arm-tdep.c (install_alu_reg): Update comment. (thumb_copy_alu_reg): Remove local variable rn. Update debugging message. Use r2 instead of r1 in the modified instruction. gdb/testsuite: 2015-04-10 Yao Qi <yao.qi@linaro.org> * gdb.arch/arm-disp-step.S (main): Call test_add_rn_pc. (test_add_rn_pc): New function. * gdb.arch/arm-disp-step.exp (test_add_rn_pc): New proc. (top level): Invoke test_add_rn_pc.
2015-04-10PR13858 - Can't do displaced stepping with no symbolsPedro Alves10-54/+162
Running break-interp.exp with the target always in non-stop mode trips on PR13858, as enabling non-stop also enables displaced stepping. The problem is that when GDB doesn't know where the entry point is, it doesn't know where to put the displaced stepping scratch pad. The test added by this commit exercises this. Without the fix, we get: (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=on: break *$pc set displaced-stepping on (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=on: set displaced-stepping on stepi 0x00000000004005be in ?? () Entry point address is not known. (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=on: stepi p /x $pc $2 = 0x4005be (gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=on: get after PC FAIL: gdb.base/step-over-no-symbols.exp: displaced=on: advanced The fix switches all GNU/Linux ports to get the entry point from AT_ENTRY in the target auxiliary vector instead of from symbols. This is currently only done by PPC when Cell debugging is enabled, but I think all archs should be able to do the same. Note that ppc_linux_displaced_step_location cached the result, I'm guessing to avoid constantly re-fetching the auxv out of remote targets, but that's no longer necessary nowadays, as the auxv blob is itself cached in the inferior object. The ppc_linux_entry_point_addr global is obviously bad for multi-process too nowadays. Tested on x86-64 (-m64/-m32), PPC64 (-m64/-m32) and S/390 GNU/Linux. Yao tested the new test on ARM as well. gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> PR gdb/13858 * amd64-linux-tdep.c (amd64_linux_init_abi_common): Install linux_displaced_step_location as gdbarch_displaced_step_location hook. * arm-linux-tdep.c (arm_linux_init_abi): Likewise. * i386-linux-tdep.c (i386_linux_init_abi): Likewise. * linux-tdep.c (linux_displaced_step_location): New function, based on ppc_linux_displaced_step_location. * linux-tdep.h (linux_displaced_step_location): New declaration. * ppc-linux-tdep.c (ppc_linux_entry_point_addr): Delete. (ppc_linux_inferior_created, ppc_linux_displaced_step_location): Delete. (ppc_linux_init_abi): Install linux_displaced_step_location as gdbarch_displaced_step_location hook, even without Cell/B.E.. (_initialize_ppc_linux_tdep): Don't install ppc_linux_inferior_created as inferior_created observer. * s390-linux-tdep.c (s390_gdbarch_init): Install linux_displaced_step_location as gdbarch_displaced_step_location hook. gdb/testsuite/ 2015-04-10 Pedro Alves <palves@redhat.com> PR gdb/13858 * gdb.base/step-over-no-symbols.exp: New file.
2015-04-10doc patch: compile: missing bitsJan Kratochvil2-0/+86
gdb/doc/ChangeLog 2015-04-10 Jan Kratochvil <jan.kratochvil@redhat.com> Eli Zaretskii <eliz@gnu.org> * gdb.texinfo (Compiling and Injecting Code): Describe set debug compile, show debug compile. New subsection Compilation options for the compile command. New subsection Compiler search for the compile command.
2015-04-09Rename common-remote-fileio.[ch] as fileio.[ch]Gary Benson10-73/+98
This commit renames common-remote-fileio.[ch] as fileio.[ch] and renames all functions in these files. gdb/ChangeLog: * common/common-remote-fileio.h: Rename to... * common/fileio.h: ...this. Update all references. (remote_fileio_to_fio_error): Rename to... (host_to_fileio_error): ...this. (remote_fileio_to_be): Rename to... (host_to_bigendian): ...this. Update all callers. (remote_fileio_to_fio_uint): Rename to... (host_to_fileio_uint): ...this. Update all callers. (remote_fileio_to_fio_time): Rename to... (host_to_fileio_time): ...this. Update all callers. (remote_fileio_to_fio_stat): Rename to... (host_to_fileio_stat): ...this. Update all references. * common/common-remote-fileio.c: Rename to... * common/fileio.c: ...this. Update all references. (remote_fileio_to_fio_error): Rename to... (host_to_fileio_error): ...this. Update all callers. (remote_fileio_mode_to_target): Rename to... (fileio_mode_pack): ...this. Update all callers. (remote_fileio_to_fio_mode): Rename to... (host_to_fileio_mode): ...this. Update all callers. (remote_fileio_to_fio_ulong): Rename to... (host_to_fileio_ulong): ...this. Update all callers. (remote_fileio_to_fio_stat): Rename to... (host_to_fileio_stat): ...this. Update all callers.
2015-04-09Add Guile frame-read-register commandAndy Wingo7-0/+103
gdb/ChangeLog: * guile/scm-frame.c (gdbscm_frame_read_register): New function. (frame_functions): Bind gdbscm_frame_read_register to frame-read-register. * guile/lib/gdb.scm (frame-read-register): Export. gdb/doc/ChangeLog: * guile.texi (Frames In Guile): Describe frame-read-register. gdb/testsuite/ChangeLog: * gdb.guile/scm-frame.exp: Add frame-read-register tests, modelled after the Python tests.
2015-04-09Introduce new shared function remote_fileio_to_fio_errorGary Benson7-165/+86
This commit introduces a new shared function to replace three identical functions in various places in the codebase. gdb/ChangeLog: * common/common-remote-fileio.h (remote_fileio_to_fio_error): New declaration. * common/common-remote-fileio.c (remote_fileio_to_fio_error): New function, factored out the named functions below. * inf-child.c (gdb/fileio.h): Remove include. (common-remote-fileio.h): New include. (inf_child_errno_to_fileio_error): Remove function. Update all callers to use remote_fileio_to_fio_error. * remote-fileio.c (remote_fileio_errno_to_target): Likewise. gdb/gdbserver/ChangeLog: * hostio-errno.c (errno_to_fileio_error): Remove function. Update caller to use remote_fileio_to_fio_error.
generated by cgit v1.1 at 2024-12-14 17:49:14 +0000