OpenE2K
/
binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
binutils-gdb/gdb/testsuite/ChangeLog

4803 lines
155 KiB
Plaintext
Raw Normal View History

Fix {mi-tracepoint-changed, mi-tsv-changed}.exp with native-extended-gdbserver 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-16 13:23:26 +02:00
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.
Fix gdbserver_reconnect_p handling 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-16 15:26:59 +02:00
2015-04-16 Pedro Alves <palves@redhat.com>
* lib/gdbserver-support.exp (gdb_exit): If gdbserver_reconnect_p
is set, don't exit gdbserver.
s390-vregs.exp: Avoid compile errors with older GCCs and on 31-bit targets 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-16 13:03:48 +02:00
2015-04-16 Andreas Arnez <arnez@linux.vnet.ibm.com>
* 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.
GDB tests for Go language support: remove unnecessary first breakpoint 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-16 13:03:47 +02:00
2015-04-16 Andreas Arnez <arnez@linux.vnet.ibm.com>
* 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".
Some Python 3 fixes 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 17:54:33 +02:00
2015-04-15 Simon Marchi <simon.marchi@ericsson.com>
* 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.
Fix fails in gdb.dwarf2/dynarr-ptr.exp 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-15 15:04:40 +02:00
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.
Increase timeout in watch-bitfields.exp for software watchpoint 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-15 13:46:58 +02:00
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.
Harden gdb.base/bp-permanent.exp 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-14 14:22:53 +02:00
2015-04-14 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/bp-permanent.exp (test): Reinstate correct test message.
Harden gdb.base/bp-permanent.exp 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-13 19:45:56 +02:00
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.
Harden gdb.base/coredump-filter.exp 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-13 19:42:48 +02:00
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.
Catch exception in lib/gdbserver-support.exp:gdb_exit 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-13 13:36:56 +02:00
2015-04-13 Yao Qi <yao.qi@linaro.org>
* lib/gdbserver-support.exp (gdb_exit): Catch exception
and use expect instead of gdb_expect.
Rename variable "addr" to "coredump_var_addr" in gdb.base/coredump-filter.exp 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-13 08:40:08 +02:00
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.
Cleanup signal-while-stepping-over-bp-other-thread.exp 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-03-09 20:02:30 +01:00
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.
step-over-trips-on-watchpoint.exp: Don't put addresses in test messages 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 20:23:24 +02:00
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.
[arm] watchpoint-reuse-slot.exp: skip setting HW points on some address 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-10 17:23:13 +02:00
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.
Test step-over-{lands-on-breakpoint|trips-on-watchpoint}.exp with displaced 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-10 16:22:38 +02:00
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.
Make gdb.threads/step-over-trips-on-watchpoint.exp effective on !x86 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-10 14:11:32 +02:00
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.
Fix gdb.base/sigstep.exp with displaced stepping on software single-step targets 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-10 11:55:09 +02:00
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.
gdb/18216: displaced step+deliver signal, a thread needs step-over, crash 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 11:36:23 +02:00
2015-04-10 Pedro Alves <palves@redhat.com>
PR gdb/18216
* gdb.threads/multiple-step-overs.exp: Remove expected eof.
[arm] Fix displaced stepping for thumb alu reg instruction 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-10 11:33:01 +02:00
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.
PR13858 - Can't do displaced stepping with no symbols 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-10 11:07:02 +02:00
2015-04-10 Pedro Alves <palves@redhat.com>
PR gdb/13858
* gdb.base/step-over-no-symbols.exp: New file.
Add Guile frame-read-register command 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-09 14:06:41 +02:00
2015-04-09 Andy Wingo <wingo@igalia.com>
* gdb.guile/scm-frame.exp: Add frame-read-register tests, modelled
after the Python tests.
Fix Python completion when using the "complete" command This patch is related to PR python/16699, and is an improvement over the patch posted here: <https://sourceware.org/ml/gdb-patches/2014-03/msg00301.html> Keith noticed that, when using the "complete" command on GDB to complete a Python command, some strange things could happen. In order to understand what can go wrong, I need to explain how the Python completion mechanism works. When the user requests a completion of a Python command by using TAB, GDB will first try to determine the right set of "brkchars" that will be used when doing the completion. This is done by actually calling the "complete" method of the Python class. Then, when we already know the "brkchars" that will be used, we call the "complete" method again, for the same values. If you read the thread mentioned above, you will see that one of the design decisions was to make the "cmdpy_completer_helper" (which is the function the does the actual calling of the "complete" method) cache the first result of the completion, since this result will be used in the second call, to do the actual completion. The problem is that the "complete" command does not process the brkchars, and the current Python completion mechanism (improved by the patch mentioned above) relies on GDB trying to determine the brkchars, and then doing the completion itself. Therefore, when we use the "complete" command instead of doing a TAB-completion on GDB, there is a scenario where we can use the invalid cache of a previous Python command that was completed before. For example: (gdb) A <TAB> (gdb) complete B B value1 B value10 B value2 B value3 B value4 B value5 B value6 B value7 B value8 B value9 (gdb) B <TAB> comp1 comp2 comp4 comp6 comp8 comp10 comp3 comp5 comp7 comp9 Here, we see that "complete B " gave a different result than "B <TAB>". The reason for that is because "A <TAB>" was called before, and its completion results were "value*", so when GDB tried to "complete B " it wrongly answered with the results for A. The problem here is using a wrong cache (A's cache) for completing B. We tried to come up with a solution that would preserve the caching mechanism, but it wasn't really possible. So I decided to completely remove the cache, and doing the method calling twice for every completion. This is not optimal, but I do not think it will impact users noticeably. It is worth mentioning another small issue that I found. The code was doing: wordobj = PyUnicode_Decode (word, sizeof (word), host_charset (), NULL); which is totally wrong, because using "sizeof" here will lead to always the same result. So I changed this to use "strlen". The testcase also catches this problem. Keith kindly expanded the existing testcase to cover the problem described above, and everything is passing. gdb/ChangeLog: 2015-04-08 Sergio Durigan Junior <sergiodj@redhat.com> PR python/16699 * python/py-cmd.c (cmdpy_completer_helper): Adjust function to not use a caching mechanism. Adjust comments and code to reflect that. Replace 'sizeof' by 'strlen' when fetching 'wordobj'. (cmdpy_completer_handle_brkchars): Adjust call to cmdpy_completer_helper. Call Py_XDECREF for 'resultobj'. (cmdpy_completer): Likewise. gdb/testsuite/ChangeLog: 2015-04-08 Keith Seitz <keiths@redhat.com> PR python/16699 * gdb.python/py-completion.exp: New tests for completion. * gdb.python/py-completion.py (CompleteLimit1): New class. (CompleteLimit2): Likewise. (CompleteLimit3): Likewise. (CompleteLimit4): Likewise. (CompleteLimit5): Likewise. (CompleteLimit6): Likewise. (CompleteLimit7): Likewise.
2015-04-09 00:27:10 +02:00
2015-04-08 Keith Seitz <keiths@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New tests for completion.
* gdb.python/py-completion.py (CompleteLimit1): New class.
(CompleteLimit2): Likewise.
(CompleteLimit3): Likewise.
(CompleteLimit4): Likewise.
(CompleteLimit5): Likewise.
(CompleteLimit6): Likewise.
(CompleteLimit7): Likewise.
Add test for PR18214 and PR18216 - multiple step-overs with queued signals Both PRs are triggered by the same use case. PR18214 is about software single-step targets. On those, the 'resume' code that detects that we're stepping over a breakpoint and delivering a signal at the same time: /* Currently, our software single-step implementation leads to different results than hardware single-stepping in one situation: when stepping into delivering a signal which has an associated signal handler, hardware single-step will stop at the first instruction of the handler, while software single-step will simply skip execution of the handler. ... Fortunately, we can at least fix this particular issue. We detect here the case where we are about to deliver a signal while software single-stepping with breakpoints removed. In this situation, we revert the decisions to remove all breakpoints and insert single- step breakpoints, and instead we install a step-resume breakpoint at the current address, deliver the signal without stepping, and once we arrive back at the step-resume breakpoint, actually step over the breakpoint we originally wanted to step over. */ doesn't handle the case of _another_ thread also needing to step over a breakpoint. Because the other thread is just resumed at the PC where it had stopped and a breakpoint is still inserted there, the thread immediately re-traps the same breakpoint. This test exercises that. On software single-step targets, it fails like this: KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr3: continue to sigusr1_handler KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr2: continue to sigusr1_handler gdb.log (simplified): (gdb) continue Continuing. Breakpoint 4, child_function_2 (arg=0x0) at src/gdb/testsuite/gdb.threads/multiple-step-overs.c:66 66 callme (); /* set breakpoint thread 2 here */ (gdb) thread 3 (gdb) queue-signal SIGUSR1 (gdb) thread 1 [Switching to thread 1 (Thread 0x7ffff7fc1740 (LWP 24824))] #0 main () at src/gdb/testsuite/gdb.threads/multiple-step-overs.c:106 106 wait_threads (); /* set wait-threads breakpoint here */ (gdb) break sigusr1_handler Breakpoint 5 at 0x400837: file src/gdb/testsuite/gdb.threads/multiple-step-overs.c, line 31. (gdb) continue Continuing. [Switching to Thread 0x7ffff7fc0700 (LWP 24828)] Breakpoint 4, child_function_2 (arg=0x0) at src/gdb/testsuite/gdb.threads/multiple-step-overs.c:66 66 callme (); /* set breakpoint thread 2 here */ (gdb) KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr3: continue to sigusr1_handler For good measure, I made the test try displaced stepping too. And then I found it crashes GDB on x86-64 (a hardware step target), but only when displaced stepping... : KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr1: continue to sigusr1_handler (PRMS: gdb/18216) KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr2: continue to sigusr1_handler (PRMS: gdb/18216) KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr3: continue to sigusr1_handler (PRMS: gdb/18216) Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000062a83a in process_event_stop_test (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4964 4964 if (sr_bp->loc->permanent Setting up the environment for debugging gdb. Breakpoint 1 at 0x79fcfc: file src/gdb/common/errors.c, line 54. Breakpoint 2 at 0x50a26c: file src/gdb/cli/cli-cmds.c, line 217. (top-gdb) p sr_bp $1 = (struct breakpoint *) 0x0 (top-gdb) bt #0 0x000000000062a83a in process_event_stop_test (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4964 #1 0x000000000062a1af in handle_signal_stop (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4715 #2 0x0000000000629097 in handle_inferior_event (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4165 #3 0x0000000000627482 in fetch_inferior_event (client_data=0x0) at src/gdb/infrun.c:3298 #4 0x000000000064ad7b in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at src/gdb/inf-loop.c:56 #5 0x00000000004c375f in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4658 #6 0x0000000000648c47 in handle_file_event (file_ptr=0x2e0eaa0, ready_mask=1) at src/gdb/event-loop.c:658 The all-stop-non-stop series fixes this, but meanwhile, this augments the multiple-step-overs.exp test to cover this, KFAILed. gdb/testsuite/ChangeLog: 2015-04-08 Pedro Alves <palves@redhat.com> PR gdb/18214 PR gdb/18216 * gdb.threads/multiple-step-overs.c (sigusr1_handler): New function. (main): Install it as SIGUSR1 handler. * gdb.threads/multiple-step-overs.exp (setup): Remove 'prefix' parameter. Always use "setup" as prefix. Toggle "set displaced-stepping" off/on depending on global. Don't switch to thread 1 here. (top level): Add displaced stepping "off/on" test axis. Update "setup" calls. Wrap each subtest with with_test_prefix. Test continuing with a queued signal in each thread.
2015-04-08 20:59:03 +02:00
2015-04-08 Pedro Alves <palves@redhat.com>
PR gdb/18214
PR gdb/18216
* gdb.threads/multiple-step-overs.c (sigusr1_handler): New
function.
(main): Install it as SIGUSR1 handler.
* gdb.threads/multiple-step-overs.exp (setup): Remove 'prefix'
parameter. Always use "setup" as prefix. Toggle "set
displaced-stepping" off/on depending on global. Don't switch to
thread 1 here.
(top level): Add displaced stepping "off/on" test axis. Update
"setup" calls. Wrap each subtest with with_test_prefix. Test
continuing with a queued signal in each thread.
Fix gdb.trace/{actions,infotrace,while-stepping}.exp with extended-remote The recent actions.exp change to check gdb_run_cmd succeeded caught further problems. The test now fails like this with --target_board=native-extended-gdbserver: FAIL: gdb.trace/actions.exp: Can't run to main gdb.log shows: (gdb) run Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.trace/actions Running the default executable on the remote target failed; try "set remote exec-file"? (gdb) FAIL: gdb.trace/actions.exp: Can't run to main The problem is that a gdb_load call is missing. Grepping around for similar problems in other tests, I found that infotrace.exp and while-stepping.exp should be likewise affected. And indeed this is what we get today: FAIL: gdb.trace/infotrace.exp: tstart FAIL: gdb.trace/infotrace.exp: continue to end (the program is no longer running) FAIL: gdb.trace/infotrace.exp: tstop FAIL: gdb.trace/infotrace.exp: 2.6: info tracepoints (trace buffer usage) FAIL: gdb.trace/while-stepping.exp: tstart FAIL: gdb.trace/while-stepping.exp: tstop FAIL: gdb.trace/while-stepping.exp: tfile: info tracepoints FAIL: gdb.trace/while-stepping.exp: ctf: info tracepoints while-stepping.exp even has the same race bug actions.exp had. After this, {actions,infotrace,while-stepping}.exp all pass cleanly with the native-extended-gdbserver board. gdb/testsuite/ChangeLog: 2015-04-08 Pedro Alves <palves@redhat.com> * gdb.trace/actions.exp: Use gdb_load before gdb_run_cmd. * gdb.trace/infotrace.exp: Use gdb_load before gdb_run_cmd. Use gdb_breakpoint instead of gdb_test that doesn't expect anything. Return early if running to main fails. * gdb.trace/while-stepping.exp: Likewise.
2015-04-08 11:39:43 +02:00
2015-04-08 Pedro Alves <palves@redhat.com>
* gdb.trace/actions.exp: Use gdb_load before gdb_run_cmd.
* gdb.trace/infotrace.exp: Use gdb_load before gdb_run_cmd. Use
gdb_breakpoint instead of gdb_test that doesn't expect anything.
Return early if running to main fails.
* gdb.trace/while-stepping.exp: Likewise.
gdb.base/interrupt.exp: Use send_inferior/$inferior_spawn_id The gdb.base/interrupt.exp test is important for testing system call restarting, but because it depends on inferior I/O, it ends up skipped against gdbserver. This patch adjusts the test to use send_inferior and $inferior_spawn_id so it works against GDBserver. gdb/testsuite/ChangeLog: 2015-04-07 Pedro Alves <palves@redhat.com> * gdb.base/interrupt.exp: Don't skip if $inferior_spawn_id != $gdb_spawn_id. Use send_inferior and $inferior_spawn_id to interact with inferior program.
2015-04-07 19:19:31 +02:00
2015-04-07 Pedro Alves <palves@redhat.com>
* gdb.base/interrupt.exp: Don't skip if $inferior_spawn_id !=
$gdb_spawn_id. Use send_inferior and $inferior_spawn_id to
interact with inferior program.
testsuite: Introduce $inferior_spawn_id Some important tests, like gdb.base/interrupt.exp end up skipped against gdbserver, because they depend on inferior I/O, which gdbserver doesn't do. This patch adds a mechanism that makes it possible to make them work. It adds a new "inferior_spawn_id" global that is the spawn ID used for I/O interaction with the inferior. By default, for native targets, or remote targets that can do I/O through GDB (semi-hosting) this will be the same as the gdb/host spawn ID. Otherwise, the board may set this to some other spawn ID. When debugging with GDBserver, this will be set to GDBserver's spawn ID. Then tests can use send_inferior instead of send_gdb to send input to the inferior, and use expect's "-i" switch to select which spawn ID to use for matching input/output. That is, something like this will now work: send_inferior "echo me\n" gdb_test_multiple "continue" "test msg" { -i "$inferior_spawn_id" -re "echo me\r\necho\r\n" { ... } } Or even: gdb_test_multiple "continue" "test msg" { -i "$inferior_spawn_id" -re "hello world" { ... } -i "$gdb_spawn_id" -re "error.*$gdb_prompt $" { ... } } Of course, by default, gdb_test_multiple still matches with $gdb_spawn_id. gdb/testsuite/ChangeLog: 2015-04-07 Pedro Alves <palves@redhat.com> * lib/gdb.exp (inferior_spawn_id): New global. (gdb_test_multiple): Handle "-i". Reset the spawn id to GDB's spawn id after processing the user code. (default_gdb_start): Set inferior_spawn_id. (send_inferior): New procedure. * lib/gdbserver-support.exp (gdbserver_start): Set inferior_spawn_id. (close_gdbserver, gdb_exit): Unset inferior_spawn_id.
2015-04-07 19:19:30 +02:00
2015-04-07 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (inferior_spawn_id): New global.
(gdb_test_multiple): Handle "-i". Reset the spawn id to GDB's
spawn id after processing the user code.
(default_gdb_start): Set inferior_spawn_id.
(send_inferior): New procedure.
* lib/gdbserver-support.exp (gdbserver_start): Set
inferior_spawn_id.
(close_gdbserver, gdb_exit): Unset inferior_spawn_id.
testsuite: Don't use expect_background to reap gdbserver I adjusted a test to do 'expect -i $server_spawn_id -re ...', and saw really strange behavior. Whether that expect would work, depended on whether GDB would also send output and the same expect matched it too (on $gdb_spawn_id). I was perplexed until I noticed that gdbserver_spawn spawns gdbserver and then uses expect_background to reap gdbserver. That expect_background conflicts/races with any "expect -i $server_spawn_id" done anywhere else in parallel... In order to make it possible for tests to read inferior I/O out of $server_spawn_id, we to get rid of that expect_background. This patch makes us instead reap gdbserver's spawn id when GDB exits. If GDB is still around, this gives a chance for gdbserver to exit cleanly. The current code in gdb_finish uses "kill", but that doesn't work with extended-remote (gdbserver doesn't exit). We now use "monitor exit" instead which works in both remote and extended-remote modes. gdb/testsuite/ChangeLog: 2015-04-07 Pedro Alves <palves@redhat.com> * lib/gdb.exp (gdb_finish): Delete persistent gdbserver handling. * lib/gdbserver-support.exp (gdbserver_start): Make $server_spawn_id global. (gdbserver_start): Don't wait for gdbserver's spawn id with expect_background. (close_gdbserver): New procedure. (gdb_exit): Rename the default version and reimplement.
2015-04-07 19:19:30 +02:00
2015-04-07 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_finish): Delete persistent gdbserver handling.
* lib/gdbserver-support.exp (gdbserver_start): Make
$server_spawn_id global.
(gdbserver_start): Don't wait for gdbserver's spawn id with
expect_background.
(close_gdbserver): New procedure.
(gdb_exit): Rename the default version and reimplement.
gdb_test_multiple: Fix user code argument processing While teaching gdb_test_multiple to forward "-i" to gdb_expect, I found that with: gdb_test_multiple (...) { -i $some_variable -re "..." {} } $some_variable was not getting expanded in the gdb_test_multiple caller's scope. This is a bug inside gdb_test_multiple. When processing an argument in passed in user code, it was appending the original argument literally, instead of appending the uplist'ed argument. gdb/testsuite/ChangeLog: 2015-04-07 Pedro Alves <palves@redhat.com> * lib/gdb.exp (gdb_test_multiple): When processing an argument, append the substituted item, not the original item.
2015-04-07 19:19:30 +02:00
2015-04-07 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_test_multiple): When processing an argument,
append the substituted item, not the original item.
gdb.base/interrupt.exp: Use gdb_test_multiple instead of gdb_expect gdb/testsuite/ChangeLog: 2015-04-07 Pedro Alves <palves@redhat.com> * gdb.base/interrupt.exp: Use gdb_test_multiple instead of gdb_expect.
2015-04-07 19:19:29 +02:00
2015-04-07 Pedro Alves <palves@redhat.com>
* gdb.base/interrupt.exp: Use gdb_test_multiple instead of
gdb_expect.
gdb.base/interrupt.exp: Fix race Working on splitting gdb and inferior output handling in this test, I noticed a race that happens to be masked out today. The test sends "a\n" to the inferior, and then inferior echoes back "a\n". If expect manages to read only the first "a\r\n" into its buffer, then this matches: -re "^a\r\n(|a\r\n)$" { and leaves the second "a\r\n" in output. Then the next test that processes inferior I/O sends "data\n", and expects: -re "^(\r\n|)data\r\n(|data\r\n)$" which fails given the anchor and given "a\r\n" is still in the buffer. This is masked today because the test relies on inferior I/O being done on GDB's terminal, and there are tested GDB commands in between, which consume the "a\r\n" that was left in the output. We don't support SunOS4 anymore, so just remove the workaround. gdb/testsuite/ChangeLog 2015-04-07 Pedro Alves <palves@redhat.com> * gdb.base/interrupt.exp: Don't handle the case of the inferior output appearing once only.
2015-04-07 19:19:29 +02:00
2015-04-07 Pedro Alves <palves@redhat.com>
* gdb.base/interrupt.exp: Don't handle the case of the inferior
output appearing once only.
Fix gdb.trace/actions.exp race I saw this on PPC64 once: not installed on target (gdb) PASS: gdb.trace/actions.exp: 5.10a: verify teval actions set for two tracepoints break main Breakpoint 4 at 0x10000c6c: file ../../../src/gdb/testsuite/gdb.trace/actions.c, line 139. (gdb) PASS: gdb.trace/actions.exp: break main run Starting program: /home/palves/gdb/build/gdb/testsuite/outputs/gdb.trace/actions/actions tstatus Breakpoint 4, main (argc=1, argv=0x3fffffffebb8, envp=0x3fffffffebc8) at ../../../src/gdb/testsuite/gdb.trace/actions.c:139 139 begin (); (gdb) tstatus Trace can not be run on this target. (gdb) actions 1 Enter actions for tracepoint 1, one per line. End with a line saying just "end". >collect $regs >end (gdb) PASS: gdb.trace/actions.exp: set actions for first tracepoint tstart You can't do that when your target is `native' (gdb) FAIL: gdb.trace/actions.exp: tstart info tracepoints 1 Num Type Disp Enb Address What 1 tracepoint keep y 0x00000000100007c8 in gdb_c_test at ../../../src/gdb/testsuite/gdb.trace/actions.c:74 collect $regs not installed on target ... followed by a cascade of FAILs. The "tstatus" was supposed to detect that this target (native) can't do tracepoints, but, alas, it didn't. That detection failed because 'gdb_test "break main"' doesn't expect anything, and then the output was slow enough that 'gdb_test "" "Breakpoint .*"' matched the output of "break main"... The fix is to use gdb_breakpoint instead. Also check the result of gdb_test while at it. Tested on x86-64 Fedora 20, native and gdbserver. gdb/testsuite/ChangeLog: 2015-04-07 Pedro Alves <palves@redhat.com> * gdb.trace/actions.exp: Use gdb_breakpoint instead of gdb_test that doesn't expect anything. Return early if running to main fails.
2015-03-05 23:01:06 +01:00
2015-04-07 Pedro Alves <palves@redhat.com>
* gdb.trace/actions.exp: Use gdb_breakpoint instead of gdb_test
that doesn't expect anything. Return early if running to main
fails.
Properly set alarm value in gdb.threads/non-stop-fair-events.exp Nowadays, the alarm value is 60, and alarm is generated on some slow boards. This patch is to pass DejaGNU timeout value to the program, and move the alarm call before going to infinite loop. If any thread has activities, the alarm is reset. gdb/testsuite: 2015-04-07 Yao Qi <yao.qi@linaro.org> * gdb.threads/non-stop-fair-events.c (SECONDS): New macro. (child_function): Call alarm. (main): Move call to alarm into the loop. * gdb.threads/non-stop-fair-events.exp: Build program with -DTIMEOUT=$timeout.
2015-04-07 12:30:07 +02:00
2015-04-07 Yao Qi <yao.qi@linaro.org>
* gdb.threads/non-stop-fair-events.c (SECONDS): New macro.
(child_function): Call alarm.
(main): Move call to alarm into the loop.
* gdb.threads/non-stop-fair-events.exp: Build program with
-DTIMEOUT=$timeout.
* lib/pascal.exp (gpc_compile): Rename dest arg to destfile. The "dest" parameter to fpc_compile/gpc_compile is the name of compilation destination file, not a board name. This patch fixes this by using names consistent with lib/future.exp:gdb_default_target_compile. gdb/testsuite/ChangeLog: * lib/pascal.exp (gpc_compile): Rename dest arg to destfile. Fix dest parameter to board_info. (fpc_compile): Ditto. (gdb_compile_pascal): Rename dest arg to destfile.
2015-04-06 17:45:06 +02:00
2015-04-06 Doug Evans <xdje42@gmail.com>
* lib/pascal.exp (gpc_compile): Rename dest arg to destfile.
Fix dest parameter to board_info.
(fpc_compile): Ditto.
(gdb_compile_pascal): Rename dest arg to destfile.
Do not consider reference types as dynamic Even when referenced types are dynamic, the corresponding referencing type should not be considered as dynamic: it's only a pointer. This prevents reference type for values not in memory to be resolved. gdb/ChangeLog: * gdbtypes.c (is_dynamic_type_internal): Remove special handling of TYPE_CODE_REF types so that they are not considered as dynamic depending on the referenced type. (resolve_dynamic_type_internal): Likewise. gdb/testsuite/ChangeLog: * gdb.ada/funcall_ref.exp: New file. * gdb.ada/funcall_ref/foo.adb: New file.
2015-04-03 10:40:52 +02:00
2015-04-03 Pierre-Marie de Rodat <derodat@adacore.com>
* gdb.ada/funcall_ref.exp: New file.
* gdb.ada/funcall_ref/foo.adb: New file.
kfail two tests in no-unwaited-for-left.exp for remote target I see these two fails in no-unwaited-for-left.exp in remote testing for aarch64-linux target. ... continue Continuing. warning: Remote failure reply: E.No unwaited-for children left. [Thread 1084] #2 stopped. (gdb) FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when thread 2 exits .... continue Continuing. warning: Remote failure reply: E.No unwaited-for children left. [Thread 1081] #1 stopped. (gdb) FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits I checked the gdb.log on buildbot, and find that these two fails also appear on Debian-i686-native-extended-gdbserver and Fedora-ppc64be-native-gdbserver-m64. I recall that they are about local/remote parity, and related RSP is missing. There has been already a PR 14618 about it. This patch is to kfail them on remote target. gdb/testsuite: 2015-04-02 Yao Qi <yao.qi@linaro.org> * gdb.threads/no-unwaited-for-left.exp: Set up kfail if target is remote.
2015-04-02 14:51:31 +02:00
2015-04-02 Yao Qi <yao.qi@linaro.org>
* gdb.threads/no-unwaited-for-left.exp: Set up kfail if target
is remote.
Make the default sysroot be "target:" This commit makes GDB default to a sysroot of "target:". One testcase needed updating as a result of this change. gdb/ChangeLog: * main.c (captured_main): Set gdb_sysroot to "target:" if not otherwise set. gdb/testsuite/ChangeLog: * gdb.base/break-probes.exp: Cope with "target:" sysroot.
2015-04-02 14:38:29 +02:00
2015-04-02 Gary Benson <gbenson@redhat.com>
* gdb.base/break-probes.exp: Cope with "target:" sysroot.
Add support for writing unwinders in Python. gdb/ChangeLog: * Makefile.in (SUBDIR_PYTHON_OBJS): Add py-unwind.o. (SUBDIR_PYTHON_SRCS): Add py-unwind.c. (py-unwind.o): New recipe. * NEWS: mention Python frame unwinding. * data-directory/Makefile.in (PYTHON_FILE_LIST): Add gdb/unwinder.py and gdb/command/unwinder.py * python/lib/gdb/__init__.py (packages): Add frame_unwinders list. (execute_unwinders): New function. * python/lib/gdb/command/unwinders.py: New file. * python/lib/gdb/unwinder.py: New file. * python/py-objfile.c (objfile_object): Add frame_unwinders field. (objfpy_dealloc): Decrement frame_unwinders reference count. (objfpy_initialize): Create frame_unwinders list. (objfpy_get_frame_unwinders): New function. (objfpy_set_frame_unwinders): Ditto. (objfile_getset): Add frame_unwinders attribute to Objfile. * python/py-progspace.c (pspace_object): Add frame_unwinders field. (pspy_dealloc): Decrement frame_unwinders reference count. (pspy_initialize): Create frame_unwinders list. (pspy_get_frame_unwinders): New function. (pspy_set_frame_unwinders): Ditto. (pspy_getset): Add frame_unwinders attribute to gdb.Progspace. * python/py-unwind.c: New file. * python/python-internal.h (pspy_get_name_unwinders): New prototype. (objpy_get_frame_unwinders): New prototype. (gdbpy_initialize_unwind): New prototype. * python/python.c (gdbpy_apply_type_printers): Call gdbpy_initialize_unwind. gdb/doc/ChangeLog: * doc/python.texi (Writing a Frame Unwinder in Python): Add section. gdb/testsuite/ChangeLog: * gdb.python/py-unwind-maint.c: New file. * gdb.python/py-unwind-maint.exp: New test. * gdb.python/py-unwind-maint.py: New file. * gdb.python/py-unwind.c: New file. * gdb.python/py-unwind.exp: New test. * gdb.python/py-unwind.py: New test.
2015-04-01 20:49:12 +02:00
2015-04-01 Sasha Smundak <asmundak@google.com>
* gdb.python/py-unwind-maint.c: New file.
* gdb.python/py-unwind-maint.exp: New test.
* gdb.python/py-unwind-maint.py: New file.
* gdb.python/py-unwind.c: New file.
* gdb.python/py-unwind.exp: New test.
* gdb.python/py-unwind.py: New test.
gdb.threads/manythreads.exp: can't read "test": no such variable If interrupt_and_wait manages to trigger the FAIL path, we get: ERROR OCCURED: can't read "test": no such variable gdb/testsuite/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * gdb.threads/manythreads.exp (interrupt_and_wait): Pass $message to fail instead of non-existent $test.
2015-03-31 19:36:51 +02:00
2015-04-01 Pedro Alves <palves@redhat.com>
* gdb.threads/manythreads.exp (interrupt_and_wait): Pass $message
to fail instead of non-existent $test.
Fix gdb_spawn_with_cmdline_opts with non-empty GDBFLAGS Running attach.exp with a DejaGnu board that sets GDBFLAGS, like e.g.,: set GDBFLAGS "-ex \"set displaced off\"" fails with (line breaks added for clarity): (gdb) PASS: gdb.base/attach.exp: starting with --pid Executing on build: kill -9 3537 (timeout = 300) spawn -ignore SIGHUP kill -9 3537 spawn of build/gdb/gdb -nw -nx \ -data-directory build/gdb/testsuite/../data-directory \ -ex "set displaced off"-iex "set height 0" -iex "set width 0" \ ^^^^^^^^ --pid=4468 -ex "start" failed ERROR: Spawning build/gdb/gdb failed. UNRESOLVED: gdb.base/attach.exp: cmdline attach run: run to prompt gdb/testsuite/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * lib/gdb.exp (gdb_spawn_with_cmdline_opts): Append space to GDBFLAGS if not empty.
2015-03-30 19:00:28 +02:00
2015-04-01 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_spawn_with_cmdline_opts): Append space to
GDBFLAGS if not empty.
Share the "multi_line" helper among all testcases gdb/testsuite/ChangeLog: * gdb.ada/complete.exp: Remove "multi_line". * gdb.ada/info_exc.exp: Remove "multi_line". * gdb.ada/packed_tagged.exp: Remove "multi_line". * gdb.ada/ptype_field.exp: Remove "multi_line". * gdb.ada/sym_print_name.exp: Remove "multi_line". * gdb.ada/tagged.exp: Remove "multi_line". * gdb.btrace/buffer-size.exp: Replace [join [list ...]] with [multi_line ...] * gdb.btrace/delta.exp: Likewise. * gdb.btrace/exception.exp: Likewise. * gdb.btrace/function_call_history.exp: Likewise. * gdb.btrace/instruction_history.exp: Likewise. * gdb.btrace/nohist.exp: Likewise. * gdb.btrace/record_goto.exp: Likewise. * gdb.btrace/segv.exp: Likewise. * gdb.btrace/stepi.exp: Likewise. * gdb.btrace/tailcall.exp: Likewise. * gdb.btrace/unknown_functions.exp: Likewise. * gdb.dwarf2/dw2-undefined-ret-addr.exp: Likewise. * lib/gdb.exp: Add the "multi_line" helper.
2015-03-10 09:51:27 +01:00
2015-04-01 Pierre-Marie de Rodat <derodat@adacore.com>
* gdb.ada/complete.exp: Remove "multi_line".
* gdb.ada/info_exc.exp: Remove "multi_line".
* gdb.ada/packed_tagged.exp: Remove "multi_line".
* gdb.ada/ptype_field.exp: Remove "multi_line".
* gdb.ada/sym_print_name.exp: Remove "multi_line".
* gdb.ada/tagged.exp: Remove "multi_line".
* gdb.btrace/buffer-size.exp: Replace [join [list ...]] with
[multi_line ...]
* gdb.btrace/delta.exp: Likewise.
* gdb.btrace/exception.exp: Likewise.
* gdb.btrace/function_call_history.exp: Likewise.
* gdb.btrace/instruction_history.exp: Likewise.
* gdb.btrace/nohist.exp: Likewise.
* gdb.btrace/record_goto.exp: Likewise.
* gdb.btrace/segv.exp: Likewise.
* gdb.btrace/stepi.exp: Likewise.
* gdb.btrace/tailcall.exp: Likewise.
* gdb.btrace/unknown_functions.exp: Likewise.
* gdb.dwarf2/dw2-undefined-ret-addr.exp: Likewise.
* lib/gdb.exp: Add the "multi_line" helper.
Crash on thread id wrap around On GNU/Linux, if the target reuses the TID of a thread that GDB still has in its list marked as THREAD_EXITED, GDB crashes, like: (gdb) continue Continuing. src/gdb/thread.c:789: internal-error: set_running: Assertion `tp->state != THREAD_EXITED' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) FAIL: gdb.threads/tid-reuse.exp: continue to breakpoint: after_reuse_time (GDB internal error) Here: (top-gdb) bt #0 internal_error (file=0x953dd8 "src/gdb/thread.c", line=789, fmt=0x953da0 "%s: Assertion `%s' failed.") at src/gdb/common/errors.c:54 #1 0x0000000000638514 in set_running (ptid=..., running=1) at src/gdb/thread.c:789 #2 0x00000000004bda42 in linux_handle_extended_wait (lp=0x16f5760, status=0, stopping=0) at src/gdb/linux-nat.c:2114 #3 0x00000000004bfa24 in linux_nat_filter_event (lwpid=20570, status=198015) at src/gdb/linux-nat.c:3127 #4 0x00000000004c070e in linux_nat_wait_1 (ops=0xe193d0, ptid=..., ourstatus=0x7fffffffd2c0, target_options=1) at src/gdb/linux-nat.c:3478 #5 0x00000000004c1015 in linux_nat_wait (ops=0xe193d0, ptid=..., ourstatus=0x7fffffffd2c0, target_options=1) at src/gdb/linux-nat.c:3722 #6 0x00000000004c92d2 in thread_db_wait (ops=0xd80b60 <thread_db_ops>, ptid=..., ourstatus=0x7fffffffd2c0, options=1) at src/gdb/linux-thread-db.c:1525 #7 0x000000000066db43 in delegate_wait (self=0xd80b60 <thread_db_ops>, arg1=..., arg2=0x7fffffffd2c0, arg3=1) at src/gdb/target-delegates.c:116 #8 0x000000000067e54b in target_wait (ptid=..., status=0x7fffffffd2c0, options=1) at src/gdb/target.c:2206 #9 0x0000000000625111 in fetch_inferior_event (client_data=0x0) at src/gdb/infrun.c:3275 #10 0x0000000000648a3b in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at src/gdb/inf-loop.c:56 #11 0x00000000004c2ecb in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4655 I managed to come up with a test that reliably reproduces this. It spawns enough threads for the pid number space to wrap around, so could potentially take a while. On my box that's 4 seconds; on gcc110, a PPC box which has max_pid set to 65536, it's over 10 seconds. So I made the test compute how long that would take, and cap the time waited if it would be unreasonably long. Tested on x86_64 Fedora 20. gdb/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * linux-thread-db.c (record_thread): Readd the thread to gdb's list if it was marked exited. gdb/testsuite/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * gdb.threads/tid-reuse.c: New file. * gdb.threads/tid-reuse.exp: New file.
2015-04-01 14:38:06 +02:00
2015-04-01 Pedro Alves <palves@redhat.com>
* gdb.threads/tid-reuse.c: New file.
* gdb.threads/tid-reuse.exp: New file.
Implement support for checking /proc/PID/coredump_filter This patch, as the subject says, extends GDB so that it is able to use the contents of the file /proc/PID/coredump_filter when generating a corefile. This file contains a bit mask that is a representation of the different types of memory mappings in the Linux kernel; the user can choose to dump or not dump a certain type of memory mapping by enabling/disabling the respective bit in the bit mask. Currently, here is what is supported: bit 0 Dump anonymous private mappings. bit 1 Dump anonymous shared mappings. bit 2 Dump file-backed private mappings. bit 3 Dump file-backed shared mappings. bit 4 (since Linux 2.6.24) Dump ELF headers. bit 5 (since Linux 2.6.28) Dump private huge pages. bit 6 (since Linux 2.6.28) Dump shared huge pages. (This table has been taken from core(5), but you can also read about it on Documentation/filesystems/proc.txt inside the Linux kernel source tree). The default value for this file, used by the Linux kernel, is 0x33, which means that bits 0, 1, 4 and 5 are enabled. This is also the default for GDB implemented in this patch, FWIW. Well, reading the file is obviously trivial. The hard part, mind you, is how to determine the types of the memory mappings. For that, I extended the code of gdb/linux-tdep.c:linux_find_memory_regions_full and made it rely *much more* on the information gathered from /proc/<PID>/smaps. This file contains a "verbose dump" of the inferior's memory mappings, and we were not using as much information as we could from it. If you want to read more about this file, take a look at the proc(5) manpage (I will also write a blog post soon about everything I had to learn to get this patch done, and when I it is ready I will post it here). With Oleg Nesterov's help, we could improve the current algorithm for determining whether a memory mapping is anonymous/file-backed, private/shared. GDB now also respects the MADV_DONTDUMP flag and does not dump the memory mapping marked as so, and will always dump "[vsyscall]" or "[vdso]" mappings (just like the Linux kernel). In a nutshell, what the new code is doing is: - If the mapping is associated to a file whose name ends with " (deleted)", or if the file is "/dev/zero", or if it is "/SYSV%08x" (shared memory), or if there is no file associated with it, or if the AnonHugePages: or the Anonymous: fields in the /proc/PID/smaps have contents, then GDB considers this mapping to be anonymous. There is a special case in this, though: if the memory mapping is a file-backed one, but *also* contains "Anonymous:" or "AnonHugePages:" pages, then GDB considers this mapping to be *both* anonymous and file-backed, just like the Linux kernel does. What that means is simple: this mapping will be dumped if the user requested anonymous mappings *or* if the user requested file-backed mappings to be present in the corefile. It is worth mentioning that, from all those checks described above, the most fragile is the one to see if the file name ends with " (deleted)". This does not necessarily mean that the mapping is anonymous, because the deleted file associated with the mapping may have been a hard link to another file, for example. The Linux kernel checks to see if "i_nlink == 0", but GDB cannot easily do this check (as it has been discussed, GDB would need to run as root, and would need to check the contents of the /proc/PID/map_files/ directory in order to determine whether the deleted was a hardlink or not). Therefore, we made a compromise here, and we assume that if the file name ends with " (deleted)", then the mapping is indeed anonymous. FWIW, this is something the Linux kernel could do better: expose this information in a more direct way. - If we see the flag "sh" in the VmFlags: field (in /proc/PID/smaps), then certainly the memory mapping is shared (VM_SHARED). If we have access to the VmFlags, and we don't see the "sh" there, then certainly the mapping is private. However, older Linux kernels (see the code for more details) do not have the VmFlags field; in that case, we use another heuristic: if we see 'p' in the permission flags, then we assume that the mapping is private, even though the presence of the 's' flag there would mean VM_MAYSHARE, which means the mapping could still be private. This should work OK enough, however. Finally, it is worth mentioning that I added a new command, 'set use-coredump-filter on/off'. When it is 'on', it will read the coredump_filter' file (if it exists) and use its value; otherwise, it will use the default value mentioned above (0x33) to decide which memory mappings to dump. gdb/ChangeLog: 2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com> Jan Kratochvil <jan.kratochvil@redhat.com> Oleg Nesterov <oleg@redhat.com> PR corefiles/16092 * linux-tdep.c: Include 'gdbcmd.h' and 'gdb_regex.h'. New enum identifying the various options of the coredump_filter file. (struct smaps_vmflags): New struct. (use_coredump_filter): New variable. (decode_vmflags): New function. (mapping_is_anonymous_p): Likewise. (dump_mapping_p): Likewise. (linux_find_memory_regions_full): New variables 'coredumpfilter_name', 'coredumpfilterdata', 'pid', 'filterflags'. Removed variable 'modified'. Read /proc/<PID>/smaps file; improve parsing of its information. Implement memory mapping filtering based on its contents. (show_use_coredump_filter): New function. (_initialize_linux_tdep): New command 'set use-coredump-filter'. * NEWS: Mention the possibility of using the '/proc/PID/coredump_filter' file when generating a corefile. Mention new command 'set use-coredump-filter'. gdb/doc/ChangeLog: 2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com> PR corefiles/16092 * gdb.texinfo (gcore): Mention new command 'set use-coredump-filter'. (set use-coredump-filter): Document new command. gdb/testsuite/ChangeLog: 2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com> PR corefiles/16092 * gdb.base/coredump-filter.c: New file. * gdb.base/coredump-filter.exp: Likewise.
2015-04-01 01:32:34 +02:00
2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com>
PR corefiles/16092
* gdb.base/coredump-filter.c: New file.
* gdb.base/coredump-filter.exp: Likewise.
dwarf.exp: Allow generating a stub .debug_line section Example of use: Dwarf::assemble "foo.s" { build_id 0102030405060708 declare_labels L; cu {is_64 0 version 4 addr_size 8} { DW_TAG_compile_unit { {DW_AT_stmt_list $L DW_FORM_sec_offset} } { DW_TAG_subprogram { # We can now reference the source file. {DW_AT_decl_file 1 DW_FORM_data1} } } } lines {is_64 0 version 2 addr_size 8} L { include_dir "foo" include_dir "bar" file_name "foo.c" 1 file_name "bar.c" 1 file_name "baz.c" 2 } } Signed-off-by: Petr Machata <pmachata@redhat.com>
2015-02-23 15:41:52 +01:00
2015-03-27 Petr Machata <pmachata@redhat.com>
* lib/dwarf.exp (Dwarf::_handle_DW_FORM): Handle DW_FORM_sec_offset.
(Dwarf::_line_count, Dwarf::_line_saw_file): New variables.
(Dwarf::assemble): Initialize them.
(Dwarf::lines): New function.
testsuite: Don't set SYMBOL_PREFIX for x86_64_*_cygwin Exactly like x86_64-*-mingw, SYMBOL_PREFIX should not be set to "_" for x86_64_*_cygwin gdb/testuite/ChangeLog: * lib/gdb.exp (gdb_target_symbol_prefix_flags): Don't set SYMBOL_PREFIX for x86_64-*-cygwin.
2015-03-26 21:51:44 +01:00
2015-03-26 Jon Turney <jon.turney@dronecode.org.uk>
* lib/gdb.exp (gdb_target_symbol_prefix_flags): Don't set
SYMBOL_PREFIX for x86_64-*-cygwin.
Properly intern constants into psymtab Variables with a DW_AT_const_value but without a DW_AT_location were not getting added to the partial symbol table. They are added to the full symbol table, however, when the compilation unit's psymtabs are expanded. Before: (gdb) p one No symbol "one" in current context. (gdb) mt flush-symbol-cache (gdb) mt expand one.c (gdb) p one $1 = 1 After: (gdb) p one $1 = 1 To the user it's pretty strange, as depending on whether tab completion has forced expansion of all CUs or not the lookup might succeed, or not if the failure was already added to the symbol cache. This commit simply makes sure to add constants to the partial symbol tables. gdb/testsuite/ChangeLog: PR symtab/18148 * gdb.dwarf2/dw2-intercu.S (one, two): Add variables that have a const_value but not a location. * gdb.dwarf2/dw2-intercu.exp: Add tests that constants without location defined in non-main CUs are visible. gdb/ChangeLog: PR symtab/18148 * dwarf2read.c (struct partial_die_info): Add has_const_value member. (add_partial_symbol): Don't punt on symbols that have const_value attributes. (read_partial_die): Detect DW_AT_const_value.
2015-03-26 19:41:15 +01:00
2015-03-26 Andy Wingo <wingo@igalia.com>
PR symtab/18148
* gdb.dwarf2/dw2-intercu.S (one, two): Add variables that have a
const_value but not a location.
* gdb.dwarf2/dw2-intercu.exp: Add tests that constants without
location defined in non-main CUs are visible.
Handle the effect of skipping prologue break-asm-file.exp has some manually written dwarf to create some line number entries like this, [0x0000013d] Extended opcode 2: set Address to 0x40053f [0x00000144] Advance Line by 4 to 7 [0x00000146] Copy [0x00000147] Extended opcode 2: set Address to 0x400541 [0x0000014e] Advance Line by 1 to 8 [0x00000150] Copy [0x00000151] Extended opcode 2: set Address to 0x400547 [0x00000158] Extended opcode 1: End of Sequence 0x40053f is the start address of function func, and is mapped to line 7. 0x400541 is within function func, and is mapped to line 8. (gdb) disassemble /r 0x40053f,+8 Dump of assembler code from 0x40053f to 0x400547: 0x000000000040053f <func+0>: 00 00 add %al,(%rax) 0x0000000000400541 <func+2>: 00 00 add %al,(%rax) 0x0000000000400543 <func+4>: 00 00 add %al,(%rax) 0x0000000000400545 <func+6>: 00 00 add %al,(%rax) in the following test, (gdb) break a/break-asm-file0.s:func Breakpoint 1 at 0x40053f: file a/break-asm-file0.s, line 7. As we can see, breakpoint is set at the start address of function func on x86, which means no prologue is skipped. On other targets, such as arm and aarch64, breakpoint is set at the address *after* the start address, which is mapped to line 8. Then test fails. In fact, it is lucky this test doesn't fail on x86 and x86_64, whose gdbarch method skip_prologue doesn't reply on skip_prologue_using_sal if producer isn't clang. if (find_pc_partial_function (start_pc, NULL, &func_addr, NULL)) { CORE_ADDR post_prologue_pc = skip_prologue_using_sal (gdbarch, func_addr); struct compunit_symtab *cust = find_pc_compunit_symtab (func_addr); /* Clang always emits a line note before the prologue and another one after. We trust clang to emit usable line notes. */ if (post_prologue_pc && (cust != NULL && COMPUNIT_PRODUCER (cust) != NULL && startswith (COMPUNIT_PRODUCER (cust), "clang "))) return max (start_pc, post_prologue_pc); } so it doesn't return and go further to prologue analyser. Since ".int 0" isn't an instruction of prologue, nothing is skipped, starting address is used, and test passes. however, on targets which don't have such producer checking, the first line number entry is skipped, and skip_prologue_using_sal returns sal represents the second line number entry. The idea of this patch is to force GDB stop at somewhere which is stilled mapped to line 7 after skipping prologue. I choose to add a new line number entry for the following instruction but mapped to the same line (7), because I see the comments in dwarf2read.c, ... fact that two consecutive line number entries for the same line is a heuristic used by gcc to denote the end of the prologue. then the line table becomes: [0x000000d4] Extended opcode 2: set Address to 0x400529 [0x000000db] Advance Line by 4 to 7 [0x000000dd] Copy [0x000000de] Extended opcode 2: set Address to 0x40052a [0x000000e5] Advance Line by 0 to 7 [0x000000e7] Copy [0x000000e8] Extended opcode 2: set Address to 0x40052b [0x000000ef] Advance Line by 1 to 8 [0x000000f1] Copy [0x000000f2] Extended opcode 2: set Address to 0x40052c [0x000000f9] Extended opcode 1: End of Sequence gdb/testsuite: 2015-03-26 Yao Qi <yao.qi@linaro.org> PR testsuite/18139 * gdb.linespec/break-asm-file0.s (func): New label .Lfunc_2. Add a line number entry for the same line. * gdb.linespec/break-asm-file1.s (func): New label .Lfunc_2. Add a line number entry for the same line.
2015-03-26 09:29:48 +01:00
2015-03-26 Yao Qi <yao.qi@linaro.org>
PR testsuite/18139
* gdb.linespec/break-asm-file0.s (func): New label .Lfunc_2.
Add a line number entry for the same line.
* gdb.linespec/break-asm-file1.s (func): New label .Lfunc_2.
Add a line number entry for the same line.
Remove some hard-coded stuff in tests There are some hard-coded stuff in .s files, such as .int 0 and address offset, which isn't portable. This patch is to replace ".int 0" with nop and address offset with labels. gdb/testsuite: 2015-03-26 Yao Qi <yao.qi@linaro.org> * gdb.linespec/break-asm-file0.s (func2): Use nop instead of .int 0. (func): Likewise. Add .Lfunc_1 label. Use .Lfunc_1 label. * gdb.linespec/break-asm-file1.s (func3): Use nop instead of .int 0. (func): Likewise. Use .Lfunc_1 label.
2015-03-26 09:29:48 +01:00
2015-03-26 Yao Qi <yao.qi@linaro.org>
* gdb.linespec/break-asm-file0.s (func2): Use nop instead of
.int 0.
(func): Likewise. Add .Lfunc_1 label.
Use .Lfunc_1 label.
* gdb.linespec/break-asm-file1.s (func3): Use nop instead of
.int 0.
(func): Likewise.
Use .Lfunc_1 label.
Compile break-asm-file{0,1}.s without debug info If I add some nop into break-asm-file1.s like this, --- INDEX:/gdb/testsuite/gdb.linespec/break-asm-file1.s +++ WORKDIR:/gdb/testsuite/gdb.linespec/break-asm-file1.s @@ -31,8 +31,8 @@ _func: .type func, %function func: .Lbegin_func: - .int 0 - .int 0 + nop + nop .Lend_func: .size func, .-func .Lend_text1: I get the following error: Running gdb/testsuite/gdb.linespec/break-asm-file.exp ... gdb/testsuite/gdb.linespec/break-asm-file1.s: Assembler messages:^M gdb/testsuite/gdb.linespec/break-asm-file1.s: Fatal error: duplicate .debug_line sections break-asm-file0.s and break-asm-file1.s have already had debug information (written manually), so don't need to generate debug infor for them. gdb/testsuite: 2015-03-26 Yao Qi <yao.qi@linaro.org> * gdb.linespec/break-asm-file.exp: Don't call prepare_for_testing. Call gdb_compile instead to compile each .s files without debug information.
2015-03-26 09:29:48 +01:00
2015-03-26 Yao Qi <yao.qi@linaro.org>
* gdb.linespec/break-asm-file.exp: Don't call prepare_for_testing.
Call gdb_compile instead to compile each .s files without debug
information.
Relax pattern to match the output of "info frame" in gdb.base/savedregs.exp Hi, I see the following two fails in gdb.base/savedregs.exp on aarch64-linux, info frame 2^M Stack frame at 0x7ffffffa60:^M pc = 0x40085c in thrower (/home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/savedregs.c:49); saved pc = 0x400898^M called by frame at 0x7ffffffa70, caller of frame at 0x7fffffe800^M source language c.^M Arglist at 0x7ffffffa60, args: ^M Locals at 0x7ffffffa60, Previous frame's sp is 0x7ffffffa60^M (gdb) FAIL: gdb.base/savedregs.exp: Get thrower info frame info frame 2^M Stack frame at 0x7fffffe800:^M pc = 0x400840 in catcher (/home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/savedregs.c:42); saved pc = 0x7fb7ffc350^M called by frame at 0x7fffffe800, caller of frame at 0x7fffffe7e0^M source language c.^M Arglist at 0x7fffffe7f0, args: sig=11^M Locals at 0x7fffffe7f0, Previous frame's sp is 0x7fffffe800 (gdb) FAIL: gdb.base/savedregs.exp: Get catcher info frame looks the test expects to match "Saved registers:" from the output of "info frame", but no registers are saved on these two frames, because thrower and catcher are simple and leaf functions. (gdb) disassemble thrower Dump of assembler code for function thrower: 0x0000000000400858 <+0>: mov x0, #0x0 // #0 0x000000000040085c <+4>: strb wzr, [x0] 0x0000000000400860 <+8>: ret End of assembler dump. (gdb) disassemble catcher Dump of assembler code for function catcher: 0x0000000000400838 <+0>: sub sp, sp, #0x10 0x000000000040083c <+4>: str w0, [sp,#12] 0x0000000000400840 <+8>: adrp x0, 0x410000 0x0000000000400844 <+12>: add x0, x0, #0xb9c 0x0000000000400848 <+16>: mov w1, #0x1 // #1 0x000000000040084c <+20>: str w1, [x0] 0x0000000000400850 <+24>: add sp, sp, #0x10 0x0000000000400854 <+28>: ret There are two ways to fix these fails, one is to modify functions to force some registers saved (for example, doing function call in them), and the other one is to relax the pattern to optionally match "Saved registers:". I did both, and feel that the latter is simple, so here is it. gdb/testsuite: 2015-03-26 Yao Qi <yao.qi@linaro.org> * gdb.base/savedregs.exp (process_saved_regs): Make "Saved registers:" optional in the pattern.
2015-03-26 09:16:20 +01:00
2015-03-26 Yao Qi <yao.qi@linaro.org>
* gdb.base/savedregs.exp (process_saved_regs): Make
"Saved registers:" optional in the pattern.
btrace: fix tests for 32-bit The x86-record_goto.S assembly source file does not build on 32-bit. This breaks many tests that use this file. Split it into x86_64-record_goto.S and i686-record_goto.S. Luckily, we can use either one with the same test .exp file. It further turned out that most tests do not really need a fixed binary; they should work pretty well with a newly-compiled C program. The one thing that breaks this is the heavy use of "record goto" to navigate inside the recorded execution. Combine step.exp, next,exp, and finish.exp into a single test step.exp and use normal stepping and reverse-stepping commands for navigation. testsuite/ * gdb.btrace/next.exp: Merged into step.exp. * gdb.btrace/finish.exp: Merged into step.exp. * gdb.btrace/nexti.exp: Merged into stepi.exp. * gdb.btrace/step.exp: Use record_goto.c as test file. Avoid using "record goto" and checking the exact replay position. * gdb.btrace/stepi.exp: Choose test file based on target. Do not check for "Recording format" in "info record" output. * gdb.btrace/record_goto.exp: Choose test file based on target. * gdb.btrace/x86-record_goto.S: Renamed into ... * gdb.btrace/x86_64-record_goto.S: ... this. * gdb.btrace/i686-record_goto.S: New. * gdb.btrace/x86-tailcall.S: Renamed into ... * gdb.btrace/x86_64-tailcall.S: ... this. * gdb.btrace/i686-tailcall.S: New. * gdb.btrace/x86-tailcall.c: Renamed into ... * gdb.btrace/tailcall.c: ... this. Split "return ++answer" into two separate statements. Update test. * gdb.btrace/delta.exp: Use record_goto.c as test file. * gdb.btrace/gcore.exp: Use record_goto.c as test file. * gdb.btrace/nohist.exp: Use record_goto.c as test file. * gdb.btrace/tailcall.exp: Choose test file based on target. * gdb.btrace/Makefile.in: Remove next, finish, and nexti.
2015-02-03 16:42:41 +01:00
2015-03-25 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/next.exp: Merged into step.exp.
* gdb.btrace/finish.exp: Merged into step.exp.
* gdb.btrace/nexti.exp: Merged into stepi.exp.
* gdb.btrace/step.exp: Use record_goto.c as test file. Avoid using
"record goto" and checking the exact replay position.
* gdb.btrace/stepi.exp: Choose test file based on target. Do not
check for "Recording format" in "info record" output.
* gdb.btrace/record_goto.exp: Choose test file based on target.
* gdb.btrace/x86-record_goto.S: Renamed into ...
* gdb.btrace/x86_64-record_goto.S: ... this.
* gdb.btrace/i686-record_goto.S: New.
* gdb.btrace/x86-tailcall.S: Renamed into ...
* gdb.btrace/x86_64-tailcall.S: ... this.
* gdb.btrace/i686-tailcall.S: New.
* gdb.btrace/x86-tailcall.c: Renamed into ...
* gdb.btrace/tailcall.c: ... this. Split "return ++answer" into two
separate statements. Update test.
* gdb.btrace/delta.exp: Use record_goto.c as test file.
* gdb.btrace/gcore.exp: Use record_goto.c as test file.
* gdb.btrace/nohist.exp: Use record_goto.c as test file.
* gdb.btrace/tailcall.exp: Choose test file based on target.
* gdb.btrace/Makefile.in: Remove next, finish, and nexti.
btrace: increase buffer size for exception test The trace for throwing and catching an exception can be quite big. Increase the buffer size to avoid spurious fails. testsuite/ * gdb.btrace/exception.exp: Increase BTS buffer size.
2015-01-23 15:13:20 +01:00
2015-03-25 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/exception.exp: Increase BTS buffer size.
Fix "thread apply all" with exited threads I noticed that "thread apply all" sometimes crashes. The problem is that thread_apply_all_command doesn take exited threads into account, and we qsort and then walk more elements than there really ever were put in the array. Valgrind shows: The current thread <Thread ID 3> has terminated. See `help thread'. (gdb) thread apply all p 1 Thread 1 (Thread 0x7ffff7fc2740 (LWP 29579)): $1 = 1 ==29576== Use of uninitialised value of size 8 ==29576== at 0x639CA8: set_thread_refcount (thread.c:1337) ==29576== by 0x5C2C7B: do_my_cleanups (cleanups.c:155) ==29576== by 0x5C2CE8: do_cleanups (cleanups.c:177) ==29576== by 0x63A191: thread_apply_all_command (thread.c:1477) ==29576== by 0x50374D: do_cfunc (cli-decode.c:105) ==29576== by 0x506865: cmd_func (cli-decode.c:1893) ==29576== by 0x7562CB: execute_command (top.c:476) ==29576== by 0x647DA4: command_handler (event-top.c:494) ==29576== by 0x648367: command_line_handler (event-top.c:692) ==29576== by 0x7BF7C9: rl_callback_read_char (callback.c:220) ==29576== by 0x64784C: rl_callback_read_char_wrapper (event-top.c:171) ==29576== by 0x647CB5: stdin_event_handler (event-top.c:432) ==29576== ... This can happen easily today as linux-nat.c/linux-thread-db.c are forgetting to purge non-current exited threads. But even with that fixed, we can always do "thread apply all" with an exited thread selected, which won't be deleted until the user switches to another thread. That's what the test added by this commit exercises. Tested on x86_64 Fedora 20. gdb/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * thread.c (thread_apply_all_command): Take exited threads into account. gdb/testsuite/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * gdb.threads/no-unwaited-for-left.exp: Test "thread apply all".
2015-03-24 22:01:29 +01:00
2015-03-24 Pedro Alves <palves@redhat.com>
* gdb.threads/no-unwaited-for-left.exp: Test "thread apply all".
Make "set scheduler-locking step" depend on user intention, only Currently, "set scheduler-locking step" is a bit odd. The manual documents it as being optimized for stepping, so that focus of debugging does not change unexpectedly, but then it says that sometimes other threads may run, and thus focus may indeed change unexpectedly... A user can then be excused to get confused and wonder why does GDB behave like this. I don't think a user should have to know about details of how "next" or whatever other run control command is implemented internally to understand when does the "scheduler-locking step" setting take effect. This patch completes a transition that the code has been moving towards for a while. It makes "set scheduler-locking step" hold threads depending on whether the _command_ the user entered was a stepping command [step/stepi/next/nexti], or not. Before, GDB could end up locking threads even on "continue" if for some reason run control decides a thread needs to be single stepped (e.g., for a software watchpoint). After, if a "continue" happens to need to single-step for some reason, we won't lock threads (unless when stepping over a breakpoint, naturally). And if a stepping command wants to continue a thread for bit, like when skipping a function to a step-resume breakpoint, we'll still lock threads, so focus of debugging doesn't change. In order to make this work, we need to record in the thread structure whether what set it running was a stepping command. (A follow up patch will remove the "step" parameters of 'proceed' and 'resume') FWIW, Fedora GDB, which defaults to "scheduler-locking step" (mainline defaults to "off") carries a different patch that goes in this direction as well. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * gdbthread.h (struct thread_control_state) <stepping_command>: New field. * infcmd.c (step_once): Pass step=1 to clear_proceed_status. Set the thread's stepping_command field. * infrun.c (resume): Check the thread's stepping_command flag to determine which threads should be resumed. Rename 'entry_step' local to user_step. (clear_proceed_status_thread): Clear 'stepping_command'. (schedlock_applies): Change parameter type to struct thread_info pointer. Adjust. (find_thread_needs_step_over): Remove 'step' parameter. Adjust. (switch_back_to_stepped_thread): Adjust calls to 'schedlock_applies'. (_initialize_infrun): Adjust "set scheduler-locking step" help. gdb/testsuite/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * gdb.threads/schedlock.exp (test_step): No longer expect that "set scheduler-locking step" with "next" over a function call runs threads unlocked. gdb/doc/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * gdb.texinfo (test_step) <set scheduler-locking step>: No longer mention that threads may sometimes run unlocked.
2015-03-24 18:50:31 +01:00
2015-03-24 Pedro Alves <palves@redhat.com>
* gdb.threads/schedlock.exp (test_step): No longer expect that
"set scheduler-locking step" with "next" over a function call runs
threads unlocked.
Fix mi-pending.exp test output to allow stable test diffing gdb/testsuite/ChangeLog: * gdb.mi/mi-pending.exp: Fix output of breakpoint test.
2015-03-24 18:28:42 +01:00
2015-03-24 Antoine Tremblay <antoine.tremblay@ericsson.com>
* gdb.mi/mi-pending.exp: Fix output of breakpoint test.
Fix breakpoint thread condition missing with mi and a pending breakpoint. When setting a pending breakpoint with a thread condition while using the mi interface, the thread condition would be lost by gdb when the breakpoint was resolved. This patch fixes this behavior by setting the thread condition properly in the mi case. Also, this patch modifies the mi-pending test case to test for this issue and removes some unneeded code in the testcase and dependency on stdio. gdb/Changelog: PR breakpoints/16466 * breakpoint.c (create_breakpoint): Set thread on breakpoint struct. gdb/testsuite/ChangeLog: PR breakpoints/16466 * gdb.mi/Makefile.in: Add mi-pendshr2.sl to cleanup. * gdb.mi/mi-pending.c (thread_func): New function. (int main): Add threading support required. * gdb.mi/mi-pending.exp: Add tests for this issue. * gdb.mi/mi-pendshr.c (pendfunc1): Remove stdio dependency. (pendfunc2): Remove stdio dependency. * gdb.mi/mi-pendshr2.c: New file.
2015-02-19 21:23:34 +01:00
2015-03-24 Antoine Tremblay <antoine.tremblay@ericsson.com>
PR breakpoints/16466
* gdb.mi/Makefile.in: Add mi-pendshr2.sl to cleanup.
* gdb.mi/mi-pending.c (thread_func): New function.
(int main): Add threading support required.
* gdb.mi/mi-pending.exp: Add tests for this issue.
* gdb.mi/mi-pendshr.c (pendfunc1): Remove stdio dependency.
(pendfunc2): Remove stdio dependency.
* gdb.mi/mi-pendshr2.c: New file.
Add missing changelog entries of last commit
2015-03-23 21:29:19 +01:00
2015-03-23 Keith Seitz <keiths@redhat.com>
* gdb.linespec/keywords.c: New file.
* gdb.linespec/keywords.exp: New file.
PR gdb/18021 - defend against "static virtual" methods This bug appears to be caused by bad debuginfo. The method causing the sefault in the reporter's test case is marked both static and virtual. This patch simply safegaurds against this case in dwarf2_add_member_fn, where the code assumes that there is a `this' pointer when a virtual method is seen (more specifically, when DW_AT_vtable_elem is seen). It previously dereferenced the first formal parameter (`this' pointer), which in this case doesn't exist. GDB consequently segfaulted dereferencing a NULL pointer. gdb/ChangeLog PR gdb/18021 * dwarf2read.c (dwarf2_add_member_fn): Issue a complaint if we find a static method with DW_AT_vtable_elem_location. gdb/testsuite/ChangeLog PR gdb/18021 * gdb.dwarf2/staticvirtual.exp: New test.
2015-02-27 18:55:07 +01:00
2015-03-23 Keith Seitz <keiths@redhat.com>
PR gdb/18021
* gdb.dwarf2/staticvirtual.exp: New test.
Remove gdb.hp gdb/ChangeLog 2015-03-20 Jan Kratochvil <jan.kratochvil@redhat.com> * config/djgpp/README: Remove gdb.hp. gdb/testsuite/ChangeLog 2015-03-20 Jan Kratochvil <jan.kratochvil@redhat.com> * Makefile.in (ALL_SUBDIRS): Remove gdb.hp. * README: Remove HP-UX and gdb.hp. (configuration): * configure: Regenerate. * configure.ac (AC_OUTPUT): Remove gdb.hp/Makefile, gdb.hp/gdb.objdbg/Makefile, gdb.hp/gdb.base-hp/Makefile, gdb.hp/gdb.aCC/Makefile, gdb.hp/gdb.compat/Makefile, gdb.hp/gdb.defects/Makefile. * gdb.hp/Makefile.in: File deleted. * gdb.hp/gdb.aCC/Makefile.in: File deleted. * gdb.hp/gdb.aCC/optimize.c: File deleted. * gdb.hp/gdb.aCC/optimize.exp: File deleted. * gdb.hp/gdb.aCC/run.c: File deleted. * gdb.hp/gdb.aCC/watch-cmd.exp: File deleted. * gdb.hp/gdb.base-hp/Makefile.in: File deleted. * gdb.hp/gdb.base-hp/callfwmall.c: File deleted. * gdb.hp/gdb.base-hp/callfwmall.exp: File deleted. * gdb.hp/gdb.base-hp/dollar.c: File deleted. * gdb.hp/gdb.base-hp/dollar.exp: File deleted. * gdb.hp/gdb.base-hp/genso-thresh.c: File deleted. * gdb.hp/gdb.base-hp/hwwatchbus.c: File deleted. * gdb.hp/gdb.base-hp/hwwatchbus.exp: File deleted. * gdb.hp/gdb.base-hp/pxdb.c: File deleted. * gdb.hp/gdb.base-hp/pxdb.exp: File deleted. * gdb.hp/gdb.base-hp/reg-pa64.exp: File deleted. * gdb.hp/gdb.base-hp/reg-pa64.s: File deleted. * gdb.hp/gdb.base-hp/reg.exp: File deleted. * gdb.hp/gdb.base-hp/reg.s: File deleted. * gdb.hp/gdb.base-hp/sized-enum.c: File deleted. * gdb.hp/gdb.base-hp/sized-enum.exp: File deleted. * gdb.hp/gdb.base-hp/so-thresh.exp: File deleted. * gdb.hp/gdb.base-hp/so-thresh.mk: File deleted. * gdb.hp/gdb.base-hp/so-thresh.sh: File deleted. * gdb.hp/gdb.compat/Makefile.in: File deleted. * gdb.hp/gdb.compat/average.c: File deleted. * gdb.hp/gdb.compat/sum.c: File deleted. * gdb.hp/gdb.compat/xdb.c: File deleted. * gdb.hp/gdb.compat/xdb0.c: File deleted. * gdb.hp/gdb.compat/xdb0.h: File deleted. * gdb.hp/gdb.compat/xdb1.c: File deleted. * gdb.hp/gdb.compat/xdb1.exp: File deleted. * gdb.hp/gdb.compat/xdb2.exp: File deleted. * gdb.hp/gdb.compat/xdb3.exp: File deleted. * gdb.hp/gdb.defects/Makefile.in: File deleted. * gdb.hp/gdb.defects/bs14602.c: File deleted. * gdb.hp/gdb.defects/bs14602.exp: File deleted. * gdb.hp/gdb.defects/solib-d.c: File deleted. * gdb.hp/gdb.defects/solib-d.exp: File deleted. * gdb.hp/gdb.defects/solib-d1.c: File deleted. * gdb.hp/gdb.defects/solib-d2.c: File deleted. * gdb.hp/gdb.objdbg/Makefile.in: File deleted. * gdb.hp/gdb.objdbg/objdbg01.exp: File deleted. * gdb.hp/gdb.objdbg/objdbg01/x1.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg01/x2.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg01/x3.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg01/x3.h: File deleted. * gdb.hp/gdb.objdbg/objdbg02.exp: File deleted. * gdb.hp/gdb.objdbg/objdbg02/x1.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg02/x2.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg02/x3.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg03.exp: File deleted. * gdb.hp/gdb.objdbg/objdbg03/x1.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg03/x2.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg03/x3.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg04.exp: File deleted. * gdb.hp/gdb.objdbg/objdbg04/x.h: File deleted. * gdb.hp/gdb.objdbg/objdbg04/x1.cc: File deleted. * gdb.hp/gdb.objdbg/objdbg04/x2.cc: File deleted. * gdb.hp/gdb.objdbg/tools/symaddr: File deleted. * gdb.hp/gdb.objdbg/tools/symaddr.pa64: File deleted. * gdb.hp/gdb.objdbg/tools/test-objdbg.cc: File deleted. * gdb.hp/tools/odump: File deleted.
2015-03-20 17:15:15 +01:00
2015-03-20 Jan Kratochvil <jan.kratochvil@redhat.com>
* Makefile.in (ALL_SUBDIRS): Remove gdb.hp.
* README: Remove HP-UX and gdb.hp.
(configuration):
* configure: Regenerate.
* configure.ac (AC_OUTPUT): Remove gdb.hp/Makefile,
gdb.hp/gdb.objdbg/Makefile, gdb.hp/gdb.base-hp/Makefile,
gdb.hp/gdb.aCC/Makefile, gdb.hp/gdb.compat/Makefile,
gdb.hp/gdb.defects/Makefile.
* gdb.hp/Makefile.in: File deleted.
* gdb.hp/gdb.aCC/Makefile.in: File deleted.
* gdb.hp/gdb.aCC/optimize.c: File deleted.
* gdb.hp/gdb.aCC/optimize.exp: File deleted.
* gdb.hp/gdb.aCC/run.c: File deleted.
* gdb.hp/gdb.aCC/watch-cmd.exp: File deleted.
* gdb.hp/gdb.base-hp/Makefile.in: File deleted.
* gdb.hp/gdb.base-hp/callfwmall.c: File deleted.
* gdb.hp/gdb.base-hp/callfwmall.exp: File deleted.
* gdb.hp/gdb.base-hp/dollar.c: File deleted.
* gdb.hp/gdb.base-hp/dollar.exp: File deleted.
* gdb.hp/gdb.base-hp/genso-thresh.c: File deleted.
* gdb.hp/gdb.base-hp/hwwatchbus.c: File deleted.
* gdb.hp/gdb.base-hp/hwwatchbus.exp: File deleted.
* gdb.hp/gdb.base-hp/pxdb.c: File deleted.
* gdb.hp/gdb.base-hp/pxdb.exp: File deleted.
* gdb.hp/gdb.base-hp/reg-pa64.exp: File deleted.
* gdb.hp/gdb.base-hp/reg-pa64.s: File deleted.
* gdb.hp/gdb.base-hp/reg.exp: File deleted.
* gdb.hp/gdb.base-hp/reg.s: File deleted.
* gdb.hp/gdb.base-hp/sized-enum.c: File deleted.
* gdb.hp/gdb.base-hp/sized-enum.exp: File deleted.
* gdb.hp/gdb.base-hp/so-thresh.exp: File deleted.
* gdb.hp/gdb.base-hp/so-thresh.mk: File deleted.
* gdb.hp/gdb.base-hp/so-thresh.sh: File deleted.
* gdb.hp/gdb.compat/Makefile.in: File deleted.
* gdb.hp/gdb.compat/average.c: File deleted.
* gdb.hp/gdb.compat/sum.c: File deleted.
* gdb.hp/gdb.compat/xdb.c: File deleted.
* gdb.hp/gdb.compat/xdb0.c: File deleted.
* gdb.hp/gdb.compat/xdb0.h: File deleted.
* gdb.hp/gdb.compat/xdb1.c: File deleted.
* gdb.hp/gdb.compat/xdb1.exp: File deleted.
* gdb.hp/gdb.compat/xdb2.exp: File deleted.
* gdb.hp/gdb.compat/xdb3.exp: File deleted.
* gdb.hp/gdb.defects/Makefile.in: File deleted.
* gdb.hp/gdb.defects/bs14602.c: File deleted.
* gdb.hp/gdb.defects/bs14602.exp: File deleted.
* gdb.hp/gdb.defects/solib-d.c: File deleted.
* gdb.hp/gdb.defects/solib-d.exp: File deleted.
* gdb.hp/gdb.defects/solib-d1.c: File deleted.
* gdb.hp/gdb.defects/solib-d2.c: File deleted.
* gdb.hp/gdb.objdbg/Makefile.in: File deleted.
* gdb.hp/gdb.objdbg/objdbg01.exp: File deleted.
* gdb.hp/gdb.objdbg/objdbg01/x1.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg01/x2.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg01/x3.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg01/x3.h: File deleted.
* gdb.hp/gdb.objdbg/objdbg02.exp: File deleted.
* gdb.hp/gdb.objdbg/objdbg02/x1.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg02/x2.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg02/x3.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg03.exp: File deleted.
* gdb.hp/gdb.objdbg/objdbg03/x1.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg03/x2.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg03/x3.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg04.exp: File deleted.
* gdb.hp/gdb.objdbg/objdbg04/x.h: File deleted.
* gdb.hp/gdb.objdbg/objdbg04/x1.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg04/x2.cc: File deleted.
* gdb.hp/gdb.objdbg/tools/symaddr: File deleted.
* gdb.hp/gdb.objdbg/tools/symaddr.pa64: File deleted.
* gdb.hp/gdb.objdbg/tools/test-objdbg.cc: File deleted.
* gdb.hp/tools/odump: File deleted.
gdbserver/Linux: unbreak thread event randomization Wanting to make sure the new continue-pending-status.exp test tests both cases of threads 2 and 3 reporting an event, I added counters to the test, to make it FAIL if events for both threads aren't seen. Assuming a well behaved backend, and given a reasonable number of iterations, it should PASS. However, running that against GNU/Linux gdbserver, I found that surprisingly, that FAILed. GDBserver always reported the breakpoint hit for the same thread. Turns out that I broke gdbserver's thread event randomization recently, with git commit 582511be ([gdbserver] linux-low.c: better starvation avoidance, handle non-stop mode too). In that commit I missed that the thread structure also has a status_pending_p field... The end result was that count_events_callback always returns 0, and then if no thread is stepping, select_event_lwp always returns the event thread. IOW, no randomization is happening at all. Quite curious how all the other changes in that patch were sufficient to fix non-stop-fair-events.exp anyway even with that broken. Tested on x86_64 Fedora 20, native and gdbserver. gdb/gdbserver/ChangeLog: 2015-03-19 Pedro Alves <palves@redhat.com> * linux-low.c (count_events_callback, select_event_lwp_callback): Use the lwp's status_pending_p field, not the thread's. gdb/testsuite/ChangeLog: 2015-03-19 Pedro Alves <palves@redhat.com> * gdb.threads/continue-pending-status.exp (saw_thread_2) (saw_thread_3): New globals. (top level): Increment them when an event for the corresponding thread is seen. (no thread starvation): New test.
2015-03-15 20:35:26 +01:00
2015-03-19 Pedro Alves <palves@redhat.com>
* gdb.threads/continue-pending-status.exp (saw_thread_2)
(saw_thread_3): New globals.
(top level): Increment them when an event for the corresponding
thread is seen.
(no thread starvation): New test.
native/Linux: internal error if resume is short-circuited If the linux_nat_resume's short-circuits the resume because the current thread has a pending status, and, a thread with a higher number was previously stopped for a breakpoint, GDB internal errors, like: /home/pedro/gdb/mygit/src/gdb/linux-nat.c:2590: internal-error: status_callback: Assertion `lp->status != 0' failed. Fix this by make status_callback bail out earlier. GDBserver is already doing the same. New test added that exercises this. gdb/ChangeLog: 2015-03-19 Pedro Alves <palves@redhat.com> * linux-nat.c (status_callback): Return early if the LWP has no status pending. gdb/testsuite/ChangeLog: 2015-03-19 Pedro Alves <palves@redhat.com> * gdb.threads/continue-pending-status.c: New file. * gdb.threads/continue-pending-status.exp: New file.
2015-03-19 13:20:25 +01:00
2015-03-19 Pedro Alves <palves@redhat.com>
* gdb.threads/continue-pending-status.c: New file.
* gdb.threads/continue-pending-status.exp: New file.
Tighten gdb.base/disp-step-syscall.exp This fixes several problems with this test. E.g,. with --target_board=native-extended-gdbserver on x86_64 Fedora 20, I get: Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/disp-step-syscall.exp ... FAIL: gdb.base/disp-step-syscall.exp: vfork: get hexadecimal valueof "$pc" (timeout) FAIL: gdb.base/disp-step-syscall.exp: vfork: single step over vfork final pc FAIL: gdb.base/disp-step-syscall.exp: vfork: delete break vfork insn FAIL: gdb.base/disp-step-syscall.exp: vfork: continue to marker (vfork) (the program is no longer running) And with --target=native-gdbserver, I get: Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/disp-step-syscall.exp ... KPASS: gdb.base/disp-step-syscall.exp: vfork: single step over vfork (PRMS server/13796) FAIL: gdb.base/disp-step-syscall.exp: vfork: get hexadecimal valueof "$pc" (timeout) FAIL: gdb.base/disp-step-syscall.exp: vfork: single step over vfork final pc FAIL: gdb.base/disp-step-syscall.exp: vfork: delete break vfork insn FAIL: gdb.base/disp-step-syscall.exp: vfork: continue to marker (vfork) (the program is no longer running) First, the lack of fork support on remote targets is supposed to be kfailed, so the KPASS is obviously bogus. The extended-remote board should have KFAILed too. The problem is that the test is using "is_remote" instead of gdb_is_target_remote. And then, I get: (gdb) PASS: gdb.base/disp-step-syscall.exp: vfork: set displaced-stepping on stepi Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. (gdb) PASS: gdb.base/disp-step-syscall.exp: vfork: single step over vfork Obviously, that should be a FAIL. The problem is that the test only expects SIGILL, not SIGSEGV. It also doesn't bail correctly if an internal error or some other pattern caught by gdb_test_multiple matches. The test doesn't really need to match specific exits/crashes patterns, if the PASS regex is improved, like in ... ... this and the other "stepi" tests are a bit too lax, passing on ".*". This tightens those up to expect "x/i" and the "=>" current PC indicator, like in: 1: x/i $pc => 0x3b36abc9e2 <vfork+34>: syscall On x86_64 Fedora 20, I now get a quick KFAIL instead of timeouts with both the native-extended-gdbserver and native-gdbserver boards: PASS: gdb.base/disp-step-syscall.exp: vfork: delete break vfork PASS: gdb.base/disp-step-syscall.exp: vfork: continue to syscall insn vfork PASS: gdb.base/disp-step-syscall.exp: vfork: set displaced-stepping on KFAIL: gdb.base/disp-step-syscall.exp: vfork: single step over vfork (PRMS: server/13796) and a full pass with native testing. gdb/testsuite/ 2015-03-18 Pedro Alves <palves@redhat.com> * gdb.base/disp-step-syscall.exp (disp_step_cross_syscall): Use gdb_is_target_remote instead of is_remote. Use gdb_test_multiple instead of gdb_expect. Exit early if gdb_test_multiple hits its internal matches. Tighten stepi tests expected output. Fail on exit with any signal, instead of just SIGILL.
2015-03-18 20:28:08 +01:00
2015-03-18 Pedro Alves <palves@redhat.com>
* gdb.base/disp-step-syscall.exp (disp_step_cross_syscall):
Use gdb_is_target_remote instead of is_remote. Use
gdb_test_multiple instead of gdb_expect. Exit early if
gdb_test_multiple hits its internal matches. Tighten stepi tests
expected output. Fail on exit with any signal, instead of just
SIGILL.
Support catch syscall on aarch64 linux Hi, This patch is to support catch syscall on aarch64 linux. We implement gdbarch method get_syscall_number for aarch64-linux, and add aarch64-linux.xml file, which looks straightforward, however the changes to test case doesn't. First of all, we enable catch-syscall.exp on aarch64-linux target, but skip the multi_arch testing on current stage. I plan to touch multi arch debugging on aarch64-linux later. Then, when I run catch-syscall.exp on aarch64-linux, gcc errors that SYS_pipe isn't defined. We find that aarch64 kernel only has pipe2 syscall and libc already convert pipe to pipe2. As a result, I change catch-syscall.c to use SYS_pipe if it is defined, otherwise use SYS_pipe2 instead. The vector all_syscalls in catch-syscall.exp can't be pre-determined, so I add a new proc setup_all_syscalls to fill it, according to the availability of SYS_pipe. Regression tested on {x86_64, aarch64}-linux x {native, gdbserver}. gdb: 2015-03-18 Yao Qi <yao.qi@linaro.org> PR tdep/18107 * aarch64-linux-tdep.c: Include xml-syscall.h (aarch64_linux_get_syscall_number): New function. (aarch64_linux_init_abi): Call set_gdbarch_get_syscall_number. * syscalls/aarch64-linux.xml: New file. gdb/testsuite: 2015-03-18 Yao Qi <yao.qi@linaro.org> PR tdep/18107 * gdb.base/catch-syscall.c [!SYS_pipe] (pipe2_syscall): New variable. * gdb.base/catch-syscall.exp: Don't skip it on aarch64*-*-linux* target. Remove elements in all_syscalls. (test_catch_syscall_multi_arch): Skip it on aarch64*-linux* target. (setup_all_syscalls): New proc.
2015-03-18 11:47:45 +01:00
2015-03-18 Yao Qi <yao.qi@linaro.org>
PR tdep/18107
* gdb.base/catch-syscall.c [!SYS_pipe] (pipe2_syscall): New
variable.
* gdb.base/catch-syscall.exp: Don't skip it on
aarch64*-*-linux* target. Remove elements in all_syscalls.
(test_catch_syscall_multi_arch): Skip it on aarch64*-linux*
target.
(setup_all_syscalls): New proc.
watchpoint-reuse-slot.exp: skip setting HW breakpoints on some address We see some fails in watchpoint-reuse-slot.exp on aarch64-linux, because it sets some HW breakpoint on some address doesn't meet the alignment requirements by kernel, kernel will reject the ptrace (PTRACE_SETHBPREGS) call, and some fails are caused, for example: (gdb) PASS: gdb.base/watchpoint-reuse-slot.exp: always-inserted off: watch x hbreak: : width 1, iter 0: base + 0: delete $bpnum hbreak *(buf.byte + 0 + 1)^M Hardware assisted breakpoint 80 at 0x410a61^M (gdb) PASS: gdb.base/watchpoint-reuse-slot.exp: always-inserted off: watch x hbreak: : width 1, iter 0: base + 1: hbreak *(buf.byte + 0 + 1) stepi^M Warning:^M Cannot insert hardware breakpoint 80.^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 hbreak: : width 1, iter 0: base + 1: stepi advanced hbreak *(buf.byte + 0 + 1)^M Hardware assisted breakpoint 440 at 0x410a61^M Warning:^M Cannot insert hardware breakpoint 440.^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 hbreak: : width 1, iter 0: base + 1: hbreak *(buf.byte + 0 + 1) This patch is to skip some tests by checking proc valid_addr_p. We can handle other targets in valid_addr_p too. gdb/testsuite: 2015-03-16 Yao Qi <yao.qi@linaro.org> * gdb.base/watchpoint-reuse-slot.exp (valid_addr_p): New proc. (top level): Skip tests if valid_addr_p returns false for $cmd1 or $cmd2.
2015-03-13 11:56:01 +01:00
2015-03-16 Yao Qi <yao.qi@linaro.org>
* gdb.base/watchpoint-reuse-slot.exp (valid_addr_p): New proc.
(top level): Skip tests if valid_addr_p returns false for
$cmd1 or $cmd2.
Add objfile-progspace to Guile interface This commit adds an objfile-progspace accessor to the (gdb) Guile module. gdb/testsuite/ChangeLog: * gdb.guile/scm-objfile.exp: Add objfile-progspace test. gdb/doc/ChangeLog: * guile.texi (Objfiles In Guile): Document objfile-progspace. gdb/ChangeLog: * guile/scm-objfile.c (gdbscm_objfile_progspace): New function. (objfile_functions): Bind gdbscm_objfile_progspace to objfile-progspace. * guile/lib/gdb.scm: Add objfile-progspace to exports.
2015-03-11 14:20:06 +01:00
2015-03-11 Andy Wingo <wingo@igalia.com>
* gdb.guile/scm-objfile.exp: Add objfile-progspace test.
Typo fix Fix typo "inferiorr". gdb/testsuite: 2015-03-11 Yao Qi <yao.qi@linaro.org> * gdb.base/catch-syscall.exp: Fix typo in comments.
2015-03-11 12:50:12 +01:00
2015-03-11 Yao Qi <yao.qi@linaro.org>
* gdb.base/catch-syscall.exp: Fix typo in comments.
Skip catch-syscall.exp on HP-UX target "catch syscall" doesn't work on HP-UX. gdb/testsuite: 2015-03-11 Yao Qi <yao.qi@linaro.org> * gdb.base/catch-syscall.exp: Skip it on HP-UX target.
2015-03-11 12:43:07 +01:00
2015-03-11 Yao Qi <yao.qi@linaro.org>
* gdb.base/catch-syscall.exp: Skip it on HP-UX target.
Delete gdb/testsuite/dg-extract-results.py Unfortunately, the Python version of the dg-extract-results.sh script doesn't produce stable-enough results for GDB. The test messages appear to end up alpha sorted (losing the original sequence) and also sorting changes between runs for some reason. That may be tolerable for GCC, but for GDB, it often renders test results diffing between different revisions unworkable. Until that is fixed upstream, delete the script from the GDB tree. testsuite/ChangeLog: 2015-03-09 Pedro Alves <palves@redhat.com> * dg-extract-results.py: Delete.
2015-03-09 18:47:18 +01:00
2015-03-09 Pedro Alves <palves@redhat.com>
* dg-extract-results.py: Delete.
Make dg-extract-results.sh explicitly treat .{sum,log} files as text This merges Sergio's fix from GCC: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01293.html gdb/testsuite/ChangeLog: 2015-03-09 Pedro Alves <palves@redhat.com> Merge dg-extract-results.sh from GCC upstream (r218843). 2014-12-17 Sergio Durigan Junior <sergiodj@redhat.com> * dg-extract-results.sh: Use --text with grep to avoid issues with binary files. Fall back to cat -v, if that doesn't work.
2015-03-09 18:47:17 +01:00
2015-03-09 Pedro Alves <palves@redhat.com>
Merge dg-extract-results.sh from GCC upstream (r218843).
2014-12-17 Sergio Durigan Junior <sergiodj@redhat.com>
* dg-extract-results.sh: Use --text with grep to avoid issues with
binary files. Fall back to cat -v, if that doesn't work.
gdb.base/bp-permanent.exp: Tighten regex Trying to fix a permanent breakpoints bug, I broke "next" over a regular breakpoint. "next" would immediately hit the breakpoint the program was already stopped at. But, the "next over setup" test failed to notice this and still issued a pass. That's because the regex matches "testsuite" in: Breakpoint 2 at 0x400687: file src/gdb/testsuite/gdb.base/bp-permanent.c, line 46. gdb/testsuite/ChangeLog: 2015-03-05 Pedro Alves <palves@redhat.com> * gdb.base/bp-permanent.exp: Tighten "next over setup" regex.
2015-03-06 00:39:46 +01:00
2015-03-05 Pedro Alves <palves@redhat.com>
* gdb.base/bp-permanent.exp: Tighten "next over setup" regex.
Accept all-stop alternative in mi_expect_interrupt When interrupting a thread in non-stop vs all-stop, the signal given in the MI *stopped event is not the same. Currently, mi_expect_interrupt only accepts the case for non-stop, so this adds the alternative for all-stop. gdb/testsuite/ChangeLog: * lib/mi-support.exp (mi_expect_interrupt): Accept alternative event for when in all-stop mode.
2015-03-04 17:37:31 +01:00
2015-03-04 Simon Marchi <simon.marchi@ericsson.com>
* lib/mi-support.exp (mi_expect_interrupt): Accept
alternative event for when in all-stop mode.
Fix gdb.threads/thread-specific-bp.exp race Gary stumbled on this: (gdb) PASS: gdb.threads/thread-specific-bp.exp: all-stop: continue to end info threads Id Target Id Frame * 1 Thread 0x7ffff7fdb700 (LWP 13717) "thread-specific" end () at /home/gary/work/archer/startswith/src/gdb/testsuite/gdb.threads/thread-specific-bp.c:29 (gdb) FAIL: gdb.threads/thread-specific-bp.exp: all-stop: thread start is gone info breakpoint The problem is that "...archer/startswith/src..." has a "start" in it, which matches the too-lax regex in the test. Rather than tweaking the regex, we can just remove the whole "info threads", like we removed similar ones in other files -- GDB nowadays does this implicitly already, so things should work without it. Thus removing this even improves testing here a bit. gdb/testsuite/ChangeLog: 2015-03-04 Pedro Alves <palves@redhat.com> * gdb.threads/thread-specific-bp.exp: Delete "info threads" test.
2015-03-04 18:23:55 +01:00
2015-03-04 Pedro Alves <palves@redhat.com>
* gdb.threads/thread-specific-bp.exp: Delete "info threads" test.
Stupid git! Apparently fixing a typo while you're editing the commit message doesn't work.
2015-03-04 15:36:03 +01:00
2015-03-04 Mark Kettenis <kettenis@gnu.org>
Enable gdb.base/foll-fork.exp on OpenBSD gdb/testsuite/ 2015-03-04 Mark Kettenis <kettenis@gnu.org> * gdb.base/foll-fork.exp: Enable on *-*-openbsd*.
2015-03-04 14:53:14 +01:00
* gdb.base/foll-fork.exp: Enable on *-*-openbsd*.
breakpoint-in-ro-region.exp: Support targets stopping in mid-line after "si" On some targets each of the assignments "i = 0" in the C source for "breakpoint-in-ro-region.exp" are compiled to a single instruction. Then each "si" stops at the beginning of the next source line. But on some other targets (like s390) such an assignment compiles to multiple instructions. Then "si" may stop in mid-line, and GDB displays the PC address in addition to the source line number. This was not considered by the regexp for this case. gdb/testsuite/ChangeLog: * gdb.base/breakpoint-in-ro-region.exp (test_single_step): In the regexps for GDB's current line display, accept a hex address preceding the line number.
2015-03-04 10:40:40 +01:00
2015-03-04 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/breakpoint-in-ro-region.exp (test_single_step): In the
regexps for GDB's current line display, accept a hex address
preceding the line number.
catch-syscall.exp: Fix missing architecture name for s390:31-bit For the "multiple targets" test in catch-syscall.exp, set the 'arch1' variable to a valid string. gdb/testsuite/ChangeLog: * gdb.base/catch-syscall.exp (test_catch_syscall_multi_arch): Set the 'arch1' variable for "s390*-linux*" targets.
2015-03-04 10:40:40 +01:00
2015-03-04 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/catch-syscall.exp (test_catch_syscall_multi_arch): Set
the 'arch1' variable for "s390*-linux*" targets.
gdb.threads/clone-thread_db.c: Add missing includes and fix pthread_join call This fixes: > gdb compile failed, /gdb/testsuite/gdb.threads/clone-thread_db.c: In function 'main': > /gdb/testsuite/gdb.threads/clone-thread_db.c:67:3: warning: implicit declaration of function 'alarm' [-Wimplicit-function-declaration] > alarm (300); > ^ > /gdb/testsuite/gdb.threads/clone-thread_db.c:69:3: warning: implicit declaration of function 'pthread_create' [-Wimplicit-function-declaration] > pthread_create (&child, NULL, thread_fn, NULL); > ^ > /gdb/testsuite/gdb.threads/clone-thread_db.c:70:3: warning: implicit declaration of function 'pthread_join' [-Wimplicit-function-declaration] > pthread_join (child); > ^ And then adding the missing headers revealed the pthread_join call was incorrect. This probably fixes the crash we see on ppc64be, e.g., at https://sourceware.org/ml/gdb-testers/2015-q1/msg04415.html the logs there show: ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x3fffb7ff54a0 (LWP 9275)] 0x00003fffb7f3ce74 in .pthread_join () from /lib64/libpthread.so.0 (gdb) FAIL: gdb.threads/clone-thread_db.exp: continue to end ... Tested on x86_64 Fedora 20. gdb/testsuite/ 2015-03-04 Pedro Alves <palves@redhat.com> * gdb.threads/clone-thread_db.c: Include unistd.h and pthread.h. (main): Pass missing retval argument to pthread_join call.
2015-03-04 10:13:49 +01:00
2015-03-04 Pedro Alves <palves@redhat.com>
* gdb.threads/clone-thread_db.c: Include unistd.h and pthread.h.
(main): Pass missing retval argument to pthread_join call.
follow-exec: delete all non-execing threads This fixes invalid reads Valgrind first caught when debugging against a GDBserver patched with a series that adds exec events to the remote protocol. Like these, using the gdb.threads/thread-execl.exp test: $ valgrind ./gdb -data-directory=data-directory ./testsuite/gdb.threads/thread-execl -ex "tar extended-remote :9999" -ex "b thread_execler" -ex "c" -ex "set scheduler-locking on" ... Breakpoint 1, thread_execler (arg=0x0) at src/gdb/testsuite/gdb.threads/thread-execl.c:29 29 if (execl (image, image, NULL) == -1) (gdb) n Thread 32509.32509 is executing new program: build/gdb/testsuite/gdb.threads/thread-execl [New Thread 32509.32532] ==32510== Invalid read of size 4 ==32510== at 0x5AA7D8: delete_breakpoint (breakpoint.c:13989) ==32510== by 0x6285D3: delete_thread_breakpoint (thread.c:100) ==32510== by 0x628603: delete_step_resume_breakpoint (thread.c:109) ==32510== by 0x61622B: delete_thread_infrun_breakpoints (infrun.c:2928) ==32510== by 0x6162EF: for_each_just_stopped_thread (infrun.c:2958) ==32510== by 0x616311: delete_just_stopped_threads_infrun_breakpoints (infrun.c:2969) ==32510== by 0x616C96: fetch_inferior_event (infrun.c:3267) ==32510== by 0x63A2DE: inferior_event_handler (inf-loop.c:57) ==32510== by 0x4E0E56: remote_async_serial_handler (remote.c:11877) ==32510== by 0x4AF620: run_async_handler_and_reschedule (ser-base.c:137) ==32510== by 0x4AF6F0: fd_event (ser-base.c:182) ==32510== by 0x63806D: handle_file_event (event-loop.c:762) ==32510== Address 0xcf333e0 is 16 bytes inside a block of size 200 free'd ==32510== at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==32510== by 0x77CB74: xfree (common-utils.c:98) ==32510== by 0x5AA954: delete_breakpoint (breakpoint.c:14056) ==32510== by 0x5988BD: update_breakpoints_after_exec (breakpoint.c:3765) ==32510== by 0x61360F: follow_exec (infrun.c:1091) ==32510== by 0x6186FA: handle_inferior_event (infrun.c:4061) ==32510== by 0x616C55: fetch_inferior_event (infrun.c:3261) ==32510== by 0x63A2DE: inferior_event_handler (inf-loop.c:57) ==32510== by 0x4E0E56: remote_async_serial_handler (remote.c:11877) ==32510== by 0x4AF620: run_async_handler_and_reschedule (ser-base.c:137) ==32510== by 0x4AF6F0: fd_event (ser-base.c:182) ==32510== by 0x63806D: handle_file_event (event-loop.c:762) ==32510== [Switching to Thread 32509.32532] Breakpoint 1, thread_execler (arg=0x0) at src/gdb/testsuite/gdb.threads/thread-execl.c:29 29 if (execl (image, image, NULL) == -1) (gdb) The breakpoint in question is the step-resume breakpoint of the non-main thread, the one that was "next"ed. The exact same issue can be seen on mainline with native debugging, by running the thread-execl.exp test in non-stop mode, because the kernel doesn't report a thread exit event for the execing thread. Tested on x86_64 Fedora 20. gdb/ChangeLog: 2015-03-02 Pedro Alves <palves@redhat.com> * infrun.c (follow_exec): Delete all threads of the process except the event thread. Extended comments. gdb/testsuite/ChangeLog: 2015-03-02 Pedro Alves <palves@redhat.com> * gdb.threads/thread-execl.exp (do_test): Handle non-stop. (top level): Call do_test with non-stop as well.
2015-03-03 02:25:17 +01:00
2015-03-02 Pedro Alves <palves@redhat.com>
* gdb.threads/thread-execl.exp (do_test): Handle non-stop.
(top level): Call do_test with non-stop as well.
gdb_test_multiple: return -1 on internal error gdb_test_multiple is supposed to return -1 on internal error: # Returns: # 1 if the test failed, according to a built-in failure pattern # 0 if only user-supplied patterns matched # -1 if there was an internal error. But alas, that's broken, it returns success... It looks like the code is assuming an earlier 'set result -1' is still in effect, but 'result' is set to 0 at the end, just before we call gdb_expect: set result 0 set code [catch {gdb_expect $code} string] gdb/testsuite/ 2015-03-02 Pedro Alves <palves@redhat.com> * lib/gdb.exp (gdb_test_multiple) <internal error>: Set result to -1.
2015-03-02 21:05:25 +01:00
2015-03-02 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_test_multiple) <internal error>: Set result to
-1.
S390: Vector register test case Add a test case for S/390 vector registers support. gdb/testsuite/ChangeLog: * gdb.arch/s390-vregs.exp: New test. * gdb.arch/s390-vregs.S: New file.
2015-03-02 10:57:40 +01:00
2015-03-02 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.arch/s390-vregs.exp: New test.
* gdb.arch/s390-vregs.S: New file.
catch_command_errors: Remove 'mask' parameter All callers of catch_command_errors pass RETURN_MASK_ALL as mask argument. This patch eliminates the mask parameter as unnecessary. gdb/ChangeLog: 2015-02-27 Pedro Alves <palves@redhat.com> * main.c (catch_command_errors, catch_command_errors_const): Remove 'mask' argument. Adjust. (captured_main): Adjust callers. gdb/testsuite/ChangeLog: 2015-02-27 Pedro Alves <palves@redhat.com> * gdb.gdb/python-interrupts.exp (test_python_interrupts): Adjust call to catch_command_errors. * gdb.gdb/python-selftest.exp (selftest_python): Adjust call to catch_command_errors.
2015-02-09 15:59:10 +01:00
2015-02-27 Pedro Alves <palves@redhat.com>
* gdb.gdb/python-interrupts.exp (test_python_interrupts): Adjust
call to catch_command_errors.
* gdb.gdb/python-selftest.exp (selftest_python): Adjust call to
catch_command_errors.
Adjust self tests to cope with GDB built as a C++ program gdb/testsuite/ 2015-02-27 Pedro Alves <palves@redhat.com> * gdb.gdb/complaints.exp (test_initial_complaints): Also accept "true" for boolean result. * gdb.gdb/selftest.exp (test_with_self): Also accept full prototype of main.
2014-10-22 16:14:41 +02:00
2015-02-27 Pedro Alves <palves@redhat.com>
* gdb.gdb/complaints.exp (test_initial_complaints): Also accept
"true" for boolean result.
* gdb.gdb/selftest.exp (test_with_self): Also accept full
prototype of main.
Add "../lib/unbuffer_output.c" and use it in gdb.base/interrupt.c In some scenarios, GDB or GDBserver can be spawned with input _not_ connected to a tty, and then tests that rely on stdio fail with timeouts, because the inferior's stdout and stderr streams end up fully buffered. See discussion here: https://sourceware.org/ml/gdb-patches/2015-02/msg00809.html We have a hack in place that works around this for Windows testing, that forces every test program to link with an .o file that does (lib/set_unbuffered_mode.c): static int __gdb_set_unbuffered_output (void) __attribute__ ((constructor)); static int __gdb_set_unbuffered_output (void) { setvbuf (stdout, NULL, _IONBF, BUFSIZ); setvbuf (stderr, NULL, _IONBF, BUFSIZ); } That's a bit hacky; it ends up done for _all_ tests. This patch adds a way to do this unbuffering explicitly from the test code itself, so it is done only when necessary, and for all targets/hosts. For starters, it adjusts gdb.base/interrupt.c to use it. Tested on x86_64 Fedora 20, native, and against a remote gdbserver board file that connects to the target with ssh, with and without -t (create pty). gdb/testsuite/ 2015-02-27 Pedro Alves <palves@redhat.com> * lib/unbuffer_output.c: New file. * gdb.base/interrupt.c: Include "../lib/unbuffer_output.c". (main): Call gdb_unbuffer_output.
2015-02-27 14:54:22 +01:00
2015-02-27 Pedro Alves <palves@redhat.com>
* lib/unbuffer_output.c: New file.
* gdb.base/interrupt.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
Don't skip catch-syscall.exp on hppa*-hp-hpux* target As far as I know, "catch syscall" is supported on hppa*-hp-hpux*, but the test catch-syscall.exp is skipped on this target by mistake. This patch is to fix it. However, I don't have a hpux machine to test. gdb/testsuite: 2015-02-27 Yao Qi <yao.qi@linaro.org> * gdb.base/catch-syscall.exp: Don't skip it on hppa*-hp-hpux* target.
2015-02-27 14:45:06 +01:00
2015-02-27 Yao Qi <yao.qi@linaro.org>
* gdb.base/catch-syscall.exp: Don't skip it on hppa*-hp-hpux*
target.
Add missing CHECK_TYPEDEF calls to recent vptr_{fieldno,basetype} cleanup. gdb/ChangeLog: * gdbtypes.c (internal_type_vptr_fieldno): Add missing call to CHECK_TYPEDEF. (set_type_vptr_fieldno): Ditto. (internal_type_vptr_basetype, set_type_vptr_basetype): Ditto. * gnu-v3-abi.c (gnuv3_dynamic_class): Ditto. gdb/testsuite/ChangeLog: * gdb.cp/class2.cc (Dbase, D): New classes. (main): New local delta. * gdb.cp/class2.exp: Test printing delta. * gdb.cp/classes.cc (DynamicBase2, DynamicBar): New classes. (dynbar): New global. * gdb.cp/classes.exp (test_ptype_class_objects): Test ptype DynamicBar.
2015-02-27 02:31:29 +01:00
2015-02-26 Doug Evans <dje@google.com>
* gdb.cp/class2.cc (Dbase, D): New classes.
(main): New local delta.
* gdb.cp/class2.exp: Test printing delta.
* gdb.cp/classes.cc (DynamicBase2, DynamicBar): New classes.
(dynbar): New global.
* gdb.cp/classes.exp (test_ptype_class_objects): Test ptype DynamicBar.
compile: Fix GNU-IFUNC funcs called from injected code One could not call IFUNCs (=indirect functions) from the compiled injected code. Either it errored with: gdb command line:1:1: error: function return type cannot be function or it just called the IFUNC dispatcher in normal way, returning real function implementation address instead of the function return value (and thus no function was called). gdb/ChangeLog 2015-02-26 Jan Kratochvil <jan.kratochvil@redhat.com> * compile/compile-c-symbols.c (convert_one_symbol, convert_symbol_bmsym) (gcc_symbol_address): Call gnu_ifunc_resolve_addr. gdb/testsuite/ChangeLog 2015-02-26 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.compile/compile-ifunc.c: New file. * gdb.compile/compile-ifunc.exp: New file.
2015-02-26 17:40:57 +01:00
2015-02-26 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.compile/compile-ifunc.c: New file.
* gdb.compile/compile-ifunc.exp: New file.
Fix print of value type in a corner case of finish When doing finish in a function, if gdb fails to return a value, gdb also fails at printing the value type if this type is a struct. For example : (gdb) fin .... Value returned has type: . Cannot determine contents This patch fixes this by calling type_to_string to print the type so that we can support these types. This patch returns the following example output : (gdb) fin .... Value returned has type: struct test. Cannot determine contents Also, this patch modifies structs.exp to check that we return the correct type. gdb/ChangeLog: * gdb/infcmd.c (print_return_value): use type_to_string to print type. gdb/testsuite/ChangeLog: * gdb.base/structs.exp: Check for correct struct on finish.
2015-02-25 17:00:01 +01:00
2015-02-26 Antoine Tremblay <antoine.tremblay@ericsson.com>
* gdb.base/structs.exp: Check for correct struct on finish.
Dwarf assembler: handle one instruction function On aarch64, we got the following fail: (gdb) disassemble func Dump of assembler code for function func: 0x0000000000400730 <+0>: ret End of assembler dump.^M (gdb) x/2i func+0^M 0x400730 <func>: ret^M 0x400734 <main>: stp x29, x30, [sp,#-16]!^M (gdb) FAIL: gdb.dwarf2/dw2-ifort-parameter.exp: x/2i func+0 the pattern in proc function_range expects to match <func+0>, however, GDB doesn't display the offset when it is zero. This patch is to adjust the pattern when $func_length is zero. gdb/testsuite: 2015-02-26 Yao Qi <yao.qi@linaro.org> * lib/dwarf.exp (function_range): Adjust pattern when $func_length is zero.
2015-02-26 15:21:19 +01:00
2015-02-26 Yao Qi <yao.qi@linaro.org>
* lib/dwarf.exp (function_range): Adjust pattern when $func_length
is zero.
SEGV in ppc64_elf_get_synthetic_symtab reading a separate debug file The attached patch fixes the SEGV and lets GDB successfully load all kernel modules installed by default on RHEL 7. Valgrind on F-21 x86_64 host has shown me more clear what is the problem: Reading symbols from /home/jkratoch/t/cordic.ko...Reading symbols from /home/jkratoch/t/cordic.ko.debug...================================================================= ==22763==ERROR: AddressSanitizer: heap-use-after-free on address 0x6120000461c8 at pc 0x150cdbd bp 0x7fffffffc7e0 sp 0x7fffffffc7d0 READ of size 8 at 0x6120000461c8 thread T0 #0 0x150cdbc in ppc64_elf_get_synthetic_symtab /home/jkratoch/redhat/gdb-test-asan/bfd/elf64-ppc.c:3282 #1 0x8c5274 in elf_read_minimal_symbols /home/jkratoch/redhat/gdb-test-asan/gdb/elfread.c:1205 #2 0x8c55e7 in elf_symfile_read /home/jkratoch/redhat/gdb-test-asan/gdb/elfread.c:1268 [...] 0x6120000461c8 is located 264 bytes inside of 288-byte region [0x6120000460c0,0x6120000461e0) freed by thread T0 here: #0 0x7ffff715454f in __interceptor_free (/lib64/libasan.so.1+0x5754f) #1 0xde9cde in xfree common/common-utils.c:98 #2 0x9a04f7 in do_my_cleanups common/cleanups.c:155 #3 0x9a05d3 in do_cleanups common/cleanups.c:177 #4 0x8c538a in elf_read_minimal_symbols /home/jkratoch/redhat/gdb-test-asan/gdb/elfread.c:1229 #5 0x8c55e7 in elf_symfile_read /home/jkratoch/redhat/gdb-test-asan/gdb/elfread.c:1268 [...] previously allocated by thread T0 here: #0 0x7ffff71547c7 in malloc (/lib64/libasan.so.1+0x577c7) #1 0xde9b95 in xmalloc common/common-utils.c:41 #2 0x8c4da2 in elf_read_minimal_symbols /home/jkratoch/redhat/gdb-test-asan/gdb/elfread.c:1147 #3 0x8c55e7 in elf_symfile_read /home/jkratoch/redhat/gdb-test-asan/gdb/elfread.c:1268 [...] SUMMARY: AddressSanitizer: heap-use-after-free /home/jkratoch/redhat/gdb-test-asan/bfd/elf64-ppc.c:3282 ppc64_elf_get_synthetic_symtab [...] ==22763==ABORTING A similar case a few lines later I have fixed in 2010 by: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=3f1eff0a2c7f0e7078f011f55b8e7f710aae0cc2 My testcase does not always reproduce it but at least a bit: * GDB without ppc64 target (even as a secondary one) is reported as "untested" * ASAN-built GDB with ppc64 target always crashes (and PASSes with this fix) * unpatched non-ASAN-built GDB with ppc64 target crashes from commandline * unpatched non-ASAN-built GDB with ppc64 target PASSes from runtest (?) gdb/ChangeLog 2015-02-26 Jan Kratochvil <jan.kratochvil@redhat.com> * elfread.c (elf_read_minimal_symbols): Use bfd_alloc for bfd_canonicalize_symtab. gdb/testsuite/ChangeLog 2015-02-26 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.arch/cordic.ko.bz2: New file. * gdb.arch/cordic.ko.debug.bz2: New file. * gdb.arch/ppc64-symtab-cordic.exp: New file.
2015-02-26 14:08:01 +01:00
2015-02-26 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/cordic.ko.bz2: New file.
* gdb.arch/cordic.ko.debug.bz2: New file.
* gdb.arch/ppc64-symtab-cordic.exp: New file.
[aarch64] Fix one fail in gdb.xml/tdesc-regs.exp Hi, I see the following fail in aarch64-linux-gnu testing... (gdb) set tdesc file /XXX/gdb/testsuite/gdb.xml/single-reg.xml^M warning: Architecture rejected target-supplied description^M (gdb) FAIL: gdb.xml/tdesc-regs.exp: set tdesc file single-reg.xml core-regs isn't set for aarch64 target, and looks it is an oversight when aarch64 port was added. gdb/testsuite: 2015-02-25 Yao Qi <yao.qi@linaro.org> * gdb.xml/tdesc-regs.exp: Set core-regs to aarch64-core.xml for aarch64*-*-* target.
2015-02-25 11:39:59 +01:00
2015-02-25 Yao Qi <yao.qi@linaro.org>
* gdb.xml/tdesc-regs.exp: Set core-regs to aarch64-core.xml for
aarch64*-*-* target.
delete_breakpoints: Rewrite using gdb_test_multiple Because delete_breakpoints uses gdb_expect directly, an internal error results in slow timeouts instead of quickly bailing out. This patch rewrites the procedure to use gdb_test_multiple instead, while preserving the existing general logic ("delete breakpoints" + "info breakpoints"). gdb/testsuite/ 2015-02-23 Pedro Alves <palves@redhat.com> * lib/gdb.exp (delete_breakpoints): Rewrite using gdb_test_multiple.
2015-02-23 18:35:09 +01:00
2015-02-23 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (delete_breakpoints): Rewrite using
gdb_test_multiple.
gdb.base/info-os.c: Include stdlib.h Fixes: > gdb compile failed, /gdb/testsuite/gdb.base/info-os.c: In function 'main': > /gdb/testsuite/gdb.base/info-os.c:65:3: warning: implicit declaration of function 'atexit' [-Wimplicit-function-declaration] > atexit (ipc_cleanup); > ^ > FAIL: gdb.base/info-os.exp: cannot compile test program with recent GCCs. gdb/testsuite/ChangeLog: 2015-02-23 Pedro Alves <palves@redhat.com> * gdb.base/info-os.c: Include stdlib.h.
2015-02-23 15:03:48 +01:00
2015-02-23 Pedro Alves <palves@redhat.com>
* gdb.base/info-os.c: Include stdlib.h.
testcase for PR symtab/17855 gdb/testsuite/ChangeLog: PR symtab/17855 * gdb.ada/exec_changed.exp: Add second test where symbol lookup cache is read after symbols have been re-read. * gdb.ada/exec_changed/first.adb (First): New procedure Break_Me. * gdb.ada/exec_changed/second.adb (Second): Ditto.
2015-02-22 18:11:55 +01:00
2015-02-22 Doug Evans <xdje42@gmail.com>
PR symtab/17855
* gdb.ada/exec_changed.exp: Add second test where symbol lookup cache
is read after symbols have been re-read.
* gdb.ada/exec_changed/first.adb (First): New procedure Break_Me.
* gdb.ada/exec_changed/second.adb (Second): Ditto.
PR c++/17976, symtab/17821 This patch addresses two issues. The basic problem is that "(anonymous namespace)" doesn't get entered into the symbol table because when dwarf2read.c:new_symbol_full is called the DIE has no name (dwarf2_name returns NULL). PR 17976: ptype '(anonymous namespace)' should work like any namespace PR 17821: perf issue looking up (anonymous namespace) bash$ gdb monster-program (gdb) mt set per on (gdb) mt set symbol-cache-size 0 (gdb) break (anonymous namespace)::foo Before: Command execution time: 3.266289 (cpu), 6.169030 (wall) Space used: 811429888 (+12910592 for this command) After: Command execution time: 1.264076 (cpu), 4.057408 (wall) Space used: 798781440 (+0 for this command) gdb/ChangeLog: PR c++/17976, symtab/17821 * cp-namespace.c (cp_search_static_and_baseclasses): New parameter is_in_anonymous. All callers updated. (find_symbol_in_baseclass): Ditto. (cp_lookup_nested_symbol_1): Ditto. Don't search all static blocks for symbols in an anonymous namespace. * dwarf2read.c (namespace_name): Don't call dwarf2_name, fetch DW_AT_name directly. (dwarf2_name): Convert missing namespace name to CP_ANONYMOUS_NAMESPACE_STR. gdeb/testsuite/ChangeLog: * gdb.cp/anon-ns.exp: Add test for ptype '(anonymous namespace)'.
2015-02-22 06:58:31 +01:00
2015-02-21 Doug Evans <dje@google.com>
* gdb.cp/anon-ns.exp: Add test for ptype '(anonymous namespace)'.
Testsuite patch for: i386: Fix internal error when prstatus in core file is too big gdb/testsuite/ChangeLog 2015-02-21 Jan Kratochvil <jan.kratochvil@redhat.com> PR corefiles/17808 * gdb.arch/i386-biarch-core.core.bz2: New file. * gdb.arch/i386-biarch-core.exp: New file.
2015-02-21 15:24:20 +01:00
2015-02-21 Jan Kratochvil <jan.kratochvil@redhat.com>
PR corefiles/17808
* gdb.arch/i386-biarch-core.core.bz2: New file.
* gdb.arch/i386-biarch-core.exp: New file.
gdb.threads/multi-create-ns-info-thr.exp and native-extended-remote board The buildbot shows that the new gdb.threads/multi-create-ns-info-thr.exp test is timing out when tested with --target=native-extended-remote. The reason is: No breakpoints or watchpoints. (gdb) break main Breakpoint 1 at 0x10000b00: file ../../../binutils-gdb/gdb/testsuite/gdb.threads/multi-create.c, line 72. (gdb) run Starting program: /home/gdb-buildbot/fedora-21-ppc64be-1/fedora-ppc64be-native-extended-gdbserver/build/gdb/testsuite/outputs/gdb.threads/multi-create-ns-info-thr/multi-cre ate-ns-info-thr Process /home/gdb-buildbot/fedora-21-ppc64be-1/fedora-ppc64be-native-extended-gdbserver/build/gdb/testsuite/outputs/gdb.threads/multi-create-ns-info-thr/multi-create-ns-inf o-thr created; pid = 16266 Unexpected vCont reply in non-stop mode: T0501:00003fffffffd190;40:00000080560fe290;thread:p3f8a.3f8a;core:0; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (gdb) break multi-create.c:45 Breakpoint 2 at 0x10000994: file ../../../binutils-gdb/gdb/testsuite/gdb.threads/multi-create.c, line 45. (gdb) commands Type commands for breakpoint(s) 2, one per line. Non-stop tests don't really work with the --target_board=native-extended-remote board, because tests toggle non-stop on after GDB is already connected to gdbserver, while Currently, non-stop must be enabled before connecting. This adjusts the test to bail if running to main fails, like all other non-stop tests. Note non-stop tests do work with --target_board=native-gdbserver. gdb/testsuite/ChangeLog: 2015-02-21 Pedro Alves <palves@redhat.com> * gdb.threads/multi-create-ns-info-thr.exp: Return early if runto_main fails.
2015-02-21 13:03:23 +01:00
2015-02-21 Pedro Alves <palves@redhat.com>
* gdb.threads/multi-create-ns-info-thr.exp: Return early if
runto_main fails.
Fix gdb.base/solib-corrupted.exp after dtrace probes changes Commit 6f9b8491 (Adapt `info probes' to support printing probes of different types.) added a new type column to "info probes". That caused a solib-corrupted.exp regression: ~~~~~~~~~~~~~~~~~~~~~ Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/solib-corrupted.exp ... FAIL: gdb.base/solib-corrupted.exp: corrupted list === gdb Summary === # of expected passes 2 # of unexpected failures 1 ~~~~~~~~~~~~~~~~~~~~~ Tested on x86_64 Fedora 20. gdb/testsuite/ChangeLog: 2015-02-20 Pedro Alves <palves@redhat.com> * gdb.base/solib-corrupted.exp: Expect "stap" as first column of info probes.
2015-02-21 00:10:53 +01:00
2015-02-20 Pedro Alves <palves@redhat.com>
* gdb.base/solib-corrupted.exp: Expect "stap" as first column of
info probes.
GNU/Linux: Stop using libthread_db/td_ta_thr_iter TL;DR - GDB can hang if something refreshes the thread list out of the target while the target is running. GDB hangs inside td_ta_thr_iter. The fix is to not use that libthread_db function anymore. Long version: Running the testsuite against my all-stop-on-top-of-non-stop series is still exposing latent non-stop bugs. I was originally seeing this with the multi-create.exp test, back when we were still using libthread_db thread event breakpoints. The all-stop-on-top-of-non-stop series forces a thread list refresh each time GDB needs to start stepping over a breakpoint (to pause all threads). That test hits the thread event breakpoint often, resulting in a bunch of step-over operations, thus a bunch of thread list refreshes while some threads in the target are running. The commit adds a real non-stop mode test that triggers the issue, based on multi-create.exp, that does an explicit "info threads" when a breakpoint is hit. IOW, it does the same things the as-ns series was doing when testing multi-create.exp. The bug is a race, so it unfortunately takes several runs for the test to trigger it. In fact, even when setting the test running in a loop, it sometimes takes several minutes for it to trigger for me. The race is related to libthread_db's td_ta_thr_iter. This is libthread_db's entry point for walking the thread list of the inferior. Sometimes, when GDB refreshes the thread list from the target, libthread_db's td_ta_thr_iter can somehow see glibc's thread list as a cycle, and get stuck in an infinite loop. The issue is that when a thread exits, its thread control structure in glibc is moved from a "used" list to a "cache" list. These lists are simply circular linked lists where the "next/prev" pointers are embedded in the thread control structure itself. The "next" pointer of the last element of the list points back to the list's sentinel "head". There's only one set of "next/prev" pointers for both lists; thus a thread can only be in one of the lists at a time, not in both simultaneously. So when thread C exits, simplifying, the following happens. A-C are threads. stack_used and stack_cache are the list's heads. Before: stack_used -> A -> B -> C -> (&stack_used) stack_cache -> (&stack_cache) After: stack_used -> A -> B -> (&stack_used) stack_cache -> C -> (&stack_cache) td_ta_thr_iter starts by iterating at the list's head's next, and iterates until it sees a thread whose next pointer points to the list's head again. Thus in the before case above, C's next points to stack_used, indicating end of list. In the same case, the stack_cache list is empty. For each thread being iterated, td_ta_thr_iter reads the whole thread object out of the inferior. This includes the thread's "next" pointer. In the scenario above, it may happen that td_ta_thr_iter is iterating thread B and has already read B's thread structure just before thread C exits and its control structure moves to the cached list. Now, recall that td_ta_thr_iter is running in the context of GDB, and there's no locking between GDB and the inferior. From it's local copy of B, td_ta_thr_iter believes that the next thread after B is thread C, so it happilly continues iterating to C, a thread that has already exited, and is now in the stack cache list. After iterating C, td_ta_thr_iter finds the stack_cache head, which because it is not stack_used, td_ta_thr_iter assumes it's just another thread. After this, unless the reverse race triggers, GDB gets stuck in td_ta_thr_iter forever walking the stack_cache list, as no thread in thatlist has a next pointer that points back to stack_used (the terminating condition). Before fully understanding the issue, I tried adding cycle detection to GDB's td_ta_thr_iter callback. However, td_ta_thr_iter skips calling the callback in some cases, which means that it's possible that the callback isn't called at all, making it impossible for GDB to break the loop. I did manage to get GDB stuck in that state more than once. Fortunately, we can avoid the issue altogether. We don't really need td_ta_thr_iter for live debugging nowadays, given PTRACE_EVENT_CLONE. We already know how to map and lwp id to a thread id without iterating (thread_from_lwp), so use that more. gdb/ChangeLog: 2015-02-20 Pedro Alves <palves@redhat.com> * linux-nat.c (linux_handle_extended_wait): Call thread_db_notice_clone whenever a new clone LWP is detected. (linux_stop_and_wait_all_lwps, linux_unstop_all_lwps): New functions. * linux-nat.h (thread_db_attach_lwp): Delete declaration. (thread_db_notice_clone, linux_stop_and_wait_all_lwps) (linux_unstop_all_lwps): Declare. * linux-thread-db.c (struct thread_get_info_inout): Delete. (thread_get_info_callback): Delete. (thread_from_lwp): Use td_thr_get_info and record_thread. (thread_db_attach_lwp): Delete. (thread_db_notice_clone): New function. (try_thread_db_load_1): If /proc is mounted and shows the process'es task list, walk over all LWPs and call thread_from_lwp instead of relying on td_ta_thr_iter. (attach_thread): Don't call check_thread_signals here. Split the tail part of the function (which adds the thread to the core GDB thread list) to ... (record_thread): ... this function. Call check_thread_signals here. (thread_db_wait): Don't call thread_db_find_new_threads_1. Always call thread_from_lwp. (thread_db_update_thread_list): Rename to ... (thread_db_update_thread_list_org): ... this. (thread_db_update_thread_list): New function. (thread_db_find_thread_from_tid): Delete. (thread_db_get_ada_task_ptid): Simplify. * nat/linux-procfs.c: Include <sys/stat.h>. (linux_proc_task_list_dir_exists): New function. * nat/linux-procfs.h (linux_proc_task_list_dir_exists): Declare. gdb/gdbserver/ChangeLog: 2015-02-20 Pedro Alves <palves@redhat.com> * thread-db.c: Include "nat/linux-procfs.h". (thread_db_init): Skip listing new threads if the kernel supports PTRACE_EVENT_CLONE and /proc/PID/task/ is accessible. gdb/testsuite/ChangeLog: 2015-02-20 Pedro Alves <palves@redhat.com> * gdb.threads/multi-create-ns-info-thr.exp: New file.
2015-02-20 21:21:59 +01:00
2015-02-20 Pedro Alves <palves@redhat.com>
* gdb.threads/multi-create-ns-info-thr.exp: New file.
Fix no-attach-trace.exp with "target remote" / gdbserver $ make check RUNTESTFLAGS="--target_board=native-gdbserver no-attach-trace.exp" ... (gdb) trace main Tracepoint 1 at 0x400594: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.trace/no-attach-trace.c, line 25. (gdb) PASS: gdb.trace/no-attach-trace.exp: set tracepoint on main tstart You can't do that when your target is `exec' (gdb) FAIL: gdb.trace/no-attach-trace.exp: tstart Even though this target supports tracing, the test restarts GDB and doesn't do gdb_run_cmd so does not reconnect to the remote target. So at that point, GDB only has the "exec" target, which obviously doesn't do tracing. The test is about doing "tstart" before running a program, so the fix is to do gdb_target_supports_trace with whatever target GDB ends up connected after clean_restart. Tested on x86_64 Fedora 20, native, native-gdbserver and native-extended-gdbserver boards. The test passes with the latter, and is skipped with the first two. gdb/testsuite/ChangeLog: 2015-02-20 Pedro Alves <palves@redhat.com> * gdb.trace/no-attach-trace.exp: Don't run to main. Do clean_restart before gdb_target_supports_trace.
2015-02-20 20:50:36 +01:00
2015-02-20 Pedro Alves <palves@redhat.com>
* gdb.trace/no-attach-trace.exp: Don't run to main. Do
clean_restart before gdb_target_supports_trace.
PR18006: internal error if threaded program calls clone(CLONE_VM) On GNU/Linux, if a pthreaded program has a thread call clone(CLONE_VM) directly, and then that clone LWP hits a debug event (breakpoint, etc.) GDB internal errors. Threaded programs shouldn't really be calling clone directly, but GDB shouldn't crash either. The crash looks like this: (gdb) break clone_fn Breakpoint 2 at 0x4007d8: file clone-thread_db.c, line 35. (gdb) r ... [Thread debugging using libthread_db enabled] ... src/gdb/linux-nat.c:1030: internal-error: lin_lwp_attach_lwp: Assertion `lwpid > 0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. The problem is that 'clone' ends up clearing the parent thread's tid field in glibc's thread data structure. For x86_64, the glibc code in question is here: sysdeps/unix/sysv/linux/x86_64/clone.S: ... testq $CLONE_THREAD, %rdi jne 1f testq $CLONE_VM, %rdi movl $-1, %eax <---- jne 2f movl $SYS_ify(getpid), %eax syscall 2: movl %eax, %fs:PID movl %eax, %fs:TID <---- 1: When GDB refreshes the thread list out of libthread_db, it finds a thread with LWP with pid -1 (the clone's parent), which naturally isn't yet on the thread list. GDB then tries to attach to that bogus LWP id, which is caught by that assertion. The fix is to detect the bad PID early. Tested on x86-64 Fedora 20. GDBserver doesn't need any fix. gdb/ChangeLog: 2015-02-20 Pedro Alves <palves@redhat.com> PR threads/18006 * linux-thread-db.c (thread_get_info_callback): Return early if the thread's lwp id is -1. gdb/testsuite/ChangeLog: 2015-02-20 Pedro Alves <palves@redhat.com> PR threads/18006 * gdb.threads/clone-thread_db.c: New file. * gdb.threads/clone-thread_db.exp: New file.
2015-02-20 20:00:21 +01:00
2015-02-20 Pedro Alves <palves@redhat.com>
PR threads/18006
* gdb.threads/clone-thread_db.c: New file.
* gdb.threads/clone-thread_db.exp: New file.
Fix non executable stack handling when calling functions in the inferior. When gdb creates a dummy frame to execute a function in the inferior, the process may generate a SIGSEGV, SIGTRAP or SIGILL because the stack is non executable. If the signal handler set in gdb has option print or stop enabled for these signals gdb handles this correctly. However, in the case of noprint and nostop the signal is short-circuited and the inferior process is sent the signal directly. This causes the inferior to crash because of gdb. This patch adds a check for SIGSEGV, SIGTRAP or SIGILL so that these signals are sent to gdb rather than short-circuited in the inferior. gdb then handles them properly and the inferior process does not crash. This patch also fixes the same behavior in gdbserver. Also added a small testcase to test the issue called catch-gdb-caused-signals. This applies to Linux only, tested on Linux. gdb/ChangeLog: PR breakpoints/16812 * linux-nat.c (linux_nat_filter_event): Report SIGTRAP,SIGILL,SIGSEGV. * nat/linux-ptrace.c (linux_wstatus_maybe_breakpoint): Add. * nat/linux-ptrace.h: Add linux_wstatus_maybe_breakpoint. gdb/gdbserver/ChangeLog: PR breakpoints/16812 * linux-low.c (wstatus_maybe_breakpoint): Remove. (linux_low_filter_event): Update wstatus_maybe_breakpoint name. (linux_wait_1): Report SIGTRAP,SIGILL,SIGSEGV. gdb/testsuite/ChangeLog: PR breakpoints/16812 * gdb.base/catch-gdb-caused-signals.c: New file. * gdb.base/catch-gdb-caused-signals.exp: New file.
2015-02-12 20:55:08 +01:00
2015-02-19 Antoine Tremblay <antoine.tremblay@ericsson.com>
PR breakpoints/16812
* gdb.base/catch-gdb-caused-signals.c: New file.
* gdb.base/catch-gdb-caused-signals.exp: New file.
Factorize target program transformations in the GDB_AC_TRANSFORM macro. This patch introduces a new M4 macro GDB_AC_TRANSFORM to avoid repeating the common idiom which is the transformation of target program names, i.e. from gdb to sparc64-linux-gnu-gdb. It also makes gdb/configure.ac and gdb/testsuite/configure.ac to use the new macro. gdb/ChangeLog: 2015-02-18 Jose E. Marchesi <jose.marchesi@oracle.com> * configure: Regenerated. * configure.ac: Use GDB_AC_TRANSFORM. * Makefile.in (aclocal_m4_deps): Added transform.m4. * acinclude.m4: sinclude transform.m4. * transform.m4: New file. (GDB_AC_TRANSFORM): New macro. gdb/testsuite/ChangeLog: 2015-02-18 Jose E. Marchesi <jose.marchesi@oracle.com> * configure: Regenerated. * configure.ac: Use GDB_AC_TRANSFORM. * aclocal.m4: sinclude ../transform.m4.
2015-02-18 13:52:53 +01:00
2015-02-18 Jose E. Marchesi <jose.marchesi@oracle.com>
* configure: Regenerated.
* configure.ac: Use GDB_AC_TRANSFORM.
* aclocal.m4: sinclude ../transform.m4.
Simple testsuite for DTrace USDT probes. This patch adds some simple tests testing the support for DTrace USDT probes. The testsuite will be skipped as unsupported in case the user does not have DTrace installed on her system. The tests included in the test suite test breakpointing on DTrace probes, enabling and disabling probes, printing of probe arguments of several types and also breakpointing on several probes with the same name. gdb/ChangeLog: 2015-02-17 Jose E. Marchesi <jose.marchesi@oracle.com> * lib/dtrace.exp: New file. * gdb.base/dtrace-probe.exp: Likewise. * gdb.base/dtrace-probe.d: Likewise. * gdb.base/dtrace-probe.c: Likewise. * lib/pdtrace.in: Likewise. * configure.ac: Output variables with the transformed names of the strip, readelf, as and nm tools. AC_SUBST lib/pdtrace.in. * configure: Regenerated.
2015-02-17 16:41:16 +01:00
2015-02-17 Jose E. Marchesi <jose.marchesi@oracle.com>
* lib/dtrace.exp: New file.
* gdb.base/dtrace-probe.exp: Likewise.
* gdb.base/dtrace-probe.d: Likewise.
* gdb.base/dtrace-probe.c: Likewise.
* lib/pdtrace.in: Likewise.
* configure.ac: Output variables with the transformed names of
the strip, readelf, as and nm tools. AC_SUBST lib/pdtrace.in.
* configure: Regenerated.
Move `compute_probe_arg' and `compile_probe_arg' to probe.c This patch moves the `compute_probe_arg' and `compile_probe_arg' functions from stap-probe.c to probe.c. The rationale is that it is reasonable to assume that all backends will provide the `$_probe_argN' convenience variables, and that the user must be placed on the PC of the probe when requesting that information. The value and type of the argument can still be determined by the probe backend via the `pops->evaluate_probe_argument' and `pops->compile_to_ax' handlers. Note that a test in gdb.base/stap-probe.exp had to be adjusted because the "No SystemTap probe at PC" messages are now "No probe at PC". gdb/ChangeLog: 2015-02-17 Jose E. Marchesi <jose.marchesi@oracle.com> * probe.c (compute_probe_arg): Moved from stap-probe.c (compile_probe_arg): Likewise. (probe_funcs): Likewise. * stap-probe.c (compute_probe_arg): Moved to probe.c. (compile_probe_arg): Likewise. (probe_funcs): Likewise. gdb/testsuite/ChangeLog: 2015-02-17 Jose E. Marchesi <jose.marchesi@oracle.com> * gdb.base/stap-probe.exp (stap_test): Remove "SystemTap" from expected message when trying to access $_probe_* convenience variables while not on a probe.
2015-02-17 15:50:19 +01:00
2015-02-17 Jose E. Marchesi <jose.marchesi@oracle.com>
* gdb.base/stap-probe.exp (stap_test): Remove "SystemTap" from
expected message when trying to access $_probe_* convenience
variables while not on a probe.
framefilter quit: New test It definitely does not test all the RETURN_MASK_ERROR cases. But it tests at least two of them. gdb/testsuite/ChangeLog 2015-02-11 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.python/py-framefilter.exp (pagination quit - *): New tests.
2015-02-11 14:53:14 +01:00
2015-02-11 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.python/py-framefilter.exp (pagination quit - *): New tests.
Fix adjust_pc_after_break, remove still current thread check On decr_pc_after_break targets, GDB adjusts the PC incorrectly if a background single-step stops somewhere where PC-$decr_pc has a breakpoint, and the thread that finishes the step is not the current thread, like: ADDR1 nop <-- breakpoint here ADDR2 jmp PC IOW, say thread A is stepping ADDR2's line in the background (an infinite loop), and the user switches focus to thread B. GDB's adjust_pc_after_break logic confuses the single-step stop of thread A for a hit of the breakpoint at ADDR1, and thus adjusts thread A's PC to point at ADDR1 when it should not, and reports a breakpoint hit, when thread A did not execute the instruction at ADDR1 at all. The test added by this patch exercises exactly that. I can't find any reason we'd need the "thread to be examined is still the current thread" condition in adjust_pc_after_break, at least nowadays; it might have made sense in the past. Best just remove it, and rely on currently_stepping(). Here's the test's log of a run with an unpatched GDB: 35 while (1); (gdb) PASS: gdb.threads/step-bg-decr-pc-switch-thread.exp: next over nop next& (gdb) PASS: gdb.threads/step-bg-decr-pc-switch-thread.exp: next& over inf loop thread 1 [Switching to thread 1 (Thread 0x7ffff7fc2740 (LWP 29027))](running) (gdb) PASS: gdb.threads/step-bg-decr-pc-switch-thread.exp: switch to main thread Breakpoint 2, thread_function (arg=0x0) at ...src/gdb/testsuite/gdb.threads/step-bg-decr-pc-switch-thread.c:34 34 NOP; /* set breakpoint here */ FAIL: gdb.threads/step-bg-decr-pc-switch-thread.exp: no output while stepping gdb/ChangeLog: 2015-02-11 Pedro Alves <pedro@codesourcery.com> * infrun.c (adjust_pc_after_break): Don't adjust the PC just because the event thread is not the current thread. gdb/testsuite/ChangeLog: 2015-02-11 Pedro Alves <pedro@codesourcery.com> * gdb.threads/step-bg-decr-pc-switch-thread.c: New file. * gdb.threads/step-bg-decr-pc-switch-thread.exp: New file.
2015-02-11 10:45:41 +01:00
2015-02-11 Pedro Alves <pedro@codesourcery.com>
* gdb.threads/step-bg-decr-pc-switch-thread.c: New file.
* gdb.threads/step-bg-decr-pc-switch-thread.exp: New file.
lib/gdb.exp (gdb_load): Always return a result. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_load): Always return a result.
2015-02-11 07:07:06 +01:00
2015-02-10 Doug Evans <xdje42@gmail.com>
* lib/gdb.exp (gdb_load): Always return a result.
Add "signal SIGTRAP" test Some local changes I was working on related to SIGTRAP handling resulted in "signal SIGTRAP" no longer passing the SIGTRAP to the inferior. Surprisingly, only annota1.exp catches this. This commit adds a test that doesn't rely on annotations, so that at the point annotations are finaly dropped, we still have this use case covered ... This is a multi-threaded test to also exercise the case of first needing to do a step-over before delivering the signal. Tested on x86_64 Fedora 20, native, remote/extended-remote gdbserver. gdb/testsuite/ 2015-02-10 Pedro Alves <palves@redhat.com> * gdb.threads/signal-sigtrap.c: New file. * gdb.threads/signal-sigtrap.exp: New file.
2015-01-26 18:52:28 +01:00
2015-02-10 Pedro Alves <palves@redhat.com>
* gdb.threads/signal-sigtrap.c: New file.
* gdb.threads/signal-sigtrap.exp: New file.
gdbserver: Fix crash when QTinit is handled with no inferior process attached When gdbserver is called with --multi and attach has not been called yet and tstart is called on the gdb client, gdbserver would crash. This patch fixes gdbserver so that it returns E01 to the gdb client. Also this patch adds a testcase to verify this bug named no-attach-trace.exp gdb/gdbserver/ChangeLog: PR breakpoints/15956 * tracepoint.c (cmd_qtinit): Add check for current_thread. gdb/testsuite/ChangeLog: * gdb.trace/no-attach-trace.c: New file. * gdb.trace/no-attach-trace.exp: New file.
2015-01-26 19:08:53 +01:00
2015-02-10 Antoine Tremblay <antoine.tremblay@ericsson.com>
* gdb.trace/no-attach-trace.c: New file.
* gdb.trace/no-attach-trace.exp: New file.
GCC5/DWARFv5 Handle DW_TAG_atomic_type for C11 _Atomic type qualifier. gdb/ChangeLog * c-typeprint.c (cp_type_print_method_args): Handle '_Atomic'. (c_type_print_modifier): Likewise. * dwarf2read.c (read_tag_atomic_type): New function. (read_type_die_1): Handle DW_TAG_atomic_type. * gdbtypes.c (make_atomic_type): New function. (recursive_dump_type): Handle TYPE_ATOMIC. * gdbtypes.h (enum type_flag_values): Renumber. (enum type_instance_flag_value): Add TYPE_INSTANCE_FLAG_ATOMIC. (TYPE_ATOMIC): New macro. (make_atomic_type): Declare. gdb/testsuite/ChangeLog * gdb.dwarf2/atomic.c: New file. * gdb.dwarf2/atomic-type.exp: Likewise. include/ChangeLog * dwarf2.def: Add DW_TAG_atomic_type.
2015-02-09 14:58:25 +01:00
2015-02-09 Mark Wielaard <mjw@redhat.com>
* gdb.dwarf2/atomic.c: New file.
* gdb.dwarf2/atomic-type.exp: Likewise.
record-btrace: indicate gaps Indicate gaps in the trace due to decode errors. Internally, a gap is represented as a btrace function segment without instructions and with a non-zero format-specific error code. Show the gap when traversing the instruction or function call history. Also indicate gaps in "info record". It looks like this: (gdb) info record Active record target: record-btrace Recording format: Branch Trace Store. Buffer size: 64KB. Recorded 32 instructions in 5 functions (1 gaps) for thread 1 (process 7182). (gdb) record function-call-history /cli 1 fib inst 1,9 at src/fib.c:9,14 2 fib inst 10,20 at src/fib.c:6,14 3 [decode error (1): instruction overflow] 4 fib inst 21,28 at src/fib.c:11,14 5 fib inst 29,33 at src/fib.c:6,9 (gdb) record instruction-history 20,22 20 0x000000000040062f <fib+47>: sub $0x1,%rax [decode error (1): instruction overflow] 21 0x0000000000400613 <fib+19>: add $0x1,%rax 22 0x0000000000400617 <fib+23>: mov %rax,0x200a3a(%rip) (gdb) Gaps are ignored during reverse execution and replay. 2015-02-09 Markus Metzger <markus.t.metzger@intel.com> * btrace.c (ftrace_find_call): Skip gaps. (ftrace_new_function): Initialize level. (ftrace_new_call, ftrace_new_tailcall, ftrace_new_return) (ftrace_new_switch): Update level computation. (ftrace_new_gap): New. (ftrace_update_function): Create new function after gap. (btrace_compute_ftrace_bts): Create gap on error. (btrace_stitch_bts): Update parameters. Clear trace if it becomes empty. (btrace_stitch_trace): Update parameters. Update callers. (btrace_clear): Reset the number of gaps. (btrace_insn_get): Return NULL if the iterator points to a gap. (btrace_insn_number): Return zero if the iterator points to a gap. (btrace_insn_end): Allow gaps at the end. (btrace_insn_next, btrace_insn_prev, btrace_insn_cmp): Handle gaps. (btrace_find_insn_by_number): Assert that the found iterator does not point to a gap. (btrace_call_next, btrace_call_prev): Assert that the last function is not a gap. * btrace.h (btrace_bts_error): New. (btrace_function): Update comment. (btrace_function) <insn, insn_offset, number>: Update comment. (btrace_function) <errcode>: New. (btrace_thread_info) <ngaps>: New. (btrace_thread_info) <replay>: Update comment. (btrace_insn_get): Update comment. * record-btrace.c (btrace_ui_out_decode_error): New. (record_btrace_info): Print number of gaps. (btrace_insn_history, btrace_call_history): Call btrace_ui_out_decode_error for gaps. (record_btrace_step_thread, record_btrace_start_replaying): Skip gaps. testsuite/ * gdb.btrace/buffer-size.exp: Update "info record" output. * gdb.btrace/delta.exp: Update "info record" output. * gdb.btrace/enable.exp: Update "info record" output. * gdb.btrace/finish.exp: Update "info record" output. * gdb.btrace/instruction_history.exp: Update "info record" output. * gdb.btrace/next.exp: Update "info record" output. * gdb.btrace/nexti.exp: Update "info record" output. * gdb.btrace/step.exp: Update "info record" output. * gdb.btrace/stepi.exp: Update "info record" output. * gdb.btrace/nohist.exp: Update "info record" output.
2014-01-30 09:51:10 +01:00
2015-02-09 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/buffer-size.exp: Update "info record" output.
* gdb.btrace/delta.exp: Update "info record" output.
* gdb.btrace/enable.exp: Update "info record" output.
* gdb.btrace/finish.exp: Update "info record" output.
* gdb.btrace/instruction_history.exp: Update "info record" output.
* gdb.btrace/next.exp: Update "info record" output.
* gdb.btrace/nexti.exp: Update "info record" output.
* gdb.btrace/step.exp: Update "info record" output.
* gdb.btrace/stepi.exp: Update "info record" output.
* gdb.btrace/nohist.exp: Update "info record" output.
record-btrace: add bts buffer size configuration option Allow the size of the branch trace ring buffer to be defined by the user. The specified buffer size will be used when BTS tracing is enabled for new threads. The obtained buffer size may differ from the requested size. The actual buffer size for the current thread is shown in the "info record" command. Bigger buffers mean longer traces, but also longer processing time. 2015-02-09 Markus Metzger <markus.t.metzger@intel.com> * btrace.c (parse_xml_btrace_conf_bts): Add size. (btrace_conf_bts_attributes): New. (btrace_conf_children): Add attributes. * common/btrace-common.h (btrace_config_bts): New. (btrace_config)<bts>: New. (btrace_config): Update comment. * nat/linux-btrace.c (linux_enable_btrace, linux_enable_bts): Use config. * features/btrace-conf.dtd: Increment version. Add size attribute to bts element. * record-btrace.c (set_record_btrace_bts_cmdlist, show_record_btrace_bts_cmdlist): New. (record_btrace_adjust_size, record_btrace_print_bts_conf, record_btrace_print_conf, cmd_set_record_btrace_bts, cmd_show_record_btrace_bts): New. (record_btrace_info): Call record_btrace_print_conf. (_initialize_record_btrace): Add commands. * remote.c: Add PACKET_Qbtrace_conf_bts_size enum. (remote_protocol_features): Add Qbtrace-conf:bts:size packet. (btrace_sync_conf): Synchronize bts size. (_initialize_remote): Add Qbtrace-conf:bts:size packet. * NEWS: Announce new commands and new packets. doc/ * gdb.texinfo (Branch Trace Configuration Format): Add size. (Process Record and Replay): Describe new set|show commands. (General Query Packets): Describe Qbtrace-conf:bts:size packet. testsuite/ * gdb.btrace/buffer-size: New. gdbserver/ * linux-low.c (linux_low_btrace_conf): Print size. * server.c (handle_btrace_conf_general_set): New. (hanle_general_set): Call handle_btrace_conf_general_set. (handle_query): Report Qbtrace-conf:bts:size as supported.
2013-11-28 16:39:12 +01:00
2015-02-09 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/buffer-size: New.
record btrace: add configuration struct Add a struct to describe the branch trace configuration and use it for enabling branch tracing. The user will be able to set configuration fields for each tracing format to be used for new threads. The actual configuration that is active for a given thread will be shown in the "info record" command. At the moment, the configuration struct only contains a format field that is set to the only available format. The format is the only configuration option that can not be set via set commands. It is given as argument to the "record btrace" command when starting recording. 2015-02-09 Markus Metzger <markus.t.metzger@intel.com> * Makefile.in (XMLFILES): Add btrace-conf.dtd. * x86-linux-nat.c (x86_linux_enable_btrace): Update parameters. (x86_linux_btrace_conf): New. (x86_linux_create_target): Initialize to_btrace_conf. * nat/linux-btrace.c (linux_enable_btrace): Update parameters. Check format. Split into this and ... (linux_enable_bts): ... this. (linux_btrace_conf): New. (perf_event_skip_record): Renamed into ... (perf_event_skip_bts_record): ... this. Updated users. (linux_disable_btrace): Split into this and ... (linux_disable_bts): ... this. (linux_read_btrace): Check format. * nat/linux-btrace.h (linux_enable_btrace): Update parameters. (linux_btrace_conf): New. (btrace_target_info)<ptid>: Moved. (btrace_target_info)<conf>: New. (btrace_target_info): Split into this and ... (btrace_tinfo_bts): ... this. Updated users. * btrace.c (btrace_enable): Update parameters. (btrace_conf, parse_xml_btrace_conf_bts, parse_xml_btrace_conf) (btrace_conf_children, btrace_conf_attributes) (btrace_conf_elements): New. * btrace.h (btrace_enable): Update parameters. (btrace_conf, parse_xml_btrace_conf): New. * common/btrace-common.h (btrace_config): New. * feature/btrace-conf.dtd: New. * record-btrace.c (record_btrace_conf): New. (record_btrace_cmdlist): New. (record_btrace_enable_warn, record_btrace_open): Pass &record_btrace_conf. (record_btrace_info): Print recording format. (cmd_record_btrace_bts_start): New. (cmd_record_btrace_start): Call cmd_record_btrace_bts_start. (_initialize_record_btrace): Add "record btrace bts" subcommand. Add "record bts" alias command. * remote.c (remote_state)<btrace_config>: New. (remote_btrace_reset, PACKET_qXfer_btrace_conf): New. (remote_protocol_features): Add qXfer:btrace-conf:read. (remote_open_1): Call remote_btrace_reset. (remote_xfer_partial): Handle TARGET_OBJECT_BTRACE_CONF. (btrace_target_info)<conf>: New. (btrace_sync_conf, btrace_read_config): New. (remote_enable_btrace): Update parameters. Call btrace_sync_conf and btrace_read_conf. (remote_btrace_conf): New. (init_remote_ops): Initialize to_btrace_conf. (_initialize_remote): Add qXfer:btrace-conf packet. * target.c (target_enable_btrace): Update parameters. (target_btrace_conf): New. * target.h (target_enable_btrace): Update parameters. (target_btrace_conf): New. (target_object)<TARGET_OBJECT_BTRACE_CONF>: New. (target_ops)<to_enable_btrace>: Update parameters and comment. (target_ops)<to_btrace_conf>: New. * target-delegates: Regenerate. * target-debug.h (target_debug_print_const_struct_btrace_config_p) (target_debug_print_const_struct_btrace_target_info_p): New. NEWS: Announce new command and new packet. doc/ * gdb.texinfo (Process Record and Replay): Describe the "record btrace bts" command. (General Query Packets): Describe qXfer:btrace-conf:read packet. (Branch Trace Configuration Format): New. gdbserver/ * linux-low.c (linux_low_enable_btrace): Update parameters. (linux_low_btrace_conf): New. (linux_target_ops)<to_btrace_conf>: Initialize. * server.c (current_btrace_conf): New. (handle_btrace_enable): Rename to ... (handle_btrace_enable_bts): ... this. Pass &current_btrace_conf to target_enable_btrace. Update comment. Update users. (handle_qxfer_btrace_conf): New. (qxfer_packets): Add btrace-conf entry. (handle_query): Report qXfer:btrace-conf:read as supported packet. * target.h (target_ops)<enable_btrace>: Update parameters and comment. (target_ops)<read_btrace_conf>: New. (target_enable_btrace): Update parameters. (target_read_btrace_conf): New. testsuite/ * gdb.btrace/delta.exp: Update "info record" output. * gdb.btrace/enable.exp: Update "info record" output. * gdb.btrace/finish.exp: Update "info record" output. * gdb.btrace/instruction_history.exp: Update "info record" output. * gdb.btrace/next.exp: Update "info record" output. * gdb.btrace/nexti.exp: Update "info record" output. * gdb.btrace/step.exp: Update "info record" output. * gdb.btrace/stepi.exp: Update "info record" output. * gdb.btrace/nohist.exp: Update "info record" output.
2013-11-28 15:44:13 +01:00
2015-02-09 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/delta.exp: Update "info record" output.
* gdb.btrace/enable.exp: Update "info record" output.
* gdb.btrace/finish.exp: Update "info record" output.
* gdb.btrace/instruction_history.exp: Update "info record" output.
* gdb.btrace/next.exp: Update "info record" output.
* gdb.btrace/nexti.exp: Update "info record" output.
* gdb.btrace/step.exp: Update "info record" output.
* gdb.btrace/stepi.exp: Update "info record" output.
* gdb.btrace/nohist.exp: Update "info record" output.
"enable count" user input error handling (PR gdb/15678) Typing "enable count" by itself crashes GDB. Also, if you omit the breakpoint number/range, the error message is not very clear: (gdb) enable count 2 warning: bad breakpoint number at or near '' (gdb) enable count Segmentation fault (core dumped) With this patch, the error messages are slightly more helpful: (gdb) enable count 2 Argument required (one or more breakpoint numbers). (gdb) enable count Argument required (hit count). gdb/ChangeLog: PR gdb/15678 * breakpoint.c (map_breakpoint_numbers): Check for empty args string. (enable_count_command): Check args for NULL value. gdb/testsuite/ChangeLog: PR gdb/15678 * gdb.base/ena-dis-br.exp: Test "enable count" for bad user input.
2015-02-02 20:57:31 +01:00
2015-02-06 Simon Marchi <simon.marchi@ericsson.com>
PR gdb/15678
* gdb.base/ena-dis-br.exp: Test "enable count" for bad user input.
Improve gdb.threads/attach-many-short-lived-threads.exp timeout handling The buildbot shows that this test is still racy, and occasionally fails with time outs on some machines. I'd like to get major issues with load out of the way. The test currently exits after 180s, which is just a random number, that has no relation to what the .exp file considers a time out. This commit makes the program wait a bit longer than what the .exp file considers a time out, and, resets the timer for each iteration. Tested on x86_64 Fedora 20, native and extended-remote gdbserver. gdb/testsuite/ 2015-02-06 Pedro Alves <palves@redhat.com> * gdb.threads/attach-many-short-lived-threads.c (SECONDS): New macro. (seconds_left, again): New globals. (main): Wait seconds_left in a 1-second sleep loop instead of sleeping 180 seconds. If 'again' is set, reset the seconds counter. * gdb.threads/attach-many-short-lived-threads.exp (test): Set 'again' in the inferior before detaching. Print the seconds left. (options): New global. (top level): Build program with -DTIMEOUT=$timeout.
2015-02-06 13:24:32 +01:00
2015-02-06 Pedro Alves <palves@redhat.com>
* gdb.threads/attach-many-short-lived-threads.c (SECONDS): New
macro.
(seconds_left, again): New globals.
(main): Wait seconds_left in a 1-second sleep loop instead of
sleeping 180 seconds. If 'again' is set, reset the seconds
counter.
* gdb.threads/attach-many-short-lived-threads.exp (test): Set
'again' in the inferior before detaching. Print the seconds left.
(options): New global.
(top level): Build program with -DTIMEOUT=$timeout.
gdb.base/gdb-sigterm.exp: Fix spurious FAILs The buildbot shows that some machines FAIL this test frequently. E.g.: https://sourceware.org/ml/gdb-testers/2015-q1/msg00997.html If I stress my machine, I can sometimes see it fail too. Bumping the 200 limit and tweaking the test to show the step count, I get: ... PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 12 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 8 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 13 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 7 times --> FAIL: gdb.base/gdb-sigterm.exp: SIGTERM stepped 228 times <-- PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 11 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 13 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 12 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 8 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 9 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 7 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 11 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 8 times ... Thinking that this might be a problem of SIGTERM reaching GDB, but then the event loop taking too long to handle it, I hacked GDB to print a debug log whenever the SIGTERM handler was called, and, whenever the event loop finally calls the async SIGTERM handler. Here's what I see: infrun: 30011 [Thread 30011], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x4005de --> infrun: got SIGTERM <-- infrun: stepping inside range [0x4005de-0x4005e0] infrun: resume (step=1, signal=GDB_SIGNAL_0), ... infrun: prepare_to_wait --> infrun: handling async SIGTERM <-- Cannot execute this command while the target is running. Use the "interrupt" command to stop the target and then try again. gdb.base/gdb-sigterm.exp: expect eof #27 FAIL: gdb.base/gdb-sigterm.exp: SIGTERM stepped 228 times So, no delay on the GDB side. It just happens that occasionally it takes more than 200 single-steps before SIGTERM even reaches GDB. This just looks like a kernel/scheduling issue --- some extra usage spike in the system (e.g., an I/O spike) might cause it for me. For the build slaves, I'm guessing they're frequently busy enough to trip on this often. Particularly more so now that we're having them run tests in parallel mode. The fix is to detect failure by timeout instead of counting single steps. This should be more reliable. Indeed for me, after this commit, I couldn't trigger a FAIL anymore, even after letting the test run for an hour. By timeout is also nicer in that a board file for a slow host/target can increase it (like, e.g., an embedded GNU/Linux board). Tested on x86_64 Fedora 20, native, gdbserver, and extended-remote gdbserver. gdb/testsuite/ 2015-02-06 Pedro Alves <palves@redhat.com> * gdb.base/gdb-sigterm.c (main): Use the TIMEOUT define to determine how many seconds to pass to 'alarm'. * gdb.base/gdb-sigterm.exp (top level): Build program with -DTIMEOUT=$timeout. (do_test): Return success/failure indication. Add more verbose logging. Don't fail if 200 single steps are seen. Instead, fail when the test times out. (passes): New global. (top level): Break the testing loop if testing fails on any iteration. Use gdb_assert.
2015-02-06 11:09:42 +01:00
2015-02-06 Pedro Alves <palves@redhat.com>
* gdb.base/gdb-sigterm.c (main): Use the TIMEOUT define to
determine how many seconds to pass to 'alarm'.
* gdb.base/gdb-sigterm.exp (top level): Build program with
-DTIMEOUT=$timeout.
(do_test): Return success/failure indication. Add more verbose
logging. Don't fail if 200 single steps are seen. Instead, fail
when the test times out.
(passes): New global.
(top level): Break the testing loop if testing fails on any
iteration. Use gdb_assert.
Clean up System V IPC objects allocated by test. This commit modifies the test program gdb.base/info-os.c so that it cleans up all allocated System V IPC objects when a fatal error occurs. Without this, it was possible for the program to leave IPC objects on the system, and such objects persist until they are manually deleted or the system reboots. I looked at changing the SysV IPC key for allocating the IPC objects to IPC_PRIVATE. That would prevent errors due to namespace conflicts with the key. However, the test needs to read the actual key number from the 'info os' command output, and IPC_PRIVATE won't work for that. gdb/testsuite/ChangeLog: 2015-02-04 Don Breazeal <donb@codesourcery.com> * gdb.base/info-os.c (shmid, semid, msqid): Make variables static and initialize them. (ipc_cleanup): New function. (main): Don't declare shmid, semid, and msqid. Add a call to atexit so that we call ipc_cleanup on exit.
2015-02-04 22:15:06 +01:00
2015-02-04 Don Breazeal <donb@codesourcery.com>
* gdb.base/info-os.c (shmid, semid, msqid): Make variables static
and initialize them.
(ipc_cleanup): New function.
(main): Don't declare shmid, semid, and msqid. Add a call to
atexit so that we call ipc_cleanup on exit.
Fix '--target_board=native-extended-gdbserver/-m32' Running the testsuite with the native-extended-gdbserver.exp board and passing a variant spec, like make check RUNTESTFLAGS="--target_board=native-extended-gdbserver/-m32" results in dejagnu trying to open a rsh connection to "native-extended-gdbserver", which of course is wrong. The point of this board is running things locally. The issue is that the native-extended-gdbserver board does not clear the "isremote" flag properly. Reported by Sergio at: https://sourceware.org/ml/gdb-patches/2015-02/msg00067.html testsuite/ 2015-02-04 Pedro Alves <palves@redhat.com> * boards/native-extended-gdbserver.exp: Remove any target variant specifications from the board name before clearing the isremote flag from board_info.
2015-02-04 14:53:24 +01:00
2015-02-04 Pedro Alves <palves@redhat.com>
* boards/native-extended-gdbserver.exp: Remove any target variant
specifications from the board name before clearing the isremote
flag from board_info.
Move vptr_{fieldno,basetype} out of main_type, and update everything accordingly. Every type has to pay the price in memory usage for their presence. The proper place for them is in the type_specific field which exists for this purpose. gdb/ChangeLog: * dwarf2read.c (process_structure_scope): Update setting of TYPE_VPTR_BASETYPE, TYPE_VPTR_FIELDNO. * gdbtypes.c (internal_type_vptr_fieldno): New function. (set_type_vptr_fieldno): New function. (internal_type_vptr_basetype): New function. (set_type_vptr_basetype): New function. (get_vptr_fieldno): Update setting of TYPE_VPTR_FIELDNO, TYPE_VPTR_BASETYPE. (allocate_cplus_struct_type): Initialize vptr_fieldno. (recursive_dump_type): Printing of vptr_fieldno, vptr_basetype ... (print_cplus_stuff): ... moved here. (copy_type_recursive): Don't copy TYPE_VPTR_BASETYPE. * gdbtypes.h (struct main_type): Members vptr_fieldno, vptr_basetype moved to ... (struct cplus_struct_type): ... here. All uses updated. (TYPE_VPTR_FIELDNO, TYPE_VPTR_BASETYPE): Rewrite. (internal_type_vptr_fieldno, set_type_vptr_fieldno): Declare. (internal_type_vptr_basetype, set_type_vptr_basetype): Declare. * stabsread.c (read_tilde_fields): Update setting of TYPE_VPTR_FIELDNO, TYPE_VPTR_BASETYPE. gdb/testsuite/ChangeLog: * gdb.base/maint.exp <maint print type argc>: Update expected output.
2015-02-01 06:40:57 +01:00
2015-01-31 Doug Evans <xdje42@gmail.com>
* gdb.base/maint.exp <maint print type argc>: Update expected output.
ChangeLog entries for max-completions patch. gdb/ChangeLog: PR cli/9007 PR cli/11920 PR cli/15548 * cli/cli-cmds.c (complete_command): Notify user if max-completions reached. * common/common-exceptions.h (enum errors) <MAX_COMPLETIONS_REACHED_ERROR>: New value. * completer.h (get_max_completions_reached_message): New declaration. (max_completions): Likewise. (completion_tracker_t): New typedef. (new_completion_tracker): New declaration. (make_cleanup_free_completion_tracker): Likewise. (maybe_add_completion_enum): New enum. (maybe_add_completion): New declaration. (throw_max_completions_reached_error): Likewise. * completer.c (max_completions): New global variable. (new_completion_tracker): New function. (free_completion_tracker): Likewise. (make_cleanup_free_completion_tracker): Likewise. (maybe_add_completions): Likewise. (throw_max_completions_reached_error): Likewise. (complete_line): Remove duplicates and limit result to max_completions entries. (get_max_completions_reached_message): New function. (gdb_display_match_list): Handle max_completions. (_initialize_completer): New declaration and function. * symtab.c: Include completer.h. (completion_tracker): New static variable. (completion_list_add_name): Call maybe_add_completion. (default_make_symbol_completion_list_break_on_1): Renamed from default_make_symbol_completion_list_break_on. Maintain completion_tracker across calls to completion_list_add_name. (default_make_symbol_completion_list_break_on): New function. * top.c (init_main): Set rl_completion_display_matches_hook. * tui/tui-io.c: Include completer.h. (tui_old_rl_display_matches_hook): New static global. (tui_rl_display_match_list): Notify user if max-completions reached. (tui_setup_io): Save/restore rl_completion_display_matches_hook. * NEWS (New Options): Mention set/show max-completions. gdb/doc/ChangeLog: * gdb.texinfo (Command Completion): Document new "set/show max-completions" option. gdb/testsuite/ChangeLog: * gdb.base/completion.exp: Disable completion limiting for existing tests. Add new tests to check completion limiting. * gdb.linespec/ls-errs.exp: Disable completion limiting.
2015-02-01 00:24:26 +01:00
2015-01-31 Gary Benson <gbenson@redhat.com>
* gdb.base/completion.exp: Disable completion limiting for
existing tests. Add new tests to check completion limiting.
* gdb.linespec/ls-errs.exp: Disable completion limiting.
gdb.ada/dyn_arrayidx.exp: Add additional_flags=-gnat12. gdb/testsuite/ChangeLog: * gdb.ada/dyn_arrayidx.exp: Add additional_flags=-gnat12.
2015-01-31 23:26:54 +01:00
2015-01-31 Doug Evans <xdje42@gmail.com>
* gdb.ada/dyn_arrayidx.exp: Add additional_flags=-gnat12.
Add support for inlining scripts into .debug_gdb_scripts. include/gdb/ChangeLog: * section-scripts.h: Remove "future extension" comment. (SECTION_SCRIPT_ID_PYTHON_TEXT): New macro. (SECTION_SCRIPT_ID_SCHEME_TEXT): New macro. gdb/ChangeLog: * NEWS: Mention inlined scripts in .debug_gdb_scripts section. * auto-load.c: #include ctype.h. (struct auto_load_pspace_info): Replace member loaded_scripts with new members loaded_script_files, loaded_script_texts. (auto_load_pspace_data_cleanup): Update. (init_loaded_scripts_info): Update. (get_auto_load_pspace_data_for_loading): Update. (maybe_add_script_file): Renamed from maybe_add_script. All callers updated. (maybe_add_script_text): New function. (clear_section_scripts): Update. (source_script_file, execute_script_contents): New functions. (source_section_scripts): Add support for SECTION_SCRIPT_ID_PYTHON_TEXT, SECTION_SCRIPT_ID_GUILE_TEXT. (print_scripts): New function. (auto_load_info_scripts): Also print inlined scripts. (maybe_print_unsupported_script_warning): Renamed from unsupported_script_warning_print. All callers updated. (maybe_print_script_not_found_warning): Renamed from script_not_found_warning_print. All callers updated. * extension-priv.h (struct extension_language_script_ops): New member objfile_script_executor. * extension.c (ext_lang_objfile_script_executor): New function. * extension.h (objfile_script_executor_func): New typedef. (ext_lang_objfile_script_executor): Declare. * guile/guile-internal.h (gdbscm_execute_objfile_script): Declare. * guile/guile.c (guile_extension_script_ops): Update. * guile/scm-objfile.c (gdbscm_execute_objfile_script): New function. * python/python.c (python_extension_script_ops): Update. (gdbpy_execute_objfile_script): New function. gdb/doc/ChangeLog: * gdb.texinfo (dotdebug_gdb_scripts section): Update docs to distinguish script files vs inlined scripts. * python.texi (Python Auto-loading): Ditto. gdb/testsuite/ChangeLog: * gdb.guile/scm-section-script.c: Add duplicate inlined section script entries. Duplicate file section script entries. * gdb.guile/scm-section-script.exp: Add tests for duplicate entries, inlined entries. Add test for safe-path rejection. * gdb.python/py-section-script.c: Add duplicate inlined section script entries. Duplicate file section script entries. * gdb.python/py-section-script.exp: Add tests for duplicate entries, inlined entries. Add test for safe-path rejection.
2015-01-31 21:01:13 +01:00
2015-01-31 Doug Evans <xdje42@gmail.com>
* gdb.guile/scm-section-script.c: Add duplicate inlined section script
entries. Duplicate file section script entries.
* gdb.guile/scm-section-script.exp: Add tests for duplicate entries,
inlined entries. Add test for safe-path rejection.
* gdb.python/py-section-script.c: Add duplicate inlined section script
entries. Duplicate file section script entries.
* gdb.python/py-section-script.exp: Add tests for duplicate entries,
inlined entries. Add test for safe-path rejection.
gdb/DWARF: Support for arrays whose bound is a discriminant. Consider the following declarations: type Array_Type is array (Integer range <>) of Integer; type Record_Type (N : Integer) is record A : Array_Type (1 .. N); end record; R : Record_Type := Get (10); It defines what Ada programers call a "discriminated record", where "N" is a component of that record called a "discriminant", and where "A" is a component defined as an array type whose upper bound is equal to the value of the discriminant. So far, we rely on a number of fairly complex GNAT-specific encodings to handle this situation. This patch is to enhance GDB to be able to print this record in the case where the compiler has been modified to replace those encodings by pure DWARF constructs. In particular, the debugging information generated for the record above looks like the following. "R" is a record.. .uleb128 0x10 # (DIE (0x13e) DW_TAG_structure_type) .long .LASF17 # DW_AT_name: "foo__record_type" ... whose is is of course dynamic (not our concern here)... .uleb128 0xd # DW_AT_byte_size .byte 0x97 # DW_OP_push_object_address .byte 0x94 # DW_OP_deref_size .byte 0x4 .byte 0x99 # DW_OP_call4 .long 0x19b .byte 0x23 # DW_OP_plus_uconst .uleb128 0x7 .byte 0x9 # DW_OP_const1s .byte 0xfc .byte 0x1a # DW_OP_and .byte 0x1 # DW_AT_decl_file (foo.adb) .byte 0x6 # DW_AT_decl_line ... and then has 2 members, fist "n" (our discriminant); .uleb128 0x11 # (DIE (0x153) DW_TAG_member) .ascii "n\0" # DW_AT_name .byte 0x1 # DW_AT_decl_file (foo.adb) .byte 0x6 # DW_AT_decl_line .long 0x194 # DW_AT_type .byte 0 # DW_AT_data_member_location ... and "A"... .uleb128 0x11 # (DIE (0x181) DW_TAG_member) .ascii "a\0" # DW_AT_name .long 0x15d # DW_AT_type .byte 0x4 # DW_AT_data_member_location ... which is an array ... .uleb128 0x12 # (DIE (0x15d) DW_TAG_array_type) .long .LASF18 # DW_AT_name: "foo__record_type__T4b" .long 0x194 # DW_AT_type ... whose lower bound is implicitly 1, and the upper bound a reference to DIE 0x153 = "N": .uleb128 0x13 # (DIE (0x16a) DW_TAG_subrange_type) .long 0x174 # DW_AT_type .long 0x153 # DW_AT_upper_bound This patch enhanced GDB to understand references to other DIEs where the DIE's address is at an offset of its enclosing type. The difficulty was that the address used to resolve the array's type (R's address + 4 bytes) is different from the address used as the base to compute N's address (an offset to R's address). We're solving this issue by using a stack of addresses rather than a single address when trying to resolve a type. Each address in the stack corresponds to each containing level. For instance, if resolving the field of a struct, the stack should contain the address of the field at the top, and then the address of the struct. That way, if the field makes a reference to an object of the struct, we can retrieve the address of that struct, and properly resolve the dynamic property references that struct. gdb/ChangeLog: * gdbtypes.h (struct dynamic_prop): New PROP_ADDR_OFFSET enum kind. * gdbtypes.c (resolve_dynamic_type_internal): Replace "addr" parameter by "addr_stack" parameter. (resolve_dynamic_range): Replace "addr" parameter by "stack_addr" parameter. Update function documentation. Update code accordingly. (resolve_dynamic_array, resolve_dynamic_union) (resolve_dynamic_struct, resolve_dynamic_type_internal): Likewise. (resolve_dynamic_type): Update code, following the changes made to resolve_dynamic_type_internal's interface. * dwarf2loc.h (struct property_addr_info): New. (dwarf2_evaluate_property): Replace "address" parameter by "addr_stack" parameter. Adjust function documentation. (struct dwarf2_offset_baton): New. (struct dwarf2_property_baton): Update documentation of field "referenced_type" to be more general. New field "offset_info" in union data field. * dwarf2loc.c (dwarf2_evaluate_property): Replace "address" parameter by "addr_stack" parameter. Adjust code accordingly. Add support for PROP_ADDR_OFFSET properties. * dwarf2read.c (attr_to_dynamic_prop): Add support for DW_AT_data_member_location attributes as well. Use case statements instead of if/else condition. gdb/testsuite/ChangeLog: * gdb.ada/disc_arr_bound: New testcase. Tested on x86_64-linux, no regression.
2015-01-05 11:32:36 +01:00
2015-01-29 Joel Brobecker <brobecker@adacore.com>
* gdb.ada/disc_arr_bound: New testcase.
[Ada/varobj] number of children of null pointer to dynamic array. This is preparation work to avoid a regression in the Ada/varobj. An upcoming patch is going to add support for types in DWARF which have dynamic properties whose value is a reference to another DIE. Consider for instance the following declaration: type Variant_Type (N : Int := 0) is record F : String(1 .. N) := (others => 'x'); end record; type Variant_Type_Access is access all Variant_Type; VTA : Variant_Type_Access := null; This declares a variable "VTA" which is an access (=pointer) to a variant record Variant_Type. This record contains two components, the first being "N" (the discriminant), and the second being "F", an array whose lower bound is 1, and whose upper bound depends on the value of "N" (the discriminant). Of interest to us, here, is that second component ("F"), and in particular its bounds. The debugging info, and in particular the info for the array looks like the following... .uleb128 0x9 # (DIE (0x91) DW_TAG_array_type) .long .LASF16 # DW_AT_name: "bar__variant_type__T2b" .long 0xac # DW_AT_GNAT_descriptive_type .long 0x2cb # DW_AT_type .long 0xac # DW_AT_sibling .uleb128 0xa # (DIE (0xa2) DW_TAG_subrange_type) .long 0xc4 # DW_AT_type .long 0x87 # DW_AT_upper_bound .byte 0 # end of children of DIE 0x91 ... where the upper bound of the array's subrange type is a reference to "n"'s DIE (0x87): .uleb128 0x8 # (DIE (0x87) DW_TAG_member) .ascii "n\0" # DW_AT_name [...] Once the patch to handle this dynamic property gets applied, this is what happens when creating a varobj for variable "VTA" (whose value is null), and then trying to list its children: (gdb) -var-create vta * vta ^done,name="vta",numchild="2",value="0x0", type="bar.variant_type_access",has_more="0" (gdb) -var-list-children 1 vta ^done,numchild="2", children=[child={name="vta.n",[...]}, child={name="vta.f",exp="f", numchild="43877616", <<<<----- value="[43877616]", <<<<----- type="array (1 .. n) of character"}], has_more="0" It has an odd number of children. In this case, we cannot really determine the number of children, since that number depends on the value of a field in a record for which we do not have a value. Up to now, the value we've been displaying is zero - meaning we have an empty array. What happens in this case, is that, because the VTA is a null pointer, we're not able to resolve the pointer's target type, and therefore end up asking ada_varobj_get_array_number_of_children to return the number of elements in that array; for that, it relies blindly on get_array_bounds, which assumes the type is no longer dynamic, and therefore the reads the bound without seeing that it's value is actually a reference rather than a resolved constant. This patch prevents the issue by explicitly handling the case of dynamic arrays, and returning zero child in that case. gdb/ChangeLog: * ada-varobj.c (ada_varobj_get_array_number_of_children): Return zero if PARENT_VALUE is NULL and parent_type's range type is dynamic. gdb/testsuite/ChangeLog: * gdb.ada/mi_var_array: New testcase. Tested on x86_64-linux.
2015-01-14 15:39:24 +01:00
2015-01-29 Joel Brobecker <brobecker@adacore.com>
* gdb.ada/mi_var_array: New testcase.
Add gdb.Objfile.username. gdb/ChangeLog: * NEWS: Mention gdb.Objfile.username. * python/py-objfile.c (objfpy_get_username): New function. (objfile_getset): Add "username". gdb/doc/ChangeLog: * python.texi (Objfiles In Python): Document Objfile.username. gdb/testsuite/ChangeLog: * gdb.python/py-objfile.exp: Add tests for objfile.username. Add test for objfile.filename, objfile.username after objfile has been unloaded.
2015-01-27 19:13:52 +01:00
2015-01-27 Doug Evans <dje@google.com>
* gdb.python/py-objfile.exp: Add tests for objfile.username.
Add test for objfile.filename, objfile.username after objfile
has been unloaded.
check gdb.lookup_type return value in gdb.python/py-lookup-type.exp This further improves this testcase to check the output of our calls to gdb.lookup_type. gdb/ChangeLog: * gdb.python/py-lookup-type.exp (test_lookup_type): Change the second test to print the name attribute of value returned by the call to gdb.lookup_type, and adjust the expected output accordingly.
2015-01-21 10:29:09 +01:00
2015-01-26 Joel Brobecker <brobecker@adacore.com>
* gdb.python/py-lookup-type.exp (test_lookup_type): Change
the second test to print the name attribute of value
returned by the call to gdb.lookup_type, and adjust
the expected output accordingly.
Remove testsuite compile errors with GCC5. GCC5 defaults to the GNU11 standard for C and warns by default for implicit function declarations and implicit return types. https://gcc.gnu.org/gcc-5/porting_to.html Fixing these issues in the testsuite turns 9 untested and 17 unsupported testcases into 417 new passes when compiling with GCC5. gdb/testsuite/ChangeLog: * gdb.arch/i386-bp_permanent.c (standard): New declaration. * gdb.base/disp-step-fork.c: Include unistd.h. * gdb.base/siginfo-obj.c: Include stdio.h. * gdb.base/siginfo-thread.c: Likewise. * gdb.mi/non-stop.c: Include unistd.h. * gdb.mi/nsthrexec.c: Include stdio.h. * gdb.mi/pthreads.c: Include unistd.h. * gdb.modula2/unbounded1.c (main): Declare returns int. * gdb.reverse/consecutive-reverse.c: Likewise. * gdb.threads/create-fail.c: Include unistd.h. * gdb.threads/killed.c: Likewise. * gdb.threads/linux-dp.c: Likewise. * gdb.threads/non-ldr-exc-1.c: Include stdio.h and string.h. * gdb.threads/non-ldr-exc-2.c: Likewise. * gdb.threads/non-ldr-exc-3.c: Likewise. * gdb.threads/non-ldr-exc-4.c: Likewise. * gdb.threads/pthreads.c: Include unistd.h. (main): Declare returns int. * gdb.threads/tls-main.c (foo): New declaration. * gdb.threads/watchpoint-fork-mt.c: Define _GNU_SOURCE.
2015-01-25 16:42:05 +01:00
2015-01-25 Mark Wielaard <mjw@redhat.com>
* gdb.arch/i386-bp_permanent.c (standard): New declaration.
* gdb.base/disp-step-fork.c: Include unistd.h.
* gdb.base/siginfo-obj.c: Include stdio.h.
* gdb.base/siginfo-thread.c: Likewise.
* gdb.mi/non-stop.c: Include unistd.h.
* gdb.mi/nsthrexec.c: Include stdio.h.
* gdb.mi/pthreads.c: Include unistd.h.
* gdb.modula2/unbounded1.c (main): Declare returns int.
* gdb.reverse/consecutive-reverse.c: Likewise.
* gdb.threads/create-fail.c: Include unistd.h.
* gdb.threads/killed.c: Likewise.
* gdb.threads/linux-dp.c: Likewise.
* gdb.threads/non-ldr-exc-1.c: Include stdio.h and string.h.
* gdb.threads/non-ldr-exc-2.c: Likewise.
* gdb.threads/non-ldr-exc-3.c: Likewise.
* gdb.threads/non-ldr-exc-4.c: Likewise.
* gdb.threads/pthreads.c: Include unistd.h.
(main): Declare returns int.
* gdb.threads/tls-main.c (foo): New declaration.
* gdb.threads/watchpoint-fork-mt.c: Define _GNU_SOURCE.
Catch exception in value_rtti_indirect_type In the situation described in bug 17416 [1]: * "set print object" is on; * The variable object is a pointer to a struct, and it contains an invalid value (e.g. NULL, or random uninitialized value); * The variable object (struct) has a child which is also a pointer to a struct; * We try to use "-var-list-children". ... an exception thrown in value_ind can propagate too far and leave an half-built variable object, leading to a wrong state. This patch adds a TRY_CATCH to catch it and makes value_rtti_indirect_type return NULL in that case, meaning that the type of the pointed object could not be found. A test for the fix is also added. New in v2: * Added test. * Restructured "catch" code. * Added details about the bug in commit log. gdb/Changelog: * valops.c (value_rtti_indirect_type): Catch exception thrown by value_ind. gdb/testsuite/ChangeLog * gdb.mi/mi-var-list-children-invalid-grandchild.c: New file. * gdb.mi/mi-var-list-children-invalid-grandchild.exp: New file. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=17416
2015-01-23 18:59:24 +01:00
2015-01-23 Simon Marchi <simon.marchi@ericsson.com>
* gdb.mi/mi-var-list-children-invalid-grandchild.c: New file.
* gdb.mi/mi-var-list-children-invalid-grandchild.exp: New file.
Use GCC5/DWARF5 DW_AT_noreturn to mark functions that don't return normally. Add a flag field is_noreturn to struct func_type. Make calling_convention a small bit field to not increase the size of the struct. Set is_noreturn if the new GCC5/DWARF5 DW_AT_noreturn is set on a DW_TAG_subprogram. Use this information to warn the user before doing a finish or return from a function that does not return normally to its caller. (gdb) finish warning: Function endless does not return normally. Try to finish anyway? (y or n) (gdb) return warning: Function does not return normally to caller. Make endless return now? (y or n) gdb/ChangeLog * dwarf2read.c (read_subroutine_type): Set TYPE_NO_RETURN from DW_AT_noreturn. * gdbtypes.h (struct func_type): Add is_noreturn field flag. Make calling_convention an 8 bit bit field. (TYPE_NO_RETURN): New macro. * infcmd.c (finish_command): Query if function does not return normally. * stack.c (return_command): Likewise. gdb/testsuite/ChangeLog * gdb.base/noreturn-return.c: New file. * gdb.base/noreturn-return.exp: New file. * gdb.base/noreturn-finish.c: New file. * gdb.base/noreturn-finish.exp: New file. include/ChangeLog * dwarf2.def (DW_AT_noreturn): New DWARF5 attribute. The dwarf2.h addition and the code to emit the new attribute is already in the gcc tree.
2014-12-09 11:45:41 +01:00
2015-01-15 Mark Wielaard <mjw@redhat.com>
* gdb.base/noreturn-return.c: New file.
* gdb.base/noreturn-return.exp: New file.
* gdb.base/noreturn-finish.c: New file.
* gdb.base/noreturn-finish.exp: New file.
Linux: make target_is_async_p return false when async is off linux_nat_is_async_p currently always returns true, even when the target is _not_ async. That confuses gdb_readline_wrapper/gdb_readline_wrapper_cleanup, which force-disables target-async while the secondary prompt is active. As a result, when gdb_readline_wrapper returns, the target is left async, even through it was sync to begin with. That can result in weird bugs, like the one the test added by this commit exposes. Ref: https://sourceware.org/ml/gdb-patches/2015-01/msg00592.html gdb/ChangeLog: 2015-01-23 Pedro Alves <palves@redhat.com> * linux-nat.c (linux_is_async_p): New macro. (linux_nat_is_async_p): (linux_nat_terminal_inferior): Check whether the target can async instead of whether it is already async. (linux_nat_terminal_ours): Don't check whether the target is async. (linux_async_pipe): Use linux_is_async_p. gdb/testsuite/ChangeLog: 2015-01-23 Pedro Alves <palves@redhat.com> * gdb.threads/continue-pending-after-query.c: New file. * gdb.threads/continue-pending-after-query.exp: New file.
2015-01-23 12:12:39 +01:00
2015-01-23 Pedro Alves <palves@redhat.com>
* gdb.threads/continue-pending-after-query.c: New file.
* gdb.threads/continue-pending-after-query.exp: New file.
Introduce gdb_interact in testsuite gdb_interact is a small utility that we have found quite useful to debug test cases. Putting gdb_interact in a test suspends it and allows to interact with gdb to inspect whatever you want. You can then type ">>>" to resume the test execution. Of course, this is only for gdb devs. It wouldn't make sense to leave a gdb_interact permanently in a test case. When starting the interaction with the user, the script prints this banner: +------------------------------------------+ | Script interrupted, you can now interact | | with by gdb. Type >>> to continue. | +------------------------------------------+ Notes: * When gdb is launched, the gdb_spawn_id variable (lib/gdb.exp) is assigned -1. Given the name, I would expect it to contain the gdb expect spawn id, which is needed for interact. I changed all places that set gdb_spawn_id to -1 to set it to the actual gdb spawn id instead. * When entering the "interact" mode, the last (gdb) prompt is already eaten by expect, so it doesn't show up on the terminal. Subsequent prompts do appear though. We tried to print "(gdb)" just before the interact to replace it. However, it could be misleading if you are debugging an MI test case, it makes you think that you are typing in a CLI prompt, when in reality it's MI. In the end I decided that since the feature is for developers who know what they're doing and that one is normally consciously using gdb_interact, the script doesn't need to babysit the user. * There are probably some quirks depending on where in the script gdb_interact appears (e.g. it could interfere with following commands and make them fail), but it works for most cases. Quirks can always be fixed later. The idea and original implementation was contributed by Anders Granlund, a colleague of mine. Thanks to him. gdb/testsuite/ChangeLog: * gdb.base/statistics.exp: Assign spawn id to gdb_spawn_id. * gdb.base/valgrind-db-attach.exp: Same. * gdb.base/valgrind-infcall.exp: Same. * lib/mi-support.exp (default_mi_gdb_start): Same. * lib/prompt.exp (default_prompt_gdb_start): Same. * lib/gdb.exp (default_gdb_spawn): Same. (gdb_interact): New.
2015-01-22 20:33:04 +01:00
2015-01-22 Anders Granlund <anders.granlund@ericsson.com>
Simon Marchi <simon.marchi@ericsson.com>
* gdb.base/statistics.exp: Assign spawn id to gdb_spawn_id.
* gdb.base/valgrind-db-attach.exp: Same.
* gdb.base/valgrind-infcall.exp: Same.
* lib/mi-support.exp (default_mi_gdb_start): Same.
* lib/prompt.exp (default_prompt_gdb_start): Same.
* lib/gdb.exp (default_gdb_spawn): Same.
(gdb_interact): New.
compile: Fix function pointers TBH while I always comment reasons for each of the compilation options in reality I tried them all and chose that combination that needs the most simple compile/compile-object-load.c (ld.so emulation) implementation. gdb/ChangeLog 2015-01-22 Jan Kratochvil <jan.kratochvil@redhat.com> * compile/compile.c (_initialize_compile): Use -fPIE for compile_args. gdb/testsuite/ChangeLog 2015-01-22 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.compile/compile.exp (pointer to jit function): New test.
2015-01-22 19:18:16 +01:00
2015-01-22 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.compile/compile.exp (pointer to jit function): New test.
Reverse debugging for PowerPC.
2015-01-17 07:30:33 +01:00
2015-01-17 Wei-cheng Wang <cole945@gmail.com>
* lib/gdb.exp (supports_process_record): Return true for
powerpc*-*-linux*.
(supports_reverse): Likewise.
Skip two more attach tests when testing against stub-like targets This patch updates two attach tests to use utility procs for checking if the attach test should run and for launching the program to be attached, as follows: 1) Use can_spawn_for_attach instead of is_remote target 2) Use spawn_wait_for_attach instead of exec/sleep Tested (1) with i686-mingw32 host and i686-pc-linux-gnu build/target and both with x86_64 Ubuntu. gdb/testsuite/ChangeLog: * gdb.base/attach-pie-noexec.exp: Use can_spawn_for_attach instead of checking whether the target board is remote and use spawn_wait_for_attach instead of exec/sleep. * gdb.base/attach-twice.exp: Likewise.
2015-01-15 19:47:31 +01:00
2015-01-15 Don Breazeal <donb@codesourcery.com>
* gdb.base/attach-pie-noexec.exp: Use can_spawn_for_attach
instead of checking whether the target board is remote and
use spawn_wait_for_attach instead of exec/sleep.
* gdb.base/attach-twice.exp: Likewise.
[Ada] 'first/'last/'length of array whose bound is a discriminant Consider the following code: type Table is array (Positive range <>) of Integer; type Object (N : Integer) is record Data : Table (1 .. N); end record; My_Object : Object := (N => 3, Data => (3, 5, 8)); Trying to print the range and length of the My_Object.Data array yields: (gdb) print my_object.data'first $1 = 1 (gdb) print my_object.data'last $2 = 0 (gdb) print my_object.data'length $3 = 0 The first one is correct, and that is thanks to the fact that the lower bound is statically known. However, for the upper bound, and consequently the array's length, the values are incorrect. It should be: (gdb) print my_object.data'last $2 = 3 (gdb) print my_object.data'length $3 = 3 What happens here is that ada_array_bound_from_type sees that our array has a parallel "___XA" type, and therefore tries to use it. In particular, it described our array's index type as: [...]___XDLU_1__n, which means lower bound = 1, and upper bound is value of "n". Unfortunately, ada_array_bound_from_type does not have access to the discriminant, and is therefore unable to compute the bound correctly. Fortunately, at this stage, the bound has already been computed a while ago, and therefore doesn't need to be re-computed here. This patch fixes the issue by ignoring that ___XA type if the array is marked as already fixed. This also fixes the same issue with packed arrays. gdb/ChangeLog: * ada-lang.c (ada_array_bound_from_type): Ignore array's parallel ___XA type if the array has already been fixed. gdb/testsuite/ChangeLog: * gdb.ada/var_arr_attrs: New testcase.
2015-01-15 07:09:32 +01:00
2015-01-15 Joel Brobecker <brobecker@adacore.com>
* gdb.ada/var_arr_attrs: New testcase.
PR17525 - breakpoint commands not executed when program run from -x script Executing a gdb script that runs the inferior (from the command line with -x), and has it hit breakpoints with breakpoint commands that themselves run the target, is currently broken on async targets (Linux, remote). While we're executing a command list or a script, we force the interpreter to be sync, which results in some functions nesting an event loop and waiting for the target to stop, instead of returning immediately and having the top level event loop handle the stop. The issue with this bug is simply that bpstat_do_actions misses checking whether the interpreter is sync. When we get here, in the case of executing a script (or, when the interpreter is sync), the program has already advanced to the next breakpoint, through maybe_wait_sync_command_done. We need to process its breakpoints immediately, just like with a sync target. Tested on x86_64 Fedora 20. gdb/ 2015-01-14 Pedro Alves <palves@redhat.com> PR gdb/17525 * breakpoint.c: Include "interps.h". (bpstat_do_actions_1): Also check whether the interpreter is async. gdb/testsuite/ 2015-01-14 Pedro Alves <palves@redhat.com> Joel Brobecker <brobecker@adacore.com> PR gdb/17525 * gdb.base/bp-cmds-execution-x-script.c: New file. * gdb.base/bp-cmds-execution-x-script.exp: New file. * gdb.base/bp-cmds-execution-x-script.gdb: New file.
2015-01-12 20:30:08 +01:00
2015-01-14 Pedro Alves <palves@redhat.com>
Joel Brobecker <brobecker@adacore.com>
PR gdb/17525
* gdb.base/bp-cmds-execution-x-script.c: New file.
* gdb.base/bp-cmds-execution-x-script.exp: New file.
* gdb.base/bp-cmds-execution-x-script.gdb: New file.
PR cli/17828: -batch -ex r breaks terminal Commit d3d4baed (PR python/17372 - Python hangs when displaying help()) had the side effect of causing 'gdb -batch' to leave the terminal in the wrong state if the program was run. E.g,. $ echo 'main(){*(int*)0=0;}' | gcc -x c -; ./gdb/gdb -batch -ex r ./a.out Program received signal SIGSEGV, Segmentation fault. 0x00000000004004ff in main () $ If you start typing the next command, seemingly nothing happens - GDB left the terminal with echo disabled. The issue is that that "r" ends up in fetch_inferior_event, which calls reinstall_readline_callback_handler_cleanup, which causes readline to prep the terminal (raw, echo disabled). But "-batch" causes GDB to exit before the top level event loop is first started, and then nothing de-preps the terminal. The reinstall_readline_callback_handler_cleanup function's intro comment mentions: "Need to do this as we go back to the event loop, ready to process further input." but the implementation forgets the case of when the interpreter is sync, which indicates we won't return to the event loop yet, or as in the case of -batch, we have not started it yet. The fix is to not install the readline callback in that case. For the test, in this case, checking that command echo still works is sufficient. Comparing stty output before/after running GDB is even better. Because stty may not be available, the test tries both ways. In any case, since expect's spawn (what we use to start gdb) creates a new pseudo tty, another expect spawn or tcl exec after GDB exits would not see the wrong terminal settings. So instead, the test spawns a shell and runs stty and GDB in it. Tested on x86_64 Fedora 20. gdb/ 2015-01-14 Pedro Alves <palves@redhat.com> PR cli/17828 * infrun.c (reinstall_readline_callback_handler_cleanup): Don't reinstall if the interpreter is sync. gdb/testsuite/ 2015-01-14 Pedro Alves <palves@redhat.com> PR cli/17828 * gdb.base/batch-preserve-term-settings.c: New file. * gdb.base/batch-preserve-term-settings.exp: New file.
2015-01-14 12:51:06 +01:00
2015-01-14 Pedro Alves <palves@redhat.com>
PR cli/17828
* gdb.base/batch-preserve-term-settings.c: New file.
* gdb.base/batch-preserve-term-settings.exp: New file.
Enhance gdb.lookup_objfile so that it works with a symlinked binary. gdb/Changelog: * objfiles.c (objfile_filename): New function. * objfiles.h (objfile_filename): Declare it. (objfile_name): Add function comment. * python/py-objfile.c (objfpy_lookup_objfile_by_name): Try both the bfd file name (which may be realpath'd), and the original name. gdb/testsuite/ChangeLog: * gdb.python/py-objfile.exp: Test gdb.lookup_objfile on symlinked binary.
2015-01-14 02:00:31 +01:00
2015-01-13 Doug Evans <dje@google.com>
* gdb.python/py-objfile.exp: Test gdb.lookup_objfile on symlinked
binary.
gdb/testsuite: Make clean mostlyclean should not delete *.py. A sanity-check in my release scripts caught something: After having created the tarballs, I verify that no checked-in file disappeared in the process, and lo and behod, it found that the following file got wiped: - gdb/testsuite/dg-extract-results.py: And it's not part of the tarball either. I don't understand while we delete all *.py files in gdb/testsuite, since I don't see a rule that expected to create one. A run of the testsuite also doesn't seem to be creating .py files there. I traced this to the following commit, which unfortunately provided no explanation. Perhaps we used to run some tests in the gdb/testsuite directory and caused files to be left behind there. Perhaps we still do today? In the meantime, Executive Decision: In order to allow me to create tarballs without losing files, I removed it. It's easy to put something back if we find out why it might still be needed. gdb/testsuite/ChangeLog: * Makefile.in (clean mostlyclean): Do not delete *.py. Tested on x86_64-linux by running the src-release.sh script again, and this time, dg-extract-results.py no longer gets wiped.
2015-01-13 15:59:32 +01:00
2015-01-13 Joel Brobecker <brobecker@adacore.com>
* Makefile.in (clean mostlyclean): Do not delete *.py.
[python/Ada] gdb.lookup_type fails to looking primitive type The following change... commit 1994afbf19892c9e614a034fbf1a5233e9addce3 Date: Tue Dec 23 07:55:39 2014 -0800 Subject: Look up primitive types as symbols. ... caused the following regression: % gdb (gdb) set lang ada (gdb) python print gdb.lookup_type('character') Traceback (most recent call last): File "<string>", line 1, in <module> gdb.error: No type named character. Error while executing Python code. This is because the language_lookup_primitive_type_as_symbol call was moved to the la_lookup_symbol_nonlocal hook. A couple of implementations have been upated accordingly, but the Ada version has not. This patch fixes this omission. gdb/ChangeLog: * ada-lang.c (ada_lookup_symbol_nonlocal): If name not found in static block, then try searching for primitive types. gdb/testsuite/ChangeLog: * gdb.python/py-lookup-type.exp: New file.
2015-01-12 12:46:34 +01:00
2015-01-13 Joel Brobecker <brobecker@adacore.com>
* gdb.python/py-lookup-type.exp: New file.
gdb.python/py-prompt.exp: restore GDBFLAGS The previous change to py-prompt.exp made it return without restoring GDBFLAGS, resulting in breaking the following tests: $ make check RUNTESTFLAGS="--target_board=native-gdbserver --directory=gdb.python" ... Running src/gdb/testsuite/gdb.python/py-prompt.exp ... Running src/gdb/testsuite/gdb.python/py-section-script.exp ... ERROR: (timeout) GDB never initialized after 10 seconds. ERROR: no fileid for gdbuild ERROR: Couldn't send python print ('test') to GDB. ERROR: no fileid for gdbuild ERROR: Couldn't send python print (sys.version_info[0]) to GDB. ERROR: no fileid for gdbuild ERROR: Couldn't send python print (sys.version_info[1]) to GDB. ERROR: no fileid for gdbuild ERROR: no fileid for gdbuild ... gdb/testsuite/ 2015-01-12 Pedro Alves <palves@redhat.com> * gdb.python/py-prompt.exp: When the board can't spawn for attach, restore GDBFLAGS before returning.
2015-01-12 18:10:06 +01:00
2015-01-12 Pedro Alves <palves@redhat.com>
* gdb.python/py-prompt.exp: When the board can't spawn for attach,
restore GDBFLAGS before returning.
[testsuite patch] Fix new FAIL: py-frame.exp: test Frame.read_register(rip) for x86_64 -m32 run one gets: +FAIL: gdb.python/py-frame.exp: test Frame.read_register(rip) I do not have x32 OS here but the %rip test should PASS there I think. On Sun, 11 Jan 2015 14:58:06 +0100, Yao Qi wrote: With your patch applied, this test is skipped on 'x86_64 -m32'. I prefer to increasing the test coverage, so how about extending the test for 'x86_64 -m32'? I mean test Frame.read_register(eip)... gdb/testsuite/ChangeLog 2015-01-12 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.python/py-frame.exp (test Frame.read_register(rip)): Use is_amd64_regs_target and is_x86_like_target.
2015-01-12 11:02:46 +01:00
2015-01-12 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.python/py-frame.exp (test Frame.read_register(rip)): Use
is_amd64_regs_target and is_x86_like_target.
Require numeric attributes to specify the form. gdb/testsuite/ChangeLog: * lib/dwarf.exp (Dwarf): Flag an error if a numeric attribute value is given without an explicit form. * gdb.dwarf2/arr-subrange.exp: Specify forms for all numeric attributes. * gdb.dwarf/corrupt.exp: Ditto. * gdb.dwarf2/enum-type.exp: Ditto. * gdb.trace/entry-values.exp: Ditto. * gdb.trace/unavailable-dwarf-piece.exp: Ditto.
2015-01-12 00:45:43 +01:00
2015-01-11 Doug Evans <xdje42@gmail.com>
* lib/dwarf.exp (Dwarf): Flag an error if a numeric attribute value
is given without an explicit form.
* gdb.dwarf2/arr-subrange.exp: Specify forms for all numeric
attributes.
* gdb.dwarf/corrupt.exp: Ditto.
* gdb.dwarf2/enum-type.exp: Ditto.
* gdb.trace/entry-values.exp: Ditto.
* gdb.trace/unavailable-dwarf-piece.exp: Ditto.
PR gdb/15830 gdb/ChangeLog: PR gdb/15830 * NEWS: The "maint demangle" command is renamed as "demangle". * demangle.c: #include cli/cli-utils.h, language.h. (demangle_command): New function. (_initialize_demangle): Add new command "demangle". * maint.c (maintenance_demangle): Stub out. (_initialize_maint_cmds): Update help text for "maint demangle", and mark as deprecated. gdb/doc/ChangeLog: * gdb.texinfo (Debugging C Plus Plus): Mention "demangle". (Symbols): Ditto. (Maintenance Commands): Delete docs for "maint demangle". gdb/testsuite/ChangeLog: * gdb.base/maint.exp: Remove references to "maint demangle". * gdb.cp/demangle.exp: Update. "maint demangle" -> "demangle". Add tests for explicitly specifying language to demangle. * gdb.dlang/demangle.exp: Ditto.
2015-01-11 23:06:34 +01:00
2015-01-11 Doug Evans <xdje42@gmail.com>
PR gdb/15830
* gdb.base/maint.exp: Remove references to "maint demangle".
* gdb.cp/demangle.exp: Update. "maint demangle" -> "demangle".
Add tests for explicitly specifying language to demangle.
* gdb.dlang/demangle.exp: Ditto.
add non-stop test that stresses thread starvation issues This commit adds a non-stop mode test originally inspired by signal-while-stepping-over-bp-other-thread.exp, that exposes the thread starvation issues fixed by the previous patches. It sets a set of threads stepping in parallel, and has one of them get a signal. Without the previous fixes, this would fail with timeouts. gdb/testsuite/ 2015-01-09 Pedro Alves <palves@redhat.com> * gdb.threads/non-stop-fair-events.c: New file. * gdb.threads/non-stop-fair-events.exp: New file.
2014-12-29 20:41:07 +01:00
2015-01-09 Pedro Alves <palves@redhat.com>
* gdb.threads/non-stop-fair-events.c: New file.
* gdb.threads/non-stop-fair-events.exp: New file.
watch_thread_num.exp and targets with fairer event reporting This patch fixes the watch_thread_num.exp test to work when the target is better at making event handling be fair among threads. I wrote patches that make GDB native and GDBserver event handling fairer between threads. That is, if threads A and B both simultaneously trigger some debug event, GDB will pick either A or B at random, rather than always handling the event of A first. There's code for that in the Linux backends (gdb and gdbserver) already, but it can be improved, and only works in all-stop mode. With those fixes in place, I found that the watch_thread_num.exp would often time out. The problem is that the test only works _because_ event handling isn't as fair as intended. With the fairness fixes, the test falls victim of PR10116 (gdb drops watchpoints on multi-threaded apps) quite often. To expand on the PR10116 reference, consider that stop events are serialized to GDB core, through target_wait. Say a thread-specific watchpoint as set on thread A. When the "right" thread and some other "wrong" thread both trigger a watchpoint simultaneously, the target may report the "wrong" thread's hit to GDB first (thread B). When handling that event, GDB notices the watchpoint is for another thread, and so shouldn't cause a user-visible stop. On resume, GDB saves the now current value of the watched expression. Afterwards, the "right" thread (thread A) reports its watchpoint trigger. But the watched value hasn't changed since GDB last saved it, and so GDB doesn't report the watchpoint hit to the user. The way the test is written, the watchpoint is associated with the first thread that happens to report an event. It happens that GDB is processing events much more often for one of the threads, which usually will be that same first thread. Hacking the test with "set debug infrun 1", we see exactly that: $ grep "infrun.*\[Thread.*," testsuite/gdb.log | sort | uniq -c | sort -nr 70 infrun: 8798 [Thread 8798], 37 infrun: 8798 [Thread 8802], 36 infrun: 8798 [Thread 8804], 36 infrun: 8798 [Thread 8803], 35 infrun: 8798 [Thread 8805], 34 infrun: 8798 [Thread 8806], The first column shows the number of times the target reported an event for that thread, from: infrun: target_wait (-1, status) = infrun: 8798 [Thread 8798], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP This masks out the PR10116 issue. However, if the target is better at giving equal priority to all threads, the PR10116 issue happens often, so it may take quite a while for the right thread to be the first to report its watchpoint event just after the memory being watched really changed, resulting in test time outs. Here's the number of events handled for each thread on a gdbserver run with the event fairness patches: $ grep "infrun.*\[Thread.*," gdb.log | sort | uniq -c 2961 infrun: 13591 [Thread 13591], 2956 infrun: 13591 [Thread 13595], 2941 infrun: 13591 [Thread 13596], 2932 infrun: 13591 [Thread 13597], 2905 infrun: 13591 [Thread 13598], 2891 infrun: 13591 [Thread 13599], Note how the number of events is much higher. The test routinely takes over 10 seconds to finish on my machine rather than under a second as with unpatched gdbserver, when it succeeds, but often it'll fail with timeouts too. So to make the test robust, this patch switches the tests to using "awatch" instead of "watch", as access watchpoints don't care about the watchpoint's "old value". With this, the test always finishes quickly, and we can even bump the number of threads concurrently writting to the shared variable, to have better assurance we're really testing the case of the "wrong" thread triggering a watchpoint. Here's the number of events I see for each thread on a run on my machine, with a gdbserver patched with the event fairness series: $ grep "infrun.*\[Thread.*," testsuite/gdb.log | sort | uniq -c 5 infrun: 5298 [Thread 5302], 4 infrun: 5298 [Thread 5303], 4 infrun: 5298 [Thread 5304], 4 infrun: 5298 [Thread 5305], 4 infrun: 5298 [Thread 5306], 4 infrun: 5298 [Thread 5307], 4 infrun: 5298 [Thread 5308], 4 infrun: 5298 [Thread 5309], 4 infrun: 5298 [Thread 5310], 4 infrun: 5298 [Thread 5311], 4 infrun: 5298 [Thread 5312], 4 infrun: 5298 [Thread 5313], 4 infrun: 5298 [Thread 5314], 4 infrun: 5298 [Thread 5315], 4 infrun: 5298 [Thread 5316], gdb/testsuite/ 2015-01-09 Pedro Alves <palves@redhat.com> * gdb.base/annota1.exp (thread_test): Use srcfile and binfile from the global scope. Set a breakpoint after all threads are started rather than stepping over two source lines. Expect the prompt. * gdb.base/watch_thread_num.c (threads_started_barrier): New global. (NUM): Now 15. (main): Use threads_started_barrier to wait for all threads to start. Main thread no longer calls thread_function. Exit after 180 seconds. (loop): New function. (thread_function): Wait on threads_started_barrier barrier. Call 'loop' at each iteration. * gdb.base/watch_thread_num.exp: Continue to breakpoint after all threads have started, instead of hardcoding number of "next" steps. Use an access watchpoint instead of a write watchpoint.
2014-12-29 20:41:05 +01:00
2015-01-09 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (thread_test): Use srcfile and binfile from
the global scope. Set a breakpoint after all threads are started
rather than stepping over two source lines. Expect the prompt.
* gdb.base/watch_thread_num.c (threads_started_barrier): New
global.
(NUM): Now 15.
(main): Use threads_started_barrier to wait for all threads to
start. Main thread no longer calls thread_function. Exit after
180 seconds.
(loop): New function.
(thread_function): Wait on threads_started_barrier barrier. Call
'loop' at each iteration.
* gdb.base/watch_thread_num.exp: Continue to breakpoint after all
threads have started, instead of hardcoding number of "next"
steps. Use an access watchpoint instead of a write watchpoint.
gdb.threads/{siginfo-thread.c,watchthreads-reorder.c,ia64-sigill.c} races with GDB These three test all spawn a few threads and then send a SIGSTOP to their parent GDB in order to pause it while the new threads set things up for the test. With a GDB patch that changes the inferior thread's scheduling a bit, I sometimes see: FAIL: gdb.threads/siginfo-threads.exp: catch signal 0 (timeout) ... FAIL: gdb.threads/watchthreads-reorder.exp: reorder1: continue a (timeout) ... FAIL: gdb.threads/ia64-sigill.exp: continue (timeout) ... The issue is that the test program stops GDB before it had a chance of processing the new thread's clone event: (gdb) PASS: gdb.threads/siginfo-threads.exp: get pid continue Continuing. Stopping GDB PID 21541. Waiting till the threads initialize their TIDs. FAIL: gdb.threads/siginfo-threads.exp: catch signal 0 (timeout) On Linux (at least), new threads start stopped, and the debugger must resume them. The fix is to make the test program wait for the new threads to be running before stopping GDB. gdb/testsuite/ 2015-01-09 Pedro Alves <palves@redhat.com> * gdb.threads/ia64-sigill.c (threads_started_barrier): New global. (thread_func): Wait on barrier. (main): Wait for all threads to start before stopping GDB. * gdb.threads/siginfo-threads.c (threads_started_barrier): New global. (thread1_func, thread2_func): Wait on barrier. (main): Wait for all threads to start before stopping GDB. * gdb.threads/watchthreads-reorder.c (threads_started_barrier): New global. (thread1_func, thread2_func): Wait on barrier. (main): Wait for all threads to start before stopping GDB.
2014-12-29 20:41:04 +01:00
2015-01-09 Pedro Alves <palves@redhat.com>
* gdb.threads/ia64-sigill.c (threads_started_barrier): New global.
(thread_func): Wait on barrier.
(main): Wait for all threads to start before stopping GDB.
* gdb.threads/siginfo-threads.c (threads_started_barrier): New
global.
(thread1_func, thread2_func): Wait on barrier.
(main): Wait for all threads to start before stopping GDB.
* gdb.threads/watchthreads-reorder.c (threads_started_barrier):
New global.
(thread1_func, thread2_func): Wait on barrier.
(main): Wait for all threads to start before stopping GDB.
Test attaching to a program that constantly spawns short-lived threads Before the previous fixes, on Linux, this would trigger several different problems, like: [New LWP 27106] [New LWP 27047] warning: unable to open /proc file '/proc/-1/status' [New LWP 27813] [New LWP 27869] warning: Can't attach LWP 11962: No child processes Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: debugger service failed warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. gdb/testsuite/ 2015-01-09 Pedro Alves <palves@redhat.com> * gdb.threads/attach-many-short-lived-threads.c: New file. * gdb.threads/attach-many-short-lived-threads.exp: New file.
2014-12-17 21:40:05 +01:00
2015-01-09 Pedro Alves <palves@redhat.com>
* gdb.threads/attach-many-short-lived-threads.c: New file.
* gdb.threads/attach-many-short-lived-threads.exp: New file.
Linux: Skip thread_db thread event reporting if PTRACE_EVENT_CLONE is supported [A test I wrote stumbled on a libthread_db issue related to thread event breakpoints. See glibc PR17705: [nptl_db: stale thread create/death events if debugger detaches] https://sourceware.org/bugzilla/show_bug.cgi?id=17705 This patch avoids that whole issue by making GDB stop using thread event breakpoints in the first place, which is good for other reasons as well, anyway.] Before PTRACE_EVENT_CLONE (Linux 2.6), the only way to learn about new threads in the inferior (to attach to them) or to learn about thread exit was to coordinate with the inferior's glibc/runtime, using libthread_db. That works by putting a breakpoint at a magic address which is called when a new thread is spawned, or when a thread is about to exit. When that breakpoint is hit, all threads are stopped, and then GDB coordinates with libthread_db to read data structures out of the inferior to learn about what happened. Then the breakpoint is single-stepped, and then all threads are re-resumed. This isn't very efficient (stops all threads) and is more fragile (inferior's thread list in memory may be corrupt; libthread_db bugs, etc.) than ideal. When the kernel supports PTRACE_EVENT_CLONE (which we already make use of), there's really no need to use libthread_db's event reporting mechanism to learn about new LWPs. And if the kernel supports that, then we learn about LWP exits through regular WIFEXITED wait statuses, so no need for the death event breakpoint either. GDBserver has been likewise skipping the thread_db events for a long while: https://sourceware.org/ml/gdb-patches/2007-10/msg00547.html There's one user-visible difference: we'll no longer print about threads being created and exiting while the program is running, like: [Thread 0x7ffff7dbb700 (LWP 30670) exited] [New Thread 0x7ffff7db3700 (LWP 30671)] [Thread 0x7ffff7dd3700 (LWP 30667) exited] [New Thread 0x7ffff7dab700 (LWP 30672)] [Thread 0x7ffff7db3700 (LWP 30671) exited] [Thread 0x7ffff7dcb700 (LWP 30668) exited] This is exactly the same behavior as when debugging against remote targets / gdbserver. I actually think that's a good thing (and as such have listed this in the local/remote parity wiki page a while ago), as the printing slows down the inferior. It's also a distraction to keep bothering the user about short-lived threads that she won't be able to interact with anyway. Instead, the user (and frontend) will be informed about new threads that currently exist in the program when the program next stops: (gdb) c ... * ctrl-c * [New Thread 0x7ffff7963700 (LWP 7797)] [New Thread 0x7ffff796b700 (LWP 7796)] Program received signal SIGINT, Interrupt. [Switching to Thread 0x7ffff796b700 (LWP 7796)] clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:81 81 testq %rax,%rax (gdb) info threads A couple of tests had assumptions on GDB thread numbers that no longer hold. Tested on x86_64 Fedora 20. gdb/ 2014-01-09 Pedro Alves <palves@redhat.com> Skip enabling event reporting if the kernel supports PTRACE_EVENT_CLONE. * linux-thread-db.c: Include "nat/linux-ptrace.h". (thread_db_use_events): New function. (try_thread_db_load_1): Check thread_db_use_events before enabling event reporting. (update_thread_state): New function. (attach_thread): Use it. Check thread_db_use_events before enabling event reporting. (thread_db_detach): Check thread_db_use_events before disabling event reporting. (find_new_threads_callback): Check thread_db_use_events before enabling event reporting. Update the thread's state if not using libthread_db events. gdb/testsuite/ 2014-01-09 Pedro Alves <palves@redhat.com> * gdb.threads/fork-thread-pending.exp: Switch to the main thread instead of to thread 2. * gdb.threads/signal-command-multiple-signals-pending.c (main): Add barrier around each pthread_create call instead of around all calls. * gdb.threads/signal-command-multiple-signals-pending.exp (test): Set a break on thread_function and have the child threads hit it one at at a time.
2014-12-16 17:12:25 +01:00
2014-01-09 Pedro Alves <palves@redhat.com>
* gdb.threads/fork-thread-pending.exp: Switch to the main thread
instead of to thread 2.
* gdb.threads/signal-command-multiple-signals-pending.c (main):
Add barrier around each pthread_create call instead of around all
calls.
* gdb.threads/signal-command-multiple-signals-pending.exp (test):
Set a break on thread_function and have the child threads hit it
one at at a time.
skip "attach" tests when testing against stub-like targets We already skip "attach" tests if the target board is remote, in dejagnu's sense, as we use TCL's exec to spawn the program on the build machine. We should also skip these tests if testing with "target remote" or other stub-like targets where "attach" doesn't make sense. Add a helper procedure that centralizes the checks a test that needs to spawn a program for testing "attach" and make all test files that use spawn_wait_for_attach check it. gdb/testsuite/ 2015-01-09 Pedro Alves <palves@redhat.com> * lib/gdb.exp (can_spawn_for_attach): New procedure. (spawn_wait_for_attach): Error out if can_spawn_for_attach returns false. * gdb.base/attach.exp: Use can_spawn_for_attach instead of checking whether the target board is remote. * gdb.multi/multi-attach.exp: Likewise. * gdb.python/py-sync-interp.exp: Likewise. * gdb.server/ext-attach.exp: Likewise. * gdb.python/py-prompt.exp: Use can_spawn_for_attach before the tests that need to attach, instead of checking whether the target board is remote at the top of the file.
2015-01-09 12:04:19 +01:00
2015-01-09 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (can_spawn_for_attach): New procedure.
(spawn_wait_for_attach): Error out if can_spawn_for_attach returns
false.
* gdb.base/attach.exp: Use can_spawn_for_attach instead of
checking whether the target board is remote.
* gdb.multi/multi-attach.exp: Likewise.
* gdb.python/py-sync-interp.exp: Likewise.
* gdb.server/ext-attach.exp: Likewise.
* gdb.python/py-prompt.exp: Use can_spawn_for_attach before the
tests that need to attach, instead of checking whether the target
board is remote at the top of the file.
Recognize branch instruction on MIPS in gdb.trace/entry-values.exp The test entry-values.exp doesn't recognize the call instructions on MIPS, such as JAL, JALS and etc, so this patch sets call_insn to match various jump and branch instructions first. Currently, we assume the next instruction address of call instruction is the address returned from foo, however it is not correct on MIPS which has delay slot. We extend variable call_insn to match one instruction after jump or branch instruction, so that $returned_from_foo is correct on MIPS. All tests in entry-values.exp are PASS. gdb/testsuite: 2015-01-08 Yao Qi <yao@codesourcery.com> * gdb.trace/entry-values.exp: Set call_insn for MIPS target.
2014-12-30 07:40:49 +01:00
2015-01-08 Yao Qi <yao@codesourcery.com>
* gdb.trace/entry-values.exp: Set call_insn for MIPS target.
[testsuite patch] Fix avx512.exp regression +gdb compile failed, ^[[01m^[[Kgdb/testsuite/gdb.arch/i386-avx512.c:20:27:^[[m^[[K ^[[01;31m^[[Kfatal error: ^[[m^[[Knat/x86-cpuid.h: No such file or directory + #include "nat/x86-cpuid.h" +^[[01;32m^[[K ^^[[m^[[K +compilation terminated. +UNTESTED: gdb.arch/i386-avx512.exp: i386-avx512.exp 125f8a3ddedd413a2290dae011f0bed9ffc78278 is the first bad commit commit 125f8a3ddedd413a2290dae011f0bed9ffc78278 Author: Gary Benson <gbenson@redhat.com> Date: Thu Jun 19 14:46:38 2014 +0100 Move shared native target specific code to gdb/nat gdb/testsuite/ChangeLog 2015-01-07 Jan Kratochvil <jan.kratochvil@redhat.com> Fix testcase compilation. * gdb.arch/i386-avx512.exp (comp_flags): Remove /common.
2015-01-07 15:42:57 +01:00
2015-01-07 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix testcase compilation.
* gdb.arch/i386-avx512.exp (comp_flags): Remove /common.
gdb/python: exception trying to create empty array The following python command fails: (gdb) python print gdb.lookup_type('char').array(1, 0) Traceback (most recent call last): File "<string>", line 1, in <module> ValueError: Array length must not be negative Error while executing Python code. The above is trying to create an empty array, which is fairly command in Ada. gdb/ChangeLog: * python/py-type.c (typy_array_1): Do not raise negative-length exception if N2 is equal to N1 - 1. gdb/testsuite/ChangeLog: * gdb.python/py-type.exp: Add a couple test about empty array creation, and negative-length array creation.
2015-01-06 15:30:53 +01:00
2015-01-06 Joel Brobecker <brobecker@adacore.com>
* gdb.python/py-type.exp: Add a couple test about empty
array creation, and negative-length array creation.
gdb.cp/nsalias.exp: Fix output of external/declaration flags. gdb/testsuite/ChangeLog: * gdb.cp/nsalias.exp: Fix output of external/declaration flags.
2015-01-03 07:00:57 +01:00
2015-01-02 Doug Evans <xdje42@gmail.com>
* gdb.cp/nsalias.exp: Fix output of external/declaration flags.
gdb.dwarf2/dw4-sig-types.exp: Also pass -fdebug-types-section to gcc. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw4-sig-types.exp: Also pass -fdebug-types-section to gcc.
2015-01-02 21:59:44 +01:00
2015-01-02 Doug Evans <dje@google.com>
* gdb.dwarf2/dw4-sig-types.exp: Also pass -fdebug-types-section to gcc.
Clean up gdb.trace/entry-values.exp This patch is to clean up gdb.trace/entry-values.exp as a preparation of the next patch. It updates the comments to reflect the code. One DIE generated in dwarf assembler is GNU_call_site { {low_pc "$bar_start + $bar_call_foo" addr} {abstract_origin :$foo_label} the DW_AT_low_pc attribute is the return address after the call, so I rename variable bar_call_foo to returned_from_foo. gdb/testsuite: 2014-12-29 Yao Qi <yao@codesourcery.com> * gdb.trace/entry-values.exp: Update comments. Rename variable bar_call_foo to returned_from_foo.
2014-12-29 04:56:51 +01:00
2014-12-29 Yao Qi <yao@codesourcery.com>
* gdb.trace/entry-values.exp: Update comments. Rename variable
bar_call_foo to returned_from_foo.
gdb/17394: cannot put breakpoint only in selected ASM file. This patch fixes a problem when trying to insert a breakpoint on a specific symbol defined in a specific file, eg: break foo.c:func This currently works for files in C/C++/Ada, etc, but doesn't always work for Asm files. Analysis of the problem showed that this related to a limitation in gas, which does not generate debug info for functions/ symbols. Thus, we have a symtab for the file ("info sources" shows the file), but it contains no symbols. When find_linespec_symbols is called in linespec_parse_basic, it calls find_function_symbols, which uses add_matching_symbols_to_info to collect all matching symbols. That function does [pardon any mangled formatting]: for (ix = 0; VEC_iterate (symtab_ptr, info->file_symtabs, ix, elt); ++ix) { if (elt == NULL) { iterate_over_all_matching_symtabs (info->state, name, VAR_DOMAIN, collect_symbols, info, pspace, 1); search_minsyms_for_name (info, name, pspace); } else if (pspace == NULL || pspace == SYMTAB_PSPACE (elt)) { /* Program spaces that are executing startup should have been filtered out earlier. */ gdb_assert (!SYMTAB_PSPACE (elt)->executing_startup); set_current_program_space (SYMTAB_PSPACE (elt)); iterate_over_file_blocks (elt, name, VAR_DOMAIN, collect_symbols, info); } } This iterates over the symtabs. In the failing use case, ELT is non-NULL (points to the symtab for the .s file), so it calls iterate_over_file_blocks. Herein is where the problem exists: it is assumed that if NAME exists, it must exist in the given symtab -- a reasonable assumption for "normal" (non-asm) cases. It never searches minimal symbols (or in the global default symtab). This patch fixes the problem by doing so. It is important to note that iterating over minsyms is fairly expensive, so this patch only adds that extra search if the language is language_asm and iterate_over_file_blocks returns no symbols. gdb/ChangeLog: 2014-12-20 Keith Seitz <keiths@redhat.com> Mihail-Marian Nistor <mihail.nistor@freescale.com> PR gdb/17394 * linespec.c (struct collect_minsyms): Add new member `symtab'. (add_minsym): Handle cases where info.symtab is non-NULL. (search_minsyms_for_name): Add new parameter `symtab'. Handle limiting searches to a specific symtab. (add_matching_symtabs_to_info): Search through minimal symbols for language_asm files for which no new symbols are found. gdb/testsuite/ChangeLog: 2014-12-20 Mihail-Marian Nistor <mihail.nistor@freescale.com> PR gdb/17394 * gdb.linespec/break-asm-file.c: New file. * gdb.linespec/break-asm-file.exp: New file. * gdb.linespec/break-asm-file0.s: New file. * gdb.linespec/break-asm-file1.s: New file.
2014-12-20 17:04:44 +01:00
2014-12-20 Mihail-Marian Nistor <mihail.nistor@freescale.com>
PR gdb/17394
* gdb.linespec/break-asm-file.c: New file.
* gdb.linespec/break-asm-file.exp: New file.
* gdb.linespec/break-asm-file0.s: New file.
* gdb.linespec/break-asm-file1.s: New file.
MIPS: Provide FPU info and decode FCSR in `info float' This patch is the V2. V1 can be found in https://sourceware.org/ml/gdb-patches/2012-05/msg00938.html V2 is to address Joel's comment <https://sourceware.org/ml/gdb-patches/2012-06/msg00289.html> about keeping dumping floating point registers. Additionally, command 'info float' prints bits on nan2008 and abs2008. ------------------------------------------------------------------ The change below provides a MIPS-specific handler for the: (gdb) info float command. It provides information about the FPU type available (if any), the FPU register width, and decodes the CP1 Floating Point Control and Status Register (FCSR): (gdb) print /x $fsr $1 = 0xff83ffff (gdb) info float fpu type: double-precision reg size: 32 bits cond : 0 1 2 3 4 5 6 7 cause : inexact uflow oflow div0 inval unimp mask : inexact uflow oflow div0 inval flags : inexact uflow oflow div0 inval rounding: -inf flush : zero One point to note about CP1.FCSR are the non-standard Flush-to-Nearest and Flush-Override bits. They are not a part of the MIPS architecture and take two positions reserved for an implementation-dependent use in the architecture. They are present in all the FPU implementations made by MIPS Technologies since the spin-off from SGI. I haven't been able to track down a single other MIPS FPU implementation that would make any use of these bits and they are required to be hardwired to zero by the architecture specification if unimplemented. Therefore I think it makes sense to report them in the current way. GDB has no guaranteed access to the CP0 Processor Identification (PRId) register to validate this feature properly and the ID information stored in the CP1 Floating Point Implementation Register (FIR) is from my experience not reliable enough (there's no Company ID available there for once unlike in CP0.PRId and Processor ID is not guaranteed to be unique). As a side note we should probably dump CP1.FIR information as well, as there's useful stuff indicating some FPU features there. That's material for another change however. gdb/ 2014-12-18 Nigel Stephens <nigel@mips.com> Maciej W. Rozycki <macro@codesourcery.com> * mips-tdep.c (print_fpu_flags): New function. (mips_print_float_info): Likewise. (mips_gdbarch_init): Install mips_print_float_info as gdbarch print_float_info routine. gdb/testsuite/ 2014-12-18 Nigel Stephens <nigel@mips.com> Maciej W. Rozycki <macro@codesourcery.com> * gdb.base/float.exp: Handle the new output from "info float" on MIPS targets.
2014-12-18 13:47:28 +01:00
2014-12-18 Nigel Stephens <nigel@mips.com>
Maciej W. Rozycki <macro@codesourcery.com>
* gdb.base/float.exp: Handle the new output from "info float" on
MIPS targets.
Fix MinGW compilation On Sun, 14 Dec 2014 07:00:28 +0100, Yao Qi wrote: The build on mingw host is broken because mingw has no mkdtemp. ../../../git/gdb/compile/compile.c: In function 'get_compile_file_tempdir': ../../../git/gdb/compile/compile.c:194:3: error: implicit declaration of function 'mkdtemp' [-Werror=implicit-function-declaration] tempdir_name = mkdtemp (tname); ^ ../../../git/gdb/compile/compile.c:194:16: error: assignment makes pointer from integer without a cast [-Werror] tempdir_name = mkdtemp (tname); ^ cc1: all warnings being treated as errors In the end I have managed to test it by Wine myself: $ wine build_win32/gdb/gdb.exe -q build_win32/gdb/gdb.exe -ex start -ex 'compile code 1' -ex 'set confirm no' -ex quit [...] Temporary breakpoint 1, main (argc=1, argv=0x241418) at ../../gdb/gdb.c:29 29 args.argc = argc; Could not load libcc1.so: Module not found. Even if it managed to load libcc1.so (it needs host-dependent name libcc1.dll) then it would soon end up at least on: default_infcall_mmap: error (_("This target does not support inferior memory allocation by mmap.")); As currently there is only: linux-tdep.c: set_gdbarch_infcall_mmap (gdbarch, linux_infcall_mmap); While one could debug Linux targets from MS-Windows host I find it somehow overcomplicated now when we are trying to get it running at least on native Linux x86*. The 'compile' project needs a larger port effort to run on MS-Windows. gdb/ChangeLog 2014-12-17 Jan Kratochvil <jan.kratochvil@redhat.com> Fix MinGW compilation. * compile/compile.c (get_compile_file_tempdir): Call error if !HAVE_MKDTEMP. * config.in: Regenerate. * configure: Regenerate. * configure.ac (AC_CHECK_FUNCS): Add mkdtemp. gdb/testsuite/ChangeLog 2014-12-17 Jan Kratochvil <jan.kratochvil@redhat.com> Fix MinGW compilation. * gdb.compile/compile-ops.exp: Update untested message if !skip_compile_feature_tests. * gdb.compile/compile-setjmp.exp: Likewise. * gdb.compile/compile-tls.exp: Likewise. * gdb.compile/compile.exp: Likewise. * lib/gdb.exp (skip_compile_feature_tests): Check also "Command not supported on this host".
2014-12-17 20:09:02 +01:00
2014-12-17 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix MinGW compilation.
* gdb.compile/compile-ops.exp: Update untested message if
!skip_compile_feature_tests.
* gdb.compile/compile-setjmp.exp: Likewise.
* gdb.compile/compile-tls.exp: Likewise.
* gdb.compile/compile.exp: Likewise.
* lib/gdb.exp (skip_compile_feature_tests): Check also "Command not
supported on this host".
boards/stabs.exp: New file. gdb/ChangeLog: * boards/stabs.exp: New file.
2014-12-17 08:10:54 +01:00
2014-12-16 Doug Evans <xdje42@gmail.com>
* boards/stabs.exp: New file.
Fix indentation of "maint print user-registers" This fixes a failure of the test case "complete 'info registers '" in completion.exp on architectures where the user registers have numbers above 99. In that case the output of "maint print user-registers" was no longer indented, and the regexp in the test case failed to add them to the list of expected completion results. The fix also swaps the columns "Name" and "Nr", such that the indentation is always the same, and to be consistent with the output of "maint print registers". gdb/ChangeLog: * user-regs.c (maintenance_print_user_registers): Swap "Nr" and "Name" columns. Assure that the output is always indented. gdb/testsuite/ChangeLog: * gdb.base/completion.exp: Adjust to format changes of "maint print user-registers".
2014-12-16 16:06:42 +01:00
2014-12-16 Andreas Arnez <arnez@vnet.linux.ibm.com>
* gdb.base/completion.exp: Adjust to format changes of "maint
print user-registers".
aarch64/gdbserver: fix floating point registers display When using aarch64 gdb with gdbserver, floating point registers are not correctly displayed, as below: (gdb) info registers fpsr fpcr fpsr <unavailable> fpcr <unavailable> To fix these problems, the missing fpsr and fpcr registers are added when floating point registers are read/write Add test for aarch64 floating point PR server/17457 gdb/gdbserver/ PR server/17457 * linux-aarch64-low.c (AARCH64_FPSR_REGNO): New define. (AARCH64_FPCR_REGNO): Likewise. (AARCH64_NUM_REGS): Update to include fpsr/fpcr registers. (aarch64_fill_fpregset): Add missing fpsr/fpcr registers. (aarch64_store_fpregset): Likewise. gdb/testsuite/ PR server/17457 * gdb.arch/aarch64-fp.c: New file. * gdb.arch/aarch64-fp.exp: New file. Signed-off-by: Catalin Udma <catalin.udma@freescale.com>
2014-12-16 08:51:42 +01:00
2014-12-16 Catalin Udma <catalin.udma@freescale.com>
PR server/17457
* gdb.arch/aarch64-fp.c: New file.
* gdb.arch/aarch64-fp.exp: New file.
Merge dg-extract-results.{sh,py} from GCC upstream It has been a while since we don't sync this file with GCC upstream, and in the meantime some interesting things have happened. The most interesting is the inclusion of a new dg-extract-results.py which is apparently faster than its shell equivalent. This merge will probably fix the bug described in <https://sourceware.org/ml/gdb-patches/2014-12/msg00421.html> Though I am still proposing the patch for upstream GCC. Once it gets accepted, I will merge it too. OK to apply? gdb/testsuite/ChangeLog: 2014-12-15 Sergio Durigan Junior <sergiodj@redhat.com> Merge dg-extract-results.{sh,py} from GCC upstream (r210243, r210637, r210913, r211666, r215400, r215817). 2014-05-08 Richard Sandiford <rdsandiford@googlemail.com> * dg-extract-results.py: New file. * dg-extract-results.sh: Use it if the environment seems suitable. 2014-05-20 Richard Sandiford <rdsandiford@googlemail.com> * dg-extract-results.py (parse_run): Handle warnings that are printed before a test harness is run. 2014-05-25 Richard Sandiford <rdsandiford@googlemail.com> * dg-extract-results.py (Named): Remove __cmp__ method. (output_variation): Use a key to sort variation.harnesses. 2014-06-14 Richard Sandiford <rdsandiford@googlemail.com> * dg-extract-results.py: For Python 3, force sys.stdout to handle surrogate escape sequences. (safe_open): New function. (output_segment, main): Use it. 2014-09-19 Segher Boessenkool <segher@kernel.crashing.org> * dg-extract-results.py (Prog.result_re): Include options in test name. 2014-10-02 Segher Boessenkool <segher@kernel.crashing.org> * dg-extract-results.py (output_variation): Always sort if do_sum.
2014-12-16 01:34:24 +01:00
2014-12-15 Sergio Durigan Junior <sergiodj@redhat.com>
Merge dg-extract-results.{sh,py} from GCC upstream (r210243,
r210637, r210913, r211666, r215400, r215817).
2014-05-08 Richard Sandiford <rdsandiford@googlemail.com>
* dg-extract-results.py: New file.
* dg-extract-results.sh: Use it if the environment seems
suitable.
2014-05-20 Richard Sandiford <rdsandiford@googlemail.com>
* dg-extract-results.py (parse_run): Handle warnings that
are printed before a test harness is run.
2014-05-25 Richard Sandiford <rdsandiford@googlemail.com>
* dg-extract-results.py (Named): Remove __cmp__ method.
(output_variation): Use a key to sort variation.harnesses.
2014-06-14 Richard Sandiford <rdsandiford@googlemail.com>
* dg-extract-results.py: For Python 3, force sys.stdout to
handle surrogate escape sequences.
(safe_open): New function.
(output_segment, main): Use it.
2014-09-19 Segher Boessenkool <segher@kernel.crashing.org>
* dg-extract-results.py (Prog.result_re): Include options
in test name.
2014-10-02 Segher Boessenkool <segher@kernel.crashing.org>
* dg-extract-results.py (output_variation): Always sort if
do_sum.
testsuite: expect possible pagination when starting gdb When gdb starts, the lines that appear before the first prompt may get paginated if the terminal in which the tests are ran is too small (in terms of rows). These lines include the welcome/license message and possibly more, such as "Reading symbols from...". Pagination is disabled right after gdb is started (with "set height 0"), but this output happens before we are able to set height. If these lines get paginated, gdb waits for the user to press enter and the test harness waits for gdb to print its prompt, resulting in a deadlock. My first idea was to launch gdb with --quiet. However, some lines are still printed ("Reading symbols from...", some more stuff when attaching with --pid, etc). The proposed solution simply expects that pagination can occur after starting gdb. If this is the case, it sends a "\n" and loops. gdb/testsuite/Changelog: * lib/gdb.exp (default_gdb_start): After starting gdb, loop as long as we get pagination notifications.
2014-12-15 17:46:44 +01:00
2014-12-15 Simon Marchi <simon.marchi@ericsson.com>
* lib/gdb.exp (default_gdb_start): After starting gdb, loop
as long as we get pagination notifications.
* Makefile.in (check-gdb.%): Restore. * README: Mention it.
2014-12-09 21:50:03 +01:00
2014-12-15 Jason Merrill <jason@redhat.com>
* Makefile.in (check-gdb.%): Restore.
* README: Mention it.
Internal error trying to print uninitialized string. Trying to print the value of a string whose size is not known at compile-time before it gets assigned a value can lead to the following internal error: (gdb) p my_str $1 = /[...]/utils.c:1089: internal-error: virtual memory exhausted. What happens is that my_str is described as a reference to an array type whose bounds are dynamic. During the read of that variable's value (in default_read_var_value), we end up resolving dynamic types which, for reference types, makes us also resolve the target of that reference type. This means we resolve our variable to a reference to an array whose bounds are undefined, and unfortunately very far appart. So, when we pass that value to ada-valprint, and in particular to da_val_print_ref, we eventually try to allocate too large of a buffer corresponding to the (bogus) size of our array, hence the internal error. This patch fixes the problem by adding a size_check before trying to print the dereferenced value. To perform this check, a function that was previously specific to ada-lang.c (check_size) gets exported, and renamed to something less prone to name collisions (ada_ensure_varsize_limit). gdb/ChangeLog: * ada-lang.h (ada_ensure_varsize_limit): Declare. * ada-lang.c (check_size): Remove advance declaration. (ada_ensure_varsize_limit): Renames check_size. Replace calls to check_size by calls to ada_ensure_varsize_limit throughout. * ada-valprint.c (ada_val_print_ref): Add call to ada_ensure_varsize_limit. Add comment explaining why. gdb/testsuite/ChangeLog: * gdb.ada/str_uninit: New testcase.
2014-12-08 16:37:00 +01:00
2014-12-13 Joel Brobecker <brobecker@adacore.com>
* gdb.ada/str_uninit: New testcase.
Fix 7.8 regression: resolve_dynamic_struct: Assertion `TYPE_NFIELDS (type) > 0' (PR 17642) https://sourceware.org/bugzilla/show_bug.cgi?id=17642 Regression since: commit 012370f6818657a816df1463ee71ca4e4ee40b33 Author: Tom Tromey <tromey@redhat.com> Date: Thu May 8 11:26:44 2014 -0600 handle VLA in a struct or union Bugreport: Regression with gdb scripts for Linux kernel https://sourceware.org/ml/gdb/2014-08/msg00127.html That big change after "else" is just reindentation. gdb/ChangeLog 2014-12-13 Jan Kratochvil <jan.kratochvil@redhat.com> PR symtab/17642 * gdbtypes.c (resolve_dynamic_type_internal): Apply check_typedef to TYPE if not TYPE_CODE_TYPEDEF. gdb/testsuite/ChangeLog 2014-12-13 Jan Kratochvil <jan.kratochvil@redhat.com> PR symtab/17642 * gdb.base/vla-stub-define.c: New file. * gdb.base/vla-stub.c: New file. * gdb.base/vla-stub.exp: New file.
2014-12-13 15:31:59 +01:00
2014-12-13 Jan Kratochvil <jan.kratochvil@redhat.com>
PR symtab/17642
* gdb.base/vla-stub-define.c: New file.
* gdb.base/vla-stub.c: New file.
* gdb.base/vla-stub.exp: New file.
the "compile" command This final patch adds the new "compile" command and subcommands, and all the machinery needed to make it work. A shared library supplied by gcc is used for all communications with gcc. Types and most aspects of symbols are provided directly by gdb to the compiler using this library. gdb provides some information about the user's code using plain text. Macros are emitted this way, and DWARF location expressions (and bounds for VLA) are compiled to C code. This hybrid approach was taken because, on the one hand, it is better to provide global declarations and such on demand; but on the other hand, for local variables, translating DWARF location expressions to C was much simpler than exporting a full compiler API to gdb -- the same result, only easier to implement, understand, and debug. In the ordinary mode, the user's expression is wrapped in a dummy function. After compilation, gdb inserts the resulting object code into the inferior, then calls this function. Access to local variables is provided by noting which registers are used by location expressions, and passing a structure of register values into the function. Writes to registers are supported by copying out these values after the function returns. This approach was taken so that we could eventually implement other more interesting features based on this same infrastructure; for example, we're planning to investigate inferior-side breakpoint conditions. gdb/ChangeLog 2014-12-12 Phil Muldoon <pmuldoon@redhat.com> Jan Kratochvil <jan.kratochvil@redhat.com> Tom Tromey <tromey@redhat.com> * NEWS: Update. * symtab.h (struct symbol_computed_ops) <generate_c_location>: New field. * p-lang.c (pascal_language_defn): Update. * opencl-lang.c (opencl_language_defn): Update. * objc-lang.c (objc_language_defn): Update. * m2-lang.c (m2_language_defn): Update. * language.h (struct language_defn) <la_get_compile_instance, la_compute_program>: New fields. * language.c (unknown_language_defn, auto_language_defn) (local_language_defn): Update. * jv-lang.c (java_language_defn): Update. * go-lang.c (go_language_defn): Update. * f-lang.c (f_language_defn): Update. * dwarf2loc.h (dwarf2_compile_property_to_c): Declare. * dwarf2loc.c (dwarf2_compile_property_to_c) (locexpr_generate_c_location, loclist_generate_c_location): New functions. (dwarf2_locexpr_funcs, dwarf2_loclist_funcs): Update. * defs.h (enum compile_i_scope_types): New. (enum command_control_type) <compile_control>: New constant. (struct command_line) <control_u>: New field. * d-lang.c (d_language_defn): Update. * compile/compile.c: New file. * compile/compile-c-support.c: New file. * compile/compile-c-symbols.c: New file. * compile/compile-c-types.c: New file. * compile/compile.h: New file. * compile/compile-internal.h: New file. * compile/compile-loc2c.c: New file. * compile/compile-object-load.c: New file. * compile/compile-object-load.h: New file. * compile/compile-object-run.c: New file. * compile/compile-object-run.h: New file. * cli/cli-script.c (multi_line_command_p, print_command_lines) (execute_control_command, process_next_line) (recurse_read_control_structure): Handle compile_control. * c-lang.h (c_get_compile_context, c_compute_program): Declare. * c-lang.c (c_language_defn, cplus_language_defn) (asm_language_defn, minimal_language_defn): Update. * ada-lang.c (ada_language_defn): Update. * Makefile.in (SUBDIR_GCC_COMPILE_OBS, SUBDIR_GCC_COMPILE_SRCS): New variables. (SFILES): Add SUBDIR_GCC_COMPILE_SRCS. (HFILES_NO_SRCDIR): Add compile.h. (COMMON_OBS): Add SUBDIR_GCC_COMPILE_OBS. (INIT_FILES): Add SUBDIR_GCC_COMPILE_SRCS. (compile.o, compile-c-types.o, compile-c-symbols.o) (compile-object-load.o, compile-object-run.o, compile-loc2c.o) (compile-c-support.o): New targets. gdb/doc/ChangeLog 2014-12-12 Phil Muldoon <pmuldoon@redhat.com> Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.texinfo (Altering): Update. (Compiling and Injecting Code): New node. gdb/testsuite/ChangeLog 2014-12-12 Phil Muldoon <pmuldoon@redhat.com> Jan Kratochvil <jan.kratochvil@redhat.com> Tom Tromey <tromey@redhat.com> * configure.ac: Add gdb.compile/. * configure: Regenerate. * gdb.compile/Makefile.in: New file. * gdb.compile/compile-ops.exp: New file. * gdb.compile/compile-ops.c: New file. * gdb.compile/compile-tls.c: New file. * gdb.compile/compile-tls.exp: New file. * gdb.compile/compile-constvar.S: New file. * gdb.compile/compile-constvar.c: New file. * gdb.compile/compile-mod.c: New file. * gdb.compile/compile-nodebug.c: New file. * gdb.compile/compile-setjmp-mod.c: New file. * gdb.compile/compile-setjmp.c: New file. * gdb.compile/compile-setjmp.exp: New file. * gdb.compile/compile-shlib.c: New file. * gdb.compile/compile.c: New file. * gdb.compile/compile.exp: New file. * lib/gdb.exp (skip_compile_feature_tests): New proc.
2014-05-14 22:35:45 +02:00
2014-12-12 Phil Muldoon <pmuldoon@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Tom Tromey <tromey@redhat.com>
* configure.ac: Add gdb.compile/.
* configure: Regenerate.
* gdb.compile/Makefile.in: New file.
* gdb.compile/compile-ops.exp: New file.
* gdb.compile/compile-ops.c: New file.
* gdb.compile/compile-tls.c: New file.
* gdb.compile/compile-tls.exp: New file.
* gdb.compile/compile-constvar.S: New file.
* gdb.compile/compile-constvar.c: New file.
* gdb.compile/compile-mod.c: New file.
* gdb.compile/compile-nodebug.c: New file.
* gdb.compile/compile-setjmp-mod.c: New file.
* gdb.compile/compile-setjmp.c: New file.
* gdb.compile/compile-setjmp.exp: New file.
* gdb.compile/compile-shlib.c: New file.
* gdb.compile/compile.c: New file.
* gdb.compile/compile.exp: New file.
* lib/gdb.exp (skip_compile_feature_tests): New proc.
add some missing ops to DWARF assembler This changes the DWARF assembler to allow comments in a location expression, and also adds support for a few new opcodes I needed. gdb/testsuite/ChangeLog 2014-12-12 Tom Tromey <tromey@redhat.com> * lib/dwarf.exp (_location): Ignore blank lines. Allow comments. Handle DW_OP_pick, DW_OP_skip, DW_OP_bra.
2014-05-14 21:46:37 +02:00
2014-12-12 Tom Tromey <tromey@redhat.com>
* lib/dwarf.exp (_location): Ignore blank lines. Allow comments.
Handle DW_OP_pick, DW_OP_skip, DW_OP_bra.
New python function gdb.lookup_objfile. gdb/ChangeLog: * NEWS: Mention gdb.lookup_objfile. * python/python.c (GdbMethods): Add lookup_objfile. * python/python-internal.h (gdbpy_lookup_objfile): Declare. * python/py-objfile.c: #include "symtab.h". (objfpy_build_id_ok, objfpy_build_id_matches): New functions. (objfpy_lookup_objfile_by_name): New function. (objfpy_lookup_objfile_by_build_id): New function. (gdbpy_lookup_objfile): New function. gdb/doc/ChangeLog: * python.texi (Objfiles In Python): Document gdb.lookup_objfile. gdb/testsuite/ChangeLog: * lib/gdb-python.exp (get_python_valueof): New function. * gdb.python/py-objfile.exp: Add tests for gdb.lookup_objfile.
2014-12-12 18:48:13 +01:00
2014-12-12 Doug Evans <dje@google.com>
* lib/gdb-python.exp (get_python_valueof): New function.
* gdb.python/py-objfile.exp: Add tests for gdb.lookup_objfile.
Provide completer for "info registers" Provide a new completion function for the argument of "info registers", "info all-registers", and the "lr" command in dbx mode. Without this patch the default symbol completer is used, which is more confusing than helpful. Also add a test for this new feature to "completion.exp": Determine the target's available set of registers/reggroups and compare this to the completion of "info registers ". For determining the available registers involve the new "maint print user-registers" command. gdb/ChangeLog: * completer.c: Include "target.h", "reggroups.h", and "user-regs.h". (reg_or_group_completer): New. * completer.h (reg_or_group_completer): Declare. * infcmd.c (_initialize_infcmd): Set reg_or_group_completer for the "info registers" and "info all-registers" commands and the dbx-mode "lr" command. gdb/testsuite/ChangeLog: * gdb.base/completion.exp: Add test for completion of "info registers ".
2014-12-12 17:11:22 +01:00
2014-12-12 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/completion.exp: Add test for completion of "info
registers ".
MIPS: Keep the ISA bit in compressed code addresses 1. Background information The MIPS architecture, as originally designed and implemented in mid-1980s has a uniform instruction word size that is 4 bytes, naturally aligned. As such all MIPS instructions are located at addresses that have their bits #1 and #0 set to zeroes, and any attempt to execute an instruction from an address that has any of the two bits set to one causes an address error exception. This may for example happen when a jump-register instruction is executed whose register value used as the jump target has any of these bits set. Then in mid 1990s LSI sought a way to improve code density for their TinyRISC family of MIPS cores and invented an alternatively encoded instruction set in a joint effort with MIPS Technologies (then a subsidiary of SGI). The new instruction set has been named the MIPS16 ASE (Application-Specific Extension) and uses a variable instruction word size, which is 2 bytes (as the name of the ASE suggests) for most, but there are a couple of exceptions that take 4 bytes, and then most of the 2-byte instructions can be treated with a 2-byte extension prefix to expand the range of the immediate operands used. As a result instructions are no longer 4-byte aligned, instead they are aligned to a multiple of 2. That left the bit #0 still unused for code references, be it for the standard MIPS (i.e. as originally invented) or for the MIPS16 instruction set, and based on that observation a clever trick was invented that on one hand allowed the processor to be seamlessly switched between the two instruction sets at any time at the run time while on the other avoided the introduction of any special control register to do that. So it is the bit #0 of the instruction address that was chosen as the selector and named the ISA bit. Any instruction executed at an even address is interpreted as a standard MIPS instruction (the address still has to have its bit #1 clear), any instruction executed at an odd address is interpreted as a MIPS16 instruction. To switch between modes ordinary jump instructions are used, such as used for function calls and returns, specifically the bit #0 of the source register used in jump-register instructions selects the execution (ISA) mode for the following piece of code to be interpreted in. Additionally new jump-immediate instructions were added that flipped the ISA bit to select the opposite mode upon execution. They were considered necessary to avoid the need to make register jumps in all cases as the original jump-immediate instructions provided no way to change the bit #0 at all. This was all important for cases where standard MIPS and MIPS16 code had to be mixed, either for compatibility with the existing binary code base or to access resources not reachable from MIPS16 code (the MIPS16 instruction set only provides access to general-purpose registers, and not for example floating-point unit registers or privileged coprocessor 0 registers) -- pieces of code in the opposite mode can be executed as ordinary subroutine calls. A similar approach has been more recently adopted for the MIPS16 replacement instruction set defined as the so called microMIPS ASE. This is another instruction set encoding introduced to the MIPS architecture. Just like the MIPS16 ASE, the microMIPS instruction set uses a variable-length encoding, where each instruction takes a multiple of 2 bytes. The ISA bit has been reused and for microMIPS-capable processors selects between the standard MIPS and the microMIPS mode instead. 2. Statement of the problem To put it shortly, MIPS16 and microMIPS code pointers used by GDB are different to these observed at the run time. This results in the same expressions being evaluated producing different results in GDB and in the program being debugged. Obviously it's the results obtained at the run time that are correct (they define how the program behaves) and therefore by definition the results obtained in GDB are incorrect. A bit longer description will record that obviously at the run time the ISA bit has to be set correctly (refer to background information above if unsure why so) or the program will not run as expected. This is recorded in all the executable file structures used at the run time: the dynamic symbol table (but not always the static one!), the GOT, and obviously in all the addresses embedded in code or data of the program itself, calculated by applying the appropriate relocations at the static link time. While a program is being processed by GDB, the ISA bit is stripped off from any code addresses, presumably to make them the same as the respective raw memory byte address used by the processor to access the instruction in the instruction fetch access cycle. This stripping is actually performed outside GDB proper, in BFD, specifically _bfd_mips_elf_symbol_processing (elfxx-mips.c, see the piece of code at the very bottom of that function, starting with an: "If this is an odd-valued function symbol, assume it's a MIPS16 or microMIPS one." comment). This function is also responsible for symbol table dumps made by `objdump' too, so you'll never see the ISA bit reported there by that tool, you need to use `readelf'. This is however unlike what is ever done at the run time, the ISA bit once present is never stripped off, for example a cast like this: (short *) main will not strip the ISA bit off and if the resulting pointer is intended to be used to access instructions as data, for example for software instruction decoding (like for fault recovery or emulation in a signal handler) or for self-modifying code then the bit still has to be stripped off by an explicit AND operation. This is probably best illustrated with a simple real program example. Let's consider the following simple program: $ cat foobar.c int __attribute__ ((mips16)) foo (void) { return 1; } int __attribute__ ((mips16)) bar (void) { return 2; } int __attribute__ ((nomips16)) foo32 (void) { return 3; } int (*foo32p) (void) = foo32; int (*foop) (void) = foo; int fooi = (int) foo; int main (void) { return foop (); } $ This is plain C with no odd tricks, except from the instruction mode attributes. They are not necessary to trigger this problem, I just put them here so that the program can be contained in a single source file and to make it obvious which function is MIPS16 code and which is not. Let's try it with Linux, so that everyone can repeat this experiment: $ mips-linux-gnu-gcc -mips16 -g -O2 -o foobar foobar.c $ Let's have a look at some interesting symbols: $ mips-linux-gnu-readelf -s foobar | egrep 'table|foo|bar' Symbol table '.dynsym' contains 7 entries: Symbol table '.symtab' contains 95 entries: 55: 00000000 0 FILE LOCAL DEFAULT ABS foobar.c 66: 0040068c 4 FUNC GLOBAL DEFAULT [MIPS16] 12 bar 68: 00410848 4 OBJECT GLOBAL DEFAULT 21 foo32p 70: 00410844 4 OBJECT GLOBAL DEFAULT 21 foop 78: 00400684 8 FUNC GLOBAL DEFAULT 12 foo32 80: 00400680 4 FUNC GLOBAL DEFAULT [MIPS16] 12 foo 88: 00410840 4 OBJECT GLOBAL DEFAULT 21 fooi $ Hmm, no sight of the ISA bit, but notice how foo and bar (but not foo32!) have been marked as MIPS16 functions (ELF symbol structure's `st_other' field is used for that). So let's try to run and poke at this program with GDB. I'll be using a native system for simplicity (I'll be using ellipses here and there to remove unrelated clutter): $ ./foobar $ echo $? 1 $ So far, so good. $ gdb ./foobar [...] (gdb) break main Breakpoint 1 at 0x400490: file foobar.c, line 23. (gdb) run Starting program: .../foobar Breakpoint 1, main () at foobar.c:23 23 return foop (); (gdb) Yay, it worked! OK, so let's poke at it: (gdb) print main $1 = {int (void)} 0x400490 <main> (gdb) print foo32 $2 = {int (void)} 0x400684 <foo32> (gdb) print foo32p $3 = (int (*)(void)) 0x400684 <foo32> (gdb) print bar $4 = {int (void)} 0x40068c <bar> (gdb) print foo $5 = {int (void)} 0x400680 <foo> (gdb) print foop $6 = (int (*)(void)) 0x400681 <foo> (gdb) A-ha! Here's the difference and finally the ISA bit! (gdb) print /x fooi $7 = 0x400681 (gdb) p/x $pc p/x $pc $8 = 0x400491 (gdb) And here as well... (gdb) advance foo foo () at foobar.c:4 4 } (gdb) disassemble Dump of assembler code for function foo: 0x00400680 <+0>: jr ra 0x00400682 <+2>: li v0,1 End of assembler dump. (gdb) finish Run till exit from #0 foo () at foobar.c:4 main () at foobar.c:24 24 } Value returned is $9 = 1 (gdb) continue Continuing. [Inferior 1 (process 14103) exited with code 01] (gdb) So let's be a bit inquisitive... (gdb) run Starting program: .../foobar Breakpoint 1, main () at foobar.c:23 23 return foop (); (gdb) Actually we do not like to run foo here at all. Let's run bar instead! (gdb) set foop = bar (gdb) print foop $10 = (int (*)(void)) 0x40068c <bar> (gdb) Hmm, no ISA bit. Is it going to work? (gdb) advance bar bar () at foobar.c:9 9 } (gdb) p/x $pc $11 = 0x40068c (gdb) disassemble Dump of assembler code for function bar: => 0x0040068c <+0>: jr ra 0x0040068e <+2>: li v0,2 End of assembler dump. (gdb) finish Run till exit from #0 bar () at foobar.c:9 Program received signal SIGILL, Illegal instruction. bar () at foobar.c:9 9 } (gdb) Oops! (gdb) p/x $pc $12 = 0x40068c (gdb) We're still there! (gdb) continue Continuing. Program terminated with signal SIGILL, Illegal instruction. The program no longer exists. (gdb) So let's try something else: (gdb) run Starting program: .../foobar Breakpoint 1, main () at foobar.c:23 23 return foop (); (gdb) set foop = foo (gdb) advance foo foo () at foobar.c:4 4 } (gdb) disassemble Dump of assembler code for function foo: => 0x00400680 <+0>: jr ra 0x00400682 <+2>: li v0,1 End of assembler dump. (gdb) finish Run till exit from #0 foo () at foobar.c:4 Program received signal SIGILL, Illegal instruction. foo () at foobar.c:4 4 } (gdb) continue Continuing. Program terminated with signal SIGILL, Illegal instruction. The program no longer exists. (gdb) The same problem! (gdb) run Starting program: /net/build2-lucid-cs/scratch/macro/mips-linux-fsf-gcc/isa-bit/foobar Breakpoint 1, main () at foobar.c:23 23 return foop (); (gdb) set foop = foo32 (gdb) advance foo32 foo32 () at foobar.c:14 14 } (gdb) disassemble Dump of assembler code for function foo32: => 0x00400684 <+0>: jr ra 0x00400688 <+4>: li v0,3 End of assembler dump. (gdb) finish Run till exit from #0 foo32 () at foobar.c:14 main () at foobar.c:24 24 } Value returned is $14 = 3 (gdb) continue Continuing. [Inferior 1 (process 14113) exited with code 03] (gdb) That did work though, so it's the ISA bit only! (gdb) quit Enough! That's the tip of the iceberg only though. So let's rebuild the executable with some dynamic symbols: $ mips-linux-gnu-gcc -mips16 -Wl,--export-dynamic -g -O2 -o foobar-dyn foobar.c $ mips-linux-gnu-readelf -s foobar-dyn | egrep 'table|foo|bar' Symbol table '.dynsym' contains 32 entries: 6: 004009cd 4 FUNC GLOBAL DEFAULT 12 bar 8: 00410b88 4 OBJECT GLOBAL DEFAULT 21 foo32p 9: 00410b84 4 OBJECT GLOBAL DEFAULT 21 foop 15: 004009c4 8 FUNC GLOBAL DEFAULT 12 foo32 17: 004009c1 4 FUNC GLOBAL DEFAULT 12 foo 25: 00410b80 4 OBJECT GLOBAL DEFAULT 21 fooi Symbol table '.symtab' contains 95 entries: 55: 00000000 0 FILE LOCAL DEFAULT ABS foobar.c 69: 004009cd 4 FUNC GLOBAL DEFAULT 12 bar 71: 00410b88 4 OBJECT GLOBAL DEFAULT 21 foo32p 72: 00410b84 4 OBJECT GLOBAL DEFAULT 21 foop 79: 004009c4 8 FUNC GLOBAL DEFAULT 12 foo32 81: 004009c1 4 FUNC GLOBAL DEFAULT 12 foo 89: 00410b80 4 OBJECT GLOBAL DEFAULT 21 fooi $ OK, now the ISA bit is there for a change, but the MIPS16 `st_other' attribute gone, hmm... What does `objdump' do then: $ mips-linux-gnu-objdump -Tt foobar-dyn | egrep 'SYMBOL|foo|bar' foobar-dyn: file format elf32-tradbigmips SYMBOL TABLE: 00000000 l df *ABS* 00000000 foobar.c 004009cc g F .text 00000004 0xf0 bar 00410b88 g O .data 00000004 foo32p 00410b84 g O .data 00000004 foop 004009c4 g F .text 00000008 foo32 004009c0 g F .text 00000004 0xf0 foo 00410b80 g O .data 00000004 fooi DYNAMIC SYMBOL TABLE: 004009cc g DF .text 00000004 Base 0xf0 bar 00410b88 g DO .data 00000004 Base foo32p 00410b84 g DO .data 00000004 Base foop 004009c4 g DF .text 00000008 Base foo32 004009c0 g DF .text 00000004 Base 0xf0 foo 00410b80 g DO .data 00000004 Base fooi $ Hmm, the attribute (0xf0, printed raw) is back, and the ISA bit gone again. Let's have a look at some DWARF-2 records GDB uses (I'll be stripping off a lot here for brevity) -- debug info: $ mips-linux-gnu-readelf -wi foobar Contents of the .debug_info section: [...] Compilation Unit @ offset 0x88: Length: 0xbb (32-bit) Version: 4 Abbrev Offset: 62 Pointer Size: 4 <0><93>: Abbrev Number: 1 (DW_TAG_compile_unit) <94> DW_AT_producer : (indirect string, offset: 0x19e): GNU C 4.8.0 20120513 (experimental) -meb -mips16 -march=mips32r2 -mhard-float -mllsc -mplt -mno-synci -mno-shared -mabi=32 -g -O2 <98> DW_AT_language : 1 (ANSI C) <99> DW_AT_name : (indirect string, offset: 0x190): foobar.c <9d> DW_AT_comp_dir : (indirect string, offset: 0x225): [...] <a1> DW_AT_ranges : 0x0 <a5> DW_AT_low_pc : 0x0 <a9> DW_AT_stmt_list : 0x27 <1><ad>: Abbrev Number: 2 (DW_TAG_subprogram) <ae> DW_AT_external : 1 <ae> DW_AT_name : foo <b2> DW_AT_decl_file : 1 <b3> DW_AT_decl_line : 1 <b4> DW_AT_prototyped : 1 <b4> DW_AT_type : <0xc2> <b8> DW_AT_low_pc : 0x400680 <bc> DW_AT_high_pc : 0x400684 <c0> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <c2> DW_AT_GNU_all_call_sites: 1 <1><c2>: Abbrev Number: 3 (DW_TAG_base_type) <c3> DW_AT_byte_size : 4 <c4> DW_AT_encoding : 5 (signed) <c5> DW_AT_name : int <1><c9>: Abbrev Number: 4 (DW_TAG_subprogram) <ca> DW_AT_external : 1 <ca> DW_AT_name : (indirect string, offset: 0x18a): foo32 <ce> DW_AT_decl_file : 1 <cf> DW_AT_decl_line : 11 <d0> DW_AT_prototyped : 1 <d0> DW_AT_type : <0xc2> <d4> DW_AT_low_pc : 0x400684 <d8> DW_AT_high_pc : 0x40068c <dc> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <de> DW_AT_GNU_all_call_sites: 1 <1><de>: Abbrev Number: 2 (DW_TAG_subprogram) <df> DW_AT_external : 1 <df> DW_AT_name : bar <e3> DW_AT_decl_file : 1 <e4> DW_AT_decl_line : 6 <e5> DW_AT_prototyped : 1 <e5> DW_AT_type : <0xc2> <e9> DW_AT_low_pc : 0x40068c <ed> DW_AT_high_pc : 0x400690 <f1> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <f3> DW_AT_GNU_all_call_sites: 1 <1><f3>: Abbrev Number: 5 (DW_TAG_subprogram) <f4> DW_AT_external : 1 <f4> DW_AT_name : (indirect string, offset: 0x199): main <f8> DW_AT_decl_file : 1 <f9> DW_AT_decl_line : 21 <fa> DW_AT_prototyped : 1 <fa> DW_AT_type : <0xc2> <fe> DW_AT_low_pc : 0x400490 <102> DW_AT_high_pc : 0x4004a4 <106> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <108> DW_AT_GNU_all_tail_call_sites: 1 [...] $ -- no sign of the ISA bit anywhere -- frame info: $ mips-linux-gnu-readelf -wf foobar [...] Contents of the .debug_frame section: 00000000 0000000c ffffffff CIE Version: 1 Augmentation: "" Code alignment factor: 1 Data alignment factor: -4 Return address column: 31 DW_CFA_def_cfa_register: r29 DW_CFA_nop 00000010 0000000c 00000000 FDE cie=00000000 pc=00400680..00400684 00000020 0000000c 00000000 FDE cie=00000000 pc=00400684..0040068c 00000030 0000000c 00000000 FDE cie=00000000 pc=0040068c..00400690 00000040 00000018 00000000 FDE cie=00000000 pc=00400490..004004a4 DW_CFA_advance_loc: 6 to 00400496 DW_CFA_def_cfa_offset: 32 DW_CFA_offset: r31 at cfa-4 DW_CFA_advance_loc: 6 to 0040049c DW_CFA_restore: r31 DW_CFA_def_cfa_offset: 0 DW_CFA_nop DW_CFA_nop DW_CFA_nop [...] $ -- no sign of the ISA bit anywhere -- range info (GDB doesn't use arange): $ mips-linux-gnu-readelf -wR foobar Contents of the .debug_ranges section: Offset Begin End 00000000 00400680 00400690 00000000 00400490 004004a4 00000000 <End of list> $ -- no sign of the ISA bit anywhere -- line info: $ mips-linux-gnu-readelf -wl foobar Raw dump of debug contents of section .debug_line: [...] Offset: 0x27 Length: 78 DWARF Version: 2 Prologue Length: 31 Minimum Instruction Length: 1 Initial value of 'is_stmt': 1 Line Base: -5 Line Range: 14 Opcode Base: 13 Opcodes: Opcode 1 has 0 args Opcode 2 has 1 args Opcode 3 has 1 args Opcode 4 has 1 args Opcode 5 has 1 args Opcode 6 has 0 args Opcode 7 has 0 args Opcode 8 has 0 args Opcode 9 has 1 args Opcode 10 has 0 args Opcode 11 has 0 args Opcode 12 has 1 args The Directory Table is empty. The File Name Table: Entry Dir Time Size Name 1 0 0 0 foobar.c Line Number Statements: Extended opcode 2: set Address to 0x400681 Special opcode 6: advance Address by 0 to 0x400681 and Line by 1 to 2 Special opcode 7: advance Address by 0 to 0x400681 and Line by 2 to 4 Special opcode 55: advance Address by 3 to 0x400684 and Line by 8 to 12 Special opcode 7: advance Address by 0 to 0x400684 and Line by 2 to 14 Advance Line by -7 to 7 Special opcode 131: advance Address by 9 to 0x40068d and Line by 0 to 7 Special opcode 7: advance Address by 0 to 0x40068d and Line by 2 to 9 Advance PC by 3 to 0x400690 Extended opcode 1: End of Sequence Extended opcode 2: set Address to 0x400491 Advance Line by 21 to 22 Copy Special opcode 6: advance Address by 0 to 0x400491 and Line by 1 to 23 Special opcode 60: advance Address by 4 to 0x400495 and Line by -1 to 22 Special opcode 34: advance Address by 2 to 0x400497 and Line by 1 to 23 Special opcode 62: advance Address by 4 to 0x40049b and Line by 1 to 24 Special opcode 32: advance Address by 2 to 0x40049d and Line by -1 to 23 Special opcode 6: advance Address by 0 to 0x40049d and Line by 1 to 24 Advance PC by 7 to 0x4004a4 Extended opcode 1: End of Sequence [...] -- a-ha, the ISA bit is there! However it's not always right for some reason, I don't have a small test case to show it, but here's an excerpt from MIPS16 libc, a prologue of a function: 00019630 <__libc_init_first>: 19630: e8a0 jrc ra 19632: 6500 nop 00019634 <_init>: 19634: f000 6a11 li v0,17 19638: f7d8 0b08 la v1,15e00 <_DYNAMIC+0x15c54> 1963c: f400 3240 sll v0,16 19640: e269 addu v0,v1 19642: 659a move gp,v0 19644: 64f6 save 48,ra,s0-s1 19646: 671c move s0,gp 19648: d204 sw v0,16(sp) 1964a: f352 984c lw v0,-27828(s0) 1964e: 6724 move s1,a0 and the corresponding DWARF-2 line info: Line Number Statements: Extended opcode 2: set Address to 0x19631 Advance Line by 44 to 45 Copy Special opcode 8: advance Address by 0 to 0x19631 and Line by 3 to 48 Special opcode 66: advance Address by 4 to 0x19635 and Line by 5 to 53 Advance PC by constant 17 to 0x19646 Special opcode 25: advance Address by 1 to 0x19647 and Line by 6 to 59 Advance Line by -6 to 53 Special opcode 33: advance Address by 2 to 0x19649 and Line by 0 to 53 Special opcode 39: advance Address by 2 to 0x1964b and Line by 6 to 59 Advance Line by -6 to 53 Special opcode 61: advance Address by 4 to 0x1964f and Line by 0 to 53 -- see that "Advance PC by constant 17" there? It clears the ISA bit, however code at 0x19646 is not standard MIPS code at all. For some reason the constant is always 17, I've never seen DW_LNS_const_add_pc used with any other value -- is that a binutils bug or what? 3. Solution: I think we should retain the value of the ISA bit in code references, that is effectively treat them as cookies as they indeed are (although trivially calculated) rather than raw memory byte addresses. In a perfect world both the static symbol table and the respective DWARF-2 records should be fixed to include the ISA bit in all the cases. I think however that this is infeasible. All the uses of `_bfd_mips_elf_symbol_processing' can not necessarily be tracked down. This function is used by `elf_slurp_symbol_table' that in turn is used by `bfd_canonicalize_symtab' and `bfd_canonicalize_dynamic_symtab', which are public interfaces. Similarly DWARF-2 records are used outside GDB, one notable if a bit questionable is the exception unwinder (libgcc/unwind-dw2.c) -- I have identified at least bits in `execute_cfa_program' and `uw_frame_state_for', both around the calls to `_Unwind_IsSignalFrame', that would need an update as they effectively flip the ISA bit freely; see also the comment about MASK_RETURN_ADDR in gcc/config/mips/mips.h. But there may be more places. Any change in how DWARF-2 records are produced would require an update there and would cause compatibility problems with libgcc.a binaries already distributed; given that this is a static library a complex change involving function renames would likely be required. I propose therefore to accept the existing inconsistencies and deal with them entirely within GDB. I have figured out that the ISA bit lost in various places can still be recovered as long as we have symbol information -- that'll have the `st_other' attribute correctly set to one of standard MIPS/MIPS16/microMIPS encoding. Here's the resulting change. It adds a couple of new `gdbarch' hooks, one to update symbol information with the ISA bit lost in `_bfd_mips_elf_symbol_processing', and two other ones to adjust DWARF-2 records as they're processed. The ISA bit is set in each address handled according to information retrieved from the symbol table for the symbol spanning the address if any; limits are adjusted based on the address they point to related to the respective base address. Additionally minimal symbol information has to be adjusted accordingly in its gdbarch hook. With these changes in place some complications with ISA bit juggling in the PC that never fully worked can be removed from the MIPS backend. Conversely, the generic dynamic linker event special breakpoint symbol handler has to be updated to call the minimal symbol gdbarch hook to record that the symbol is a MIPS16 or microMIPS address if applicable or the breakpoint will be set at the wrong address and either fail to work or cause SIGTRAPs (this is because the symbol is handled early on and bypasses regular symbol processing). 4. Results obtained The change fixes the example above -- to repeat only the crucial steps: (gdb) break main Breakpoint 1 at 0x400491: file foobar.c, line 23. (gdb) run Starting program: .../foobar Breakpoint 1, main () at foobar.c:23 23 return foop (); (gdb) print foo $1 = {int (void)} 0x400681 <foo> (gdb) set foop = bar (gdb) advance bar bar () at foobar.c:9 9 } (gdb) disassemble Dump of assembler code for function bar: => 0x0040068d <+0>: jr ra 0x0040068f <+2>: li v0,2 End of assembler dump. (gdb) finish Run till exit from #0 bar () at foobar.c:9 main () at foobar.c:24 24 } Value returned is $2 = 2 (gdb) continue Continuing. [Inferior 1 (process 14128) exited with code 02] (gdb) -- excellent! The change removes about 90 failures per MIPS16 multilib in mips-sde-elf testing too, results for MIPS16 are now similar to that for standard MIPS; microMIPS results are a bit worse because of host-I/O problems in QEMU used instead of MIPSsim for microMIPS testing only: === gdb Summary === # of expected passes 14299 # of unexpected failures 187 # of expected failures 56 # of known failures 58 # of unresolved testcases 11 # of untested testcases 52 # of unsupported tests 174 MIPS16: === gdb Summary === # of expected passes 14298 # of unexpected failures 187 # of unexpected successes 2 # of expected failures 54 # of known failures 58 # of unresolved testcases 12 # of untested testcases 52 # of unsupported tests 174 microMIPS: === gdb Summary === # of expected passes 14149 # of unexpected failures 201 # of unexpected successes 2 # of expected failures 54 # of known failures 58 # of unresolved testcases 7 # of untested testcases 53 # of unsupported tests 175 2014-12-12 Maciej W. Rozycki <macro@codesourcery.com> Maciej W. Rozycki <macro@mips.com> Pedro Alves <pedro@codesourcery.com> gdb/ * gdbarch.sh (elf_make_msymbol_special): Change type to `F', remove `predefault' and `invalid_p' initializers. (make_symbol_special): New architecture method. (adjust_dwarf2_addr, adjust_dwarf2_line): Likewise. (objfile, symbol): New declarations. * arch-utils.h (default_elf_make_msymbol_special): Remove prototype. (default_make_symbol_special): New prototype. (default_adjust_dwarf2_addr): Likewise. (default_adjust_dwarf2_line): Likewise. * mips-tdep.h (mips_unmake_compact_addr): New prototype. * arch-utils.c (default_elf_make_msymbol_special): Remove function. (default_make_symbol_special): New function. (default_adjust_dwarf2_addr): Likewise. (default_adjust_dwarf2_line): Likewise. * dwarf2-frame.c (decode_frame_entry_1): Call `gdbarch_adjust_dwarf2_addr'. * dwarf2loc.c (dwarf2_find_location_expression): Likewise. * dwarf2read.c (create_addrmap_from_index): Likewise. (process_psymtab_comp_unit_reader): Likewise. (add_partial_symbol): Likewise. (add_partial_subprogram): Likewise. (process_full_comp_unit): Likewise. (read_file_scope): Likewise. (read_func_scope): Likewise. Call `gdbarch_make_symbol_special'. (read_lexical_block_scope): Call `gdbarch_adjust_dwarf2_addr'. (read_call_site_scope): Likewise. (dwarf2_ranges_read): Likewise. (dwarf2_record_block_ranges): Likewise. (read_attribute_value): Likewise. (dwarf_decode_lines_1): Call `gdbarch_adjust_dwarf2_line'. (new_symbol_full): Call `gdbarch_adjust_dwarf2_addr'. * elfread.c (elf_symtab_read): Don't call `gdbarch_elf_make_msymbol_special' if unset. * mips-linux-tdep.c (micromips_linux_sigframe_validate): Strip the ISA bit from the PC. * mips-tdep.c (mips_unmake_compact_addr): New function. (mips_elf_make_msymbol_special): Set the ISA bit in the symbol's address appropriately. (mips_make_symbol_special): New function. (mips_pc_is_mips): Set the ISA bit before symbol lookup. (mips_pc_is_mips16): Likewise. (mips_pc_is_micromips): Likewise. (mips_pc_isa): Likewise. (mips_adjust_dwarf2_addr): New function. (mips_adjust_dwarf2_line): Likewise. (mips_read_pc, mips_unwind_pc): Keep the ISA bit. (mips_addr_bits_remove): Likewise. (mips_skip_trampoline_code): Likewise. (mips_write_pc): Don't set the ISA bit. (mips_eabi_push_dummy_call): Likewise. (mips_o64_push_dummy_call): Likewise. (mips_gdbarch_init): Install `mips_make_symbol_special', `mips_adjust_dwarf2_addr' and `mips_adjust_dwarf2_line' gdbarch handlers. * solib.c (gdb_bfd_lookup_symbol_from_symtab): Get target-specific symbol address adjustments. * gdbarch.h: Regenerate. * gdbarch.c: Regenerate. 2014-12-12 Maciej W. Rozycki <macro@codesourcery.com> gdb/testsuite/ * gdb.base/func-ptrs.c: New file. * gdb.base/func-ptrs.exp: New file.
2014-12-12 14:31:53 +01:00
2014-12-12 Maciej W. Rozycki <macro@codesourcery.com>
* gdb.base/func-ptrs.c: New file.
* gdb.base/func-ptrs.exp: New file.
Only leave dprintf inserted if it is marked as persistent (PR breakpoints/17012) On Linux native, if dprintfs are inserted when detaching, they are left in the inferior which causes it to crash from a SIGTRAP. It also happens with dprintfs on remote targets, when set disconnected-dprintf is off. The rationale of the line modified by the patch was to leave dprintfs inserted in order to support disconnected dprintfs. However, not all dprintfs are persistent. Also, there's no reason other kinds of breakpoints can't be persistent either. So this replaces the bp_dprintf check with a check on whether the location is persistent. bl->target_info.persist will be 1 only if disconnected-dprintf is on and we are debugging a remote target. On native, it will always be 0, regardless of the value of disconnected-dprintf. This makes sense, since disconnected dprintfs are not supported by the native target. One issue about the test is that it does not pass when using --target_board=native-extended-gdbserver, partly due to bug 17302 [1]. One quick hack I tried for this was to add a useless "next" between the call to getpid() and detach, which avoids the bug. There is still one case where the test fails, and that is with: - breakpoint always-inserted on - dprintf-style agent - disconnected-dprintf on What happens is that my detach does not actually detach the process, because some persistent commands (the disconnected dprintf) is present. However since gdbserver is ran with --once, when gdb disconnects, gdbserver goes down and takes with it all the processes it spawned and that are still under its control (which includes my test process). When the test checks if the test process is still alive, it obvisouly fails. Investigating about that led me to ask a question on the ML [2] about the behavior of detach. Until the remote case is sorted out, the problematic test is marked as KFAIL. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=17302 [2] https://sourceware.org/ml/gdb/2014-08/msg00115.html gdb/Changelog: PR breakpoints/17012 * breakpoint.c (remove_breakpoints_pid): Skip removing breakpoint if it is marked as persistent. gdb/testsuite/ChangeLog: PR breakpoints/17012 * gdb.base/dprintf-detach.c: New file. * gdb.base/dprintf-detach.exp: New file.
2014-12-10 22:10:05 +01:00
2014-12-10 Simon Marchi <simon.marchi@ericsson.com>
PR breakpoints/17012
* gdb.base/dprintf-detach.c: New file.
* gdb.base/dprintf-detach.exp: New file.
Introduce target_is_gdbserver This patch introduces a function in gdbserver-support.exp to find out whether the current target is GDBserver. The code was inspired from gdb.trace/qtro.exp, so it replaces the code there by a call to the new function. gdb/testsuite/ChangeLog: * gdb.trace/qtro.exp: Replace gdbserver detection code by... * lib/gdb.exp (target_is_gdbserver): New procedure.
2014-12-10 21:12:17 +01:00
2014-12-10 Simon Marchi <simon.marchi@ericsson.com>
* gdb.trace/qtro.exp: Replace gdbserver detection code by...
* lib/gdb.exp (target_is_gdbserver): New procedure.
New "owner" attribute for gdb.Objfile. gdb/ChangeLog: * NEWS: Mention gdb.Objfile.owner. * python/py-objfile.c (objfpy_get_owner): New function. (objfile_getset): Add "owner". gdb/doc/ChangeLog: * python.texi (Objfiles In Python): Document Objfile.owner. gdb/testsuite/ChangeLog: * gdb.python/py-objfile.exp: Add tests for objfile.owner.
2014-12-08 17:50:48 +01:00
2014-12-08 Doug Evans <dje@google.com>
* gdb.python/py-objfile.exp: Add tests for objfile.owner.
Fix parallel testing issues in gdb.guile tests Some gdb.guile tests such as scm-error.exp copies .scm file to ${subdir}/, how ${subdir} doesn't exist in parallel testing (outputs/${subdir} exists). $ make -j3 check TESTS='gdb.guile/scm-section-script.exp gdb.guile/scm-error.exp gdb.guile/scm-frame-args.exp' ERROR: remote_download to host of ../../../../git/gdb/testsuite/gdb.guile/scm-section-script.scm to gdb.guile/t-scm-section-script.scm: cp: cannot create regular file 'gdb.guile/t-scm-section-script.scm': No such file or directory ERROR: remote_download to host of ../../../../git/gdb/testsuite/gdb.guile/scm-frame-args.scm to gdb.guile/t-scm-frame-args.scm: cp: cannot create regular file 'gdb.guile/t-scm-frame-args.scm': No such file or directory ERROR: remote_download to host of ../../../../git/gdb/testsuite/gdb.guile/scm-error-1.scm to gdb.guile/t-scm-error-1.scm: cp: cannot create regular file 'gdb.guile/t-scm-error-1.scm': No such file or directory This patch is to remove the third argument of gdb_remote_download, so that gdb_remote_download can return the correct location. Further, these tests only copy .scm files to a different name. From what I can tell from the comments, looks we do this to avoid clobbering file in in-tree build. However, if source and dest of copy are the same, the operation is no-op. So it makes few sense to copy .scm files to a different names. I tried in-tree build/test with this patch, test result isn't changed. gdb/testsuite: 2014-12-05 Yao Qi <yao@codesourcery.com> * gdb.guile/scm-error.exp: Remove the third argument to gdb_remote_download. * gdb.guile/scm-frame-args.exp: Likewise. * gdb.guile/scm-section-script.exp: Likewise.
2014-11-29 09:58:34 +01:00
2014-12-05 Yao Qi <yao@codesourcery.com>
* gdb.guile/scm-error.exp: Remove the third argument to
gdb_remote_download.
* gdb.guile/scm-frame-args.exp: Likewise.
* gdb.guile/scm-section-script.exp: Likewise.
Use standard_testfile in i386-bp_permanent.exp This patch is to use standard_testfile in i386-bp_permanent.exp to replace existing setting to testfile, srcfile and binfile. So it fixes a problem in i386-bp_permanent.exp in parallel testing. $ make -j3 check TESTS='gdb.guile/scm-section-script.exp gdb.arch/i386-bp_permanent.exp' .... gdb compile failed, /usr/bin/ld: cannot open output file x86/gdb/testsuite/gdb.arch/i386-bp_permanent: No such file or directory collect2: error: ld returned 1 exit status gdb/testsuite: 2014-12-05 Yao Qi <yao@codesourcery.com> * gdb.arch/i386-bp_permanent.exp: Use standard_testfile.
2014-11-29 10:24:07 +01:00
2014-12-05 Yao Qi <yao@codesourcery.com>
* gdb.arch/i386-bp_permanent.exp: Use standard_testfile.
New python method gdb.Objfile.add_separate_debug_file. gdb/ChangeLog: * NEWS: Mention gdb.Objfile.add_separate_debug_file. * python/py-objfile.c (objfpy_add_separate_debug_file): New function. (objfile_getset): Add "add_separate_debug_file". gdb/doc/ChangeLog: * python.texi (Objfiles In Python): Document Objfile.add_separate_debug_file. gdb/testsuite/ChangeLog: * gdb.python/py-objfile.exp: Add tests for objfile.add_separate_debug_file.
2014-12-04 21:01:22 +01:00
2014-12-04 Doug Evans <dje@google.com>
* gdb.python/py-objfile.exp: Add tests for
objfile.add_separate_debug_file.
New python attribute gdb.Objfile.build_id. gdb/ChangeLog: * NEWS: Mention gdb.Objfile.build_id. * build-id.c (build_id_bfd_get): Make non-static. * build-id.h (build_id_bfd_get): Add declaration. * python/py-objfile.c: #include "build-id.h", "elf-bfd.h". (OBJFPY_REQUIRE_VALID): New macro. (objfpy_get_build_id): New function. (objfile_getset): Add "build_id". * utils.c (make_hex_string): New function. * utils.h (make_hex_string): Add declaration. gdb/doc/ChangeLog: * python.texi (Objfiles In Python): Document Objfile.build_id. gdb/testsuite/ChangeLog: * lib/gdb.exp (get_build_id): New function. (build_id_debug_filename_get): Rewrite to use it. * gdb.python/py-objfile.exp: Add test for objfile.build_id.
2014-12-04 20:32:24 +01:00
2014-12-04 Doug Evans <dje@google.com>
* lib/gdb.exp (get_build_id): New function.
(build_id_debug_filename_get): Rewrite to use it.
* gdb.python/py-objfile.exp: Add test for objfile.build_id.
Correct invalid assumptions made by (mostly) DWARF-2 tests Address issues triggered by the MIPS ISA bit handling change, usually in tests that make artificial DWARF-2 records: * gdb.cp/expand-psymtabs-cxx.exp -- this test is debugging an object file and assuming addresses will be 0; with the ISA bit set code addresses are 1 instead: (gdb) PASS: gdb.cp/expand-psymtabs-cxx.exp: set language c++ p 'method(long)' $1 = {void (long)} 0x1 <method(long)> (gdb) FAIL: gdb.cp/expand-psymtabs-cxx.exp: before expand p method $2 = {void (long)} 0x1 <method(long)> (gdb) FAIL: gdb.cp/expand-psymtabs-cxx.exp: force expand p 'method(long)' $3 = {void (long)} 0x1 <method(long)> (gdb) FAIL: gdb.cp/expand-psymtabs-cxx.exp: after expand Fix by matching any hex number, there's no value AFAICT for the test in matching 0 exactly, and I suppose the method's offset within section can be non-zero for some other reasons on other targets too. * gdb.cp/nsalias.exp -- this assumes instructions can be aligned arbitrarily and places code labels at odd addreses, setting the ISA bit and wreaking havoc: (gdb) PASS: gdb.cp/nsalias.exp: print outer::inner::innermost::x list outer::inner::innermost::foo Function "outer::inner::innermost::foo" not defined. (gdb) FAIL: gdb.cp/nsalias.exp: list outer::inner::innermost::foo break *outer::inner::innermost::foo No symbol "foo" in namespace "outer::inner::innermost". (gdb) FAIL: gdb.cp/nsalias.exp: setting breakpoint at *outer::inner::innermost::foo delete $bpnum No breakpoint number 6. (gdb) FAIL: gdb.cp/nsalias.exp: (outer::inner::innermost): delete $bpnum -- etc., etc... Fix by aligning labels to 4; required by many processors. * gdb.dwarf2/dw2-canonicalize-type.exp, gdb.dwarf2/dw2-empty-pc-range.exp, gdb.dwarf2/pr11465.exp -- these assume an instruction and consequently a function can take as little as 1 byte, which makes it impossible to look up a code symbol by an address with the ISA bit set as the address is already beyond the end of the function: (gdb) ptype f No symbol "f" in current context. (gdb) FAIL: gdb.dwarf2/dw2-canonicalize-type.exp: ptype f (gdb) PASS: gdb.dwarf2/dw2-empty-pc-range.exp: empty range before CU load ptype realrange No symbol "realrange" in current context. (gdb) FAIL: gdb.dwarf2/dw2-empty-pc-range.exp: valid range after CU load (gdb) p N::c.C Cannot take address of method C. (gdb) FAIL: gdb.dwarf2/pr11465.exp: p N::c.C -- fix by increasing the size of the function to 4 (perhaps code in gdb/mips-tdep.c could look up code symbols up to twice, with and failing that without the ISA bit set, but it seems wrong to me to implement specific handling for invalid code just to satisfy test cases that assume too much about the target). * gdb.dwarf2/dw2-case-insensitive.exp -- an artificial code label is created, but does not work because data (a `.align' pseudo-op in this case) follows and as a result the label has no MIPS16 or microMIPS annotation in the symbol table: (gdb) PASS: gdb.dwarf2/dw2-case-insensitive.exp: set case-sensitive off info functions fUnC_lang All functions matching regular expression "fUnC_lang": File file1.txt: foo FUNC_lang(void); Non-debugging symbols: 0x004006e0 FUNC_lang_start (gdb) FAIL: gdb.dwarf2/dw2-case-insensitive.exp: regexp case-sensitive off -- fix by adding a `.insn' pseudo-op on MIPS targets; the pseudo-op marks data as instructions. * gdb.dwarf2/dw2-stack-boundary.exp -- the test case enables complaints and assumes none will be issued beyond ones explicitly arranged by the test case, however overlapping sections are noticed while minimal symbols are looked up by `mips_adjust_dwarf2_addr' in DWARF-2 record processing: (gdb) set complaints 100 (gdb) PASS: gdb.dwarf2/dw2-stack-boundary.exp: set complaints 100 file ./dw2-stack-boundary Reading symbols from ./dw2-stack-boundary...location description stack underflow...location description stack overflow...unexpected overlap between: (A) section `.reginfo' from `.../gdb.dwarf2/dw2-stack-boundary' [0x0, 0x18) (B) section `*COM*' from `.../gdb.dwarf2/dw2-stack-boundary' [0x0, 0x0). Will ignore section B...unexpected overlap between: (A) section `.reginfo' from `.../gdb.dwarf2/dw2-stack-boundary' [0x0, 0x18) (B) section `*UND*' from `.../gdb.dwarf2/dw2-stack-boundary' [0x0, 0x0). Will ignore section B...unexpected overlap between: (A) section `.reginfo' from `.../gdb.dwarf2/dw2-stack-boundary' [0x0, 0x18) (B) section `*ABS*' from `.../gdb.dwarf2/dw2-stack-boundary' [0x0, 0x0). Will ignore section B...done. (gdb) FAIL: gdb.dwarf2/dw2-stack-boundary.exp: check partial symtab errors -- fix by ignoring any extra noise as long as what we look for is found. * gdb.cp/expand-psymtabs-cxx.exp: Accept any address of `method(long)', not just 0x0. * gdb.cp/nsalias.exp: Align code labels to 4. * gdb.dwarf2/dw2-canonicalize-type.S (main): Expand to 4-bytes. * gdb.dwarf2/dw2-empty-pc-range.S (main): Likewise. * gdb.dwarf2/pr11465.S (_ZN1N1cE): Likewise. * gdb.dwarf2/dw2-case-insensitive.c (START_INSNS): New macro. (cu_text_start, FUNC_lang_start): Use `START_INSNS'. * gdb.dwarf2/dw2-stack-boundary.exp: Accept noise in complaints.
2014-12-04 01:06:10 +01:00
2014-12-04 Maciej W. Rozycki <macro@codesourcery.com>
* gdb.cp/expand-psymtabs-cxx.exp: Accept any address of
`method(long)', not just 0x0.
* gdb.cp/nsalias.exp: Align code labels to 4.
* gdb.dwarf2/dw2-canonicalize-type.S (main): Expand to 4-bytes.
* gdb.dwarf2/dw2-empty-pc-range.S (main): Likewise.
* gdb.dwarf2/pr11465.S (_ZN1N1cE): Likewise.
* gdb.dwarf2/dw2-case-insensitive.c (START_INSNS): New macro.
(cu_text_start, FUNC_lang_start): Use `START_INSNS'.
* gdb.dwarf2/dw2-stack-boundary.exp: Accept noise in complaints.
PR symtab/17602 gdb/ChangeLog: PR symtab/17602 * linespec.c (iterate_name_matcher): Fix arguments to symbol_name_cmp. gdb/testsuite/ChangeLog: PR symtab/17602 * gdb.cp/anon-ns.cc: Move guts of this file to ... * gdb.cp/anon-ns-2.cc: ... here. New file. * gdb.cp/anon-ns.exp: Update.
2014-12-03 01:40:38 +01:00
2014-12-02 Doug Evans <dje@google.com>
fix spelling of anon-ns2.cc in earlier entry, and whitespace in same entry
2015-01-03 21:35:41 +01:00
PR symtab/17602
PR symtab/17602 gdb/ChangeLog: PR symtab/17602 * linespec.c (iterate_name_matcher): Fix arguments to symbol_name_cmp. gdb/testsuite/ChangeLog: PR symtab/17602 * gdb.cp/anon-ns.cc: Move guts of this file to ... * gdb.cp/anon-ns-2.cc: ... here. New file. * gdb.cp/anon-ns.exp: Update.
2014-12-03 01:40:38 +01:00
* gdb.cp/anon-ns.cc: Move guts of this file to ...
fix spelling of anon-ns2.cc in earlier entry, and whitespace in same entry
2015-01-03 21:35:41 +01:00
* gdb.cp/anon-ns2.cc: ... here. New file.
PR symtab/17602 gdb/ChangeLog: PR symtab/17602 * linespec.c (iterate_name_matcher): Fix arguments to symbol_name_cmp. gdb/testsuite/ChangeLog: PR symtab/17602 * gdb.cp/anon-ns.cc: Move guts of this file to ... * gdb.cp/anon-ns-2.cc: ... here. New file. * gdb.cp/anon-ns.exp: Update.
2014-12-03 01:40:38 +01:00
* gdb.cp/anon-ns.exp: Update.
New python events: inferior call, register/memory changed. gdb/ChangeLog: * NEWS: Mention new Python events. * Makefile.in (SUBDIR_PYTHON_OBS): Add py-infevents.o. (SUBDIR_PYTHON_SRCS): Add py-infevents.c. (py-infevents.o): New rule. * doc/observer.texi (inferior_call_pre, inferior_call_post) (memory_changed, register_changed): New observers. * infcall.c (call_function_by_hand): Notify observer before and after inferior call. * python/py-event.h (inferior_call_kind): New enum. (emit_inferior_call_event): New prototype. (emit_register_changed_event): New prototype. (emit_memory_changed_event): New prototype. * python/py-events.h (events_object): New registries inferior_call, memory_changed and register_changed. * python/py-evts.c (gdbpy_initialize_py_events): Add the inferior_call, memory_changed and register_changed registries. * python/py-infevents.c: New. * python/py-inferior.c (python_on_inferior_call_pre) (python_on_inferior_call_post, python_on_register_change) (python_on_memory_change): New functions. (gdbpy_initialize_inferior): Attach python handler to new observers. * python/py-infthread.c(gdbpy_create_ptid_object): New. (thpy_get_ptid) Use gdbpy_create_ptid_object. * python/python-internal.h: (gdbpy_create_ptid_object) (gdbpy_initialize_inferior_call_pre_event) (gdbpy_initialize_inferior_call_post_event) (gdbpy_initialize_register_changed_event) (gdbpy_initialize_memory_changed_event): New prototypes. * python/python.c (_initialize_python): Initialize new events. * valops.c (value_assign): Notify register_changed observer. gdb/doc/ChangeLog: * python.texi (Events In Python): Document new events InferiorCallPreEvent, InferiorCallPostEvent, MemoryChangedEvent and RegisterChangedEvent. gdb/testsuite/ChangeLog: * gdb.python/py-events.py (inferior_call_handler): New. (register_changed_handler, memory_changed_handler): New. (test_events.invoke): Register new handlers. * gdb.python/py-events.exp: Add tests for inferior call, memory_changed and register_changed events.
2014-12-02 20:15:29 +01:00
2014-12-02 Nick Bull <nicholaspbull@gmail.com>
* gdb.python/py-events.py (inferior_call_handler): New.
(register_changed_handler, memory_changed_handler): New.
(test_events.invoke): Register new handlers.
* gdb.python/py-events.exp: Add tests for inferior call,
memory_changed and register_changed events.
execl-update-breakpoints.exp: Move whole segment instead of .text section The test case builds two copies of the program, one with the compile option "ldflags=-Wl,-Ttext=0x1000000" and the other with the address changed to 0x2000000. However, when linking with ld.bfd, the resulting executables crash early in ld.so on S390 and i386. Analysis of the crash: The default linker script establishes a certain order of loadable sections, and the option "-Ttext" effectively splits these into an "unaffected" lot (everything before .text) and an "affected" lot. The affected lot is placed at the given address, whereas the unaffected lot stays at its default address. The unaffected lot starts at an aligned address plus Elf header sizes, which is good if it is the first LOAD segment (like on AMD64). But if the affected lot comes first instead (like on S390 and i386), the PHDR doesn't fit there and is placed *outside* any LOAD segments. Then the PHDR is not mapped when the loader gets control, and the loader runs into a segmentation fault while trying to access it. Since we are lucky about the order of segments on AMD64, the test succeeds there, but the resulting binaries are unusually large -- 2.1M each, with lots of padding within. When replacing '-Ttext' by '-Ttext-segment', the linker moves all segments consistently, the binaries have normal sizes, and the test case succeeds on all mentioned platforms. Since old versions of the gold linker don't support '-Ttext-segment', the patch also adds logic for falling back to '-Ttext'. gdb/testsuite/ChangeLog: * gdb.base/execl-update-breakpoints.exp: Specify the link address with '-Ttext-segment' instead of '-Ttext'. Fall back to '-Ttext' if the linker doesn't understand this.
2014-12-02 16:35:47 +01:00
2014-12-02 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/execl-update-breakpoints.exp: Specify the link address
with '-Ttext-segment' instead of '-Ttext'. Fall back to '-Ttext'
if the linker doesn't understand this.
Fix Python help() test for Python 3 The message displayed when using help() changed a bit with time, so this adjusts the test accordingly. gdb/testsuite/ChangeLog: * gdb.python/python.exp: Change expected reply to help().
2014-12-01 14:08:06 +01:00
2014-12-01 Simon Marchi <simon.marchi@ericsson.com>
* gdb.python/python.exp: Change expected reply to help().
Don't enable gdbtk in testsuite When I skim configure.ac and Makefile.in in gdb/testsuite, I happen to see that directory gdb.gdbtk is added to subdirs, however it doesn't exist. gdb/testsuite/gdb.gdbtk was removed by the patch below, [rfa] git repo fixup: delete gdb/testsuite/gdb.gdbtk http://thread.gmane.org/gmane.comp.gdb.patches/61489 and we should cleanup configure.ac accordingly. gdb/testsuite: 2014-12-01 Yao Qi <yao@codesourcery.com> * configure.ac: Remove AC_ARG_ENABLE for gdbtk. Don't invoke AC_CONFIG_SUBDIRS(gdb.gdbtk). * configure: Re-generated.
2014-11-25 09:07:45 +01:00
2014-12-01 Yao Qi <yao@codesourcery.com>
* configure.ac: Remove AC_ARG_ENABLE for gdbtk. Don't invoke
AC_CONFIG_SUBDIRS(gdb.gdbtk).
* configure: Re-generated.
Enable chained function calls in C++ expressions. gdb/ChangeLog: * eval.c: Include gdbthread.h. (evaluate_subexp): Enable thread stack temporaries before evaluating a complete expression and clean them up after the evaluation is complete. * gdbthread.h: Include common/vec.h. (value_ptr): New typedef. (VEC (value_ptr)): New vector type. (value_vec): New typedef. (struct thread_info): Add new fields stack_temporaries_enabled and stack_temporaries. (enable_thread_stack_temporaries) (thread_stack_temporaries_enabled_p, push_thread_stack_temporary) (get_last_thread_stack_temporary) (value_in_thread_stack_temporaries): Declare. * gdbtypes.c (class_or_union_p): New function. * gdbtypes.h (class_or_union_p): Declare. * infcall.c (call_function_by_hand): Store return values of class type as temporaries on stack. * thread.c (enable_thread_stack_temporaries): New function. (thread_stack_temporaries_enabled_p, push_thread_stack_temporary) (get_last_thread_stack_temporary): Likewise. (value_in_thread_stack_temporaries): Likewise. * value.c (value_force_lval): New function. * value.h (value_force_lval): Declare. gdb/testsuite/ChangeLog: * gdb.cp/chained-calls.cc: New file. * gdb.cp/chained-calls.exp: New file. * gdb.cp/smartp.exp: Remove KFAIL for "p c2->inta".
2014-11-11 14:43:03 +01:00
2014-11-28 Siva Chandra Reddy <sivachandra@google.com>
* gdb.cp/chained-calls.cc: New file.
* gdb.cp/chained-calls.exp: New file.
* gdb.cp/smartp.exp: Remove KFAIL for "p c2->inta".
Fix prints in tests for Python 3 Python 3's print requires to use parentheses, so this patch adds them where they were missing. gdb/testsuite/ChangeLog: * gdb.ada/py_range.exp: Add parentheses to calls to print. * gdb.dwarf2/symtab-producer.exp: Same. * gdb.gdb/python-interrupts.exp: Same. * gdb.gdb/python-selftest.exp: Same. * gdb.python/py-linetable.exp: Same. * gdb.python/py-type.exp: Same. * gdb.python/py-value-cc.exp: Same. * gdb.python/py-value.exp: Same.
2014-11-28 17:18:48 +01:00
2014-11-28 Simon Marchi <simon.marchi@ericsson.com>
* gdb.ada/py_range.exp: Add parentheses to python calls to print.
* gdb.dwarf2/symtab-producer.exp: Same.
* gdb.gdb/python-interrupts.exp: Same.
* gdb.gdb/python-selftest.exp: Same.
* gdb.python/py-linetable.exp: Same.
* gdb.python/py-type.exp: Same.
* gdb.python/py-value-cc.exp: Same.
* gdb.python/py-value.exp: Same.
Match library name prefixed with sysroot We enable systemtap probe in glibc recently, and see the following gdb fail, (gdb) set solib-absolute-prefix /. ... Stopped due to shared library event:^M Inferior loaded /./foo/bar/gdb.base/break-probes-solib.so ... (gdb) FAIL: gdb.base/break-probes.exp: run til our library loads (the program exited) $binfile_lib is /foo/bar/gdb.base/break-probes-solib.so, but the sysroot is prefixed in solib.c:solib_find, as comments described: Global variable GDB_SYSROOT is used as a prefix directory to search for shared libraries if they have an absolute path. so the output becomes "/./foo/bar/gdb.base/break-probes-solib.so", which is still correct. However, the test repeatedly continue the program and tries to match $binfile_lib, finally, the program exits and the test fails. This patch is to adjust the pattern to match $sysroot$binfile_lib instead of $binfile_lib. gdb/testsuite: 2014-11-28 Yao Qi <yao@codesourcery.com> * gdb.base/break-probes.exp: Match library name prefixed with sysroot.
2014-11-28 04:21:48 +01:00
2014-11-28 Yao Qi <yao@codesourcery.com>
* gdb.base/break-probes.exp: Match library name prefixed with
sysroot.
Fix test always passing in python/py-linetable.exp The following test is found in python/py-linetable.exp: gdb_test "python print sorted(fset)" \ "\[20L, 21L, 22L, 24L, 25L, 28L, 29L, 30L, 32L, 33L, 37L, 39L, 40L, 42L, 44L, 45L, 46L\].*" \ "Test frozen set contains line numbers" I noticed that it passed when using Python 3, even though it should fail because of the missing parentheses for the call print. There needs to be more escaping of the square brackets. Currently, it is interpreted as "any one character from this big list of characters, followed by .*". When adding the required amount of backslashes, the test starts failing as it should. Moreover, both in Python 2.7 and Python 3.3 the numbers don't have the L suffix, so now the test fails because of that. Anybody knows why they were there in the first place? I just tested with Python 2.4 and there are no Ls. gdb/testsuite/ChangeLog: * gdb.python/py-linetable.exp: Escape properly sorted(fset) test expected output. Add parentheses for the call to print. Remove L suffix from integers. Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
2014-11-26 19:03:57 +01:00
2014-11-27 Simon Marchi <simon.marchi@ericsson.com>
* gdb.python/py-linetable.exp: Escape properly sorted(fset)
test expected output. Add parentheses for the call to print.
Remove L suffix from integers.
gdb.dwarf2/dw2-op-out-param.S: Fix comment. gdb/ChangeLog: * gdb.dwarf2/dw2-op-out-param.S: Fix comment.
2014-11-26 23:44:46 +01:00
2014-11-26 Doug Evans <dje@google.com>
* gdb.dwarf2/dw2-op-out-param.S: Fix comment.
Use MACRO_AT_func in entry-values.exp MACRO_AT_func can be used in gdb.trace/entry-values.exp to correctly get function's address in generated debug info. As a result, the test is more friendly to clang. Currently, there are some fails in entry-values.exp when the test is compiled by clang. With this patch applied, all fails go away. gdb/testsuite: 2014-11-22 Yao Qi <yao@codesourcery.com> * gdb.trace/entry-values.c: Remove asms. (foo): Add foo_label. (bar): Add bar_label. * gdb.trace/entry-values.exp: Remove code computing foo's length and bar's length. (Dwarf::assemble): Invoke function_range for bar and use MACRO_AT_func for foo.
2014-11-22 14:28:31 +01:00
2014-11-22 Yao Qi <yao@codesourcery.com>
* gdb.trace/entry-values.c: Remove asms.
(foo): Add foo_label.
(bar): Add bar_label.
* gdb.trace/entry-values.exp: Remove code computing foo's
length and bar's length.
(Dwarf::assemble): Invoke function_range for bar and use
MACRO_AT_func for foo.
[arm] Fix fails in dw2-compdir-oldgcc.exp This patch fixes two fails in dw2-compdir-oldgcc.exp I've seen on arm target thumb mode. FAIL: gdb.dwarf2/dw2-compdir-oldgcc.exp: info source gcc42 FAIL: gdb.dwarf2/dw2-compdir-oldgcc.exp: info source gcc43 When fill in DW_AT_low_pc, the label should be used rather than the function, otherwise, the LSB bit of the address in DW_AT_low_pc is set and the debug info is wrong. This patch is to add two labels for functions gcc42 and gcc43 respectively, and use them. These two fails are fixed. gdb/testsuite: 2014-11-22 Yao Qi <yao@codesourcery.com> * gdb.dwarf2/dw2-compdir-oldgcc.S: Define label .Lgcc42_procstart and .Lgcc43_procstart. Use .Lgcc42_procstart instead of gcc42. Use .Lgcc43_procstart instead of gcc43.
2014-11-22 14:22:01 +01:00
2014-11-22 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dw2-compdir-oldgcc.S: Define label .Lgcc42_procstart
and .Lgcc43_procstart. Use .Lgcc42_procstart instead of gcc42.
Use .Lgcc43_procstart instead of gcc43.
Handling of empty Ada ranges with a negative upper bound. Consider the following variable declaration: type Array_Type is array (Integer range <>) of Integer; Var: Array_Type (0 .. -1); "ptype var" prints the wrong upper bound for that array: (gdb) ptype var type = array (0 .. 4294967295) of integer The debugging info for the type of variable "Var" is as follow: <2><cf>: Abbrev Number: 13 (DW_TAG_structure_type) <d0> DW_AT_name : foo__var___PAD <3><db>: Abbrev Number: 14 (DW_TAG_member) <dc> DW_AT_name : F <e0> DW_AT_type : <0xa5> This is just an artifact from code generation, which is just a wrapper that we should ignore. The real type is the type of field "F" in that PAD type, which is described as: <2><a5>: Abbrev Number: 10 (DW_TAG_array_type) <a6> DW_AT_name : foo__TvarS <3><b6>: Abbrev Number: 11 (DW_TAG_subrange_type) <b7> DW_AT_type : <0xc1> <bb> DW_AT_lower_bound : 0 <bc> DW_AT_upper_bound : 0xffffffff Trouble occurs because DW_AT_upper_bound is encoded using a DW_FORM_data4, which is ambiguous regarding signedness. In that case, dwarf2read.c::dwarf2_get_attr_constant_value reads the value as unsigned, which is not what we want in this case. As it happens, we already have code dealing with this situation in dwarf2read.c::read_subrange_type which checks whether the subrange's type is signed or not, and if it is, fixes the bound's value by sign-extending it: if (high.kind == PROP_CONST && !TYPE_UNSIGNED (base_type) && (high.data.const_val & negative_mask)) high.data.const_val |= negative_mask; Unfortunately, what happens in our case is that the base type of the array's subrange type is marked as being unsigned, and so we never get to apply the sign extension. Following the DWARF trail, the range's base type is described as another subrange type... <2><c1>: Abbrev Number: 12 (DW_TAG_subrange_type) <c7> DW_AT_name : foo__TTvarSP1___XDLU_0__1m <cb> DW_AT_type : <0x2d> ... whose base type is, (finally), a basic type (signed): <1><2d>: Abbrev Number: 2 (DW_TAG_base_type) <2e> DW_AT_byte_size : 4 <2f> DW_AT_encoding : 5 (signed) <30> DW_AT_name : integer The reason why GDB thinks that foo__TTvarSP1___XDLU_0__1m (the base type of the array's range type) is an unsigned type is found in gdbtypes.c::create_range_type. We consider that a range type is unsigned iff its lower bound is >= 0: if (low_bound->kind == PROP_CONST && low_bound->data.const_val >= 0) TYPE_UNSIGNED (result_type) = 1; That is normally sufficient, as one would expect the upper bound to always be greater or equal to the lower bound. But Ada actually allows the declaration of empty range types where the upper bound is less than the lower bound. In this case, the upper bound is negative, so we should not be marking the type as unsigned. This patch fixes the issue by simply checking the upper bound as well as the lower bound, and clears the range type's unsigned flag when it is found to be constant and negative. gdb/ChangeLog: * gdbtypes.c (create_range_type): Unset RESULT_TYPE's flag_unsigned if HIGH_BOUND is constant and negative. gdb/testsuite/ChangeLog: * gdb.ada/n_arr_bound: New testcase. Tested on x86_64-linux.
2014-10-03 00:17:49 +02:00
2014-11-21 Joel Brobecker <brobecker@adacore.com>
* gdb.ada/n_arr_bound: New testcase.
Partial fix for PR breakpoints/10737: Make syscall info be per-arch instead of global This patch intends to partially fix PR breakpoints/10737, which is about making the syscall information (for the "catch syscall" command) be per-arch, instead of global. This is not a full fix because of the other issues pointed by Pedro here: <https://sourceware.org/bugzilla/show_bug.cgi?id=10737#c5> However, I consider it a good step towards the real fix. It will also help me fix <https://sourceware.org/bugzilla/show_bug.cgi?id=17402>. What this patch does, basically, is move the "syscalls_info" struct to gdbarch. Currently, the syscall information is stored in a global variable inside gdb/xml-syscall.c, which means that there is no easy way to correlate this info with the current target or architecture being used, for example. This causes strange behaviors, because the syscall info is not re-read when the arch changes. For example, if you put a syscall catchpoint in syscall 5 on i386 (syscall open), and then load a x86_64 program on GDB and put the same syscall 5 there (fstat on x86_64), you will still see that GDB tells you that it is catching "open", even though it is not. With this patch, GDB correctly says that it will be catching fstat syscalls. (gdb) set architecture i386 The target architecture is assumed to be i386 (gdb) catch syscall 5 Catchpoint 1 (syscall 'open' [5]) (gdb) set architecture i386:x86-64 The target architecture is assumed to be i386:x86-64 (gdb) catch syscall 5 Catchpoint 2 (syscall 'open' [5]) But with the patch: (gdb) set architecture i386 The target architecture is assumed to be i386 (gdb) catch syscall 5 Catchpoint 1 (syscall 'open' [5]) (gdb) set architecture i386:x86-64 The target architecture is assumed to be i386:x86-64 (gdb) catch syscall 5 Catchpoint 2 (syscall 'fstat' [5]) As I said, there are still some problems on the "catch syscall" mechanism, because (for example) the user should be able to "catch syscall open" on i386, and then expect "open" to be caught also on x86_64. Currently, it doesn't work. I intend to work on this later. gdb/ 2014-11-20 Sergio Durigan Junior <sergiodj@redhat.com> PR breakpoints/10737 * amd64-linux-tdep.c (amd64_linux_init_abi_common): Adjust call to set_xml_syscall_file_name to provide gdbarch. * arm-linux-tdep.c (arm_linux_init_abi): Likewise. * bfin-linux-tdep.c (bfin_linux_init_abi): Likewise. * breakpoint.c (print_it_catch_syscall): Adjust call to get_syscall_by_number to provide gdbarch. (print_one_catch_syscall): Likewise. (print_mention_catch_syscall): Likewise. (print_recreate_catch_syscall): Likewise. (catch_syscall_split_args): Adjust calls to get_syscall_by_number and get_syscall_by_name to provide gdbarch. (catch_syscall_completer): Adjust call to get_syscall_names to provide gdbarch. * gdbarch.c: Regenerate. * gdbarch.h: Likewise. * gdbarch.sh: Forward declare "struct syscalls_info". (xml_syscall_file): New variable. (syscalls_info): Likewise. * i386-linux-tdep.c (i386_linux_init_abi): Adjust call to set_xml_syscall_file_name to provide gdbarch. * mips-linux-tdep.c (mips_linux_init_abi): Likewise. * ppc-linux-tdep.c (ppc_linux_init_abi): Likewise. * s390-linux-tdep.c (s390_gdbarch_init): Likewise. * sparc-linux-tdep.c (sparc32_linux_init_abi): Likewise. * sparc64-linux-tdep.c (sparc64_linux_init_abi): Likewise. * xml-syscall.c: Include gdbarch.h. (set_xml_syscall_file_name): Accept gdbarch parameter. (get_syscall_by_number): Likewise. (get_syscall_by_name): Likewise. (get_syscall_names): Likewise. (my_gdb_datadir): Delete global variable. (struct syscalls_info) <my_gdb_datadir>: New variable. (struct syscalls_info) <sysinfo>: Rename variable to "syscalls_info". (sysinfo): Delete global variable. (have_initialized_sysinfo): Likewise. (xml_syscall_file): Likewise. (sysinfo_free_syscalls_desc): Rename to... (syscalls_info_free_syscalls_desc): ... this. (free_syscalls_info): Rename "sysinfo" to "syscalls_info". Adjust code to the new layout of "struct syscalls_info". (make_cleanup_free_syscalls_info): Rename parameter "sysinfo" to "syscalls_info". (syscall_create_syscall_desc): Likewise. (syscall_start_syscall): Likewise. (syscall_parse_xml): Likewise. (xml_init_syscalls_info): Likewise. Drop "const" from return value. (init_sysinfo): Rename to... (init_syscalls_info): ...this. Add gdbarch as a parameter. Adjust function to deal with gdbarch. (xml_get_syscall_number): Delete parameter sysinfo. Accept gdbarch as a parameter. Adjust code. (xml_get_syscall_name): Likewise. (xml_list_of_syscalls): Likewise. (set_xml_syscall_file_name): Accept gdbarch as parameter. (get_syscall_by_number): Likewise. (get_syscall_by_name): Likewise. (get_syscall_names): Likewise. * xml-syscall.h (set_xml_syscall_file_name): Likewise. (get_syscall_by_number): Likewise. (get_syscall_by_name): Likewise. (get_syscall_names): Likewise. gdb/testsuite/ 2014-11-20 Sergio Durigan Junior <sergiodj@redhat.com> PR breakpoints/10737 * gdb.base/catch-syscall.exp (do_syscall_tests): Call test_catch_syscall_multi_arch. (test_catch_syscall_multi_arch): New function.
2014-11-20 18:28:18 +01:00
2014-11-20 Sergio Durigan Junior <sergiodj@redhat.com>
PR breakpoints/10737
* gdb.base/catch-syscall.exp (do_syscall_tests): Call
test_catch_syscall_multi_arch.
(test_catch_syscall_multi_arch): New function.
Split struct symtab into two: struct symtab and compunit_symtab. Currently "symtabs" in gdb are stored as a single linked list of struct symtab that contains both symbol symtabs (the blockvectors) and file symtabs (the linetables). This has led to confusion, bugs, and performance issues. This patch is conceptually very simple: split struct symtab into two pieces: one part containing things common across the entire compilation unit, and one part containing things specific to each source file. Example. For the case of a program built out of these files: foo.c foo1.h foo2.h bar.c foo1.h bar.h Today we have a single list of struct symtabs: objfile -> foo.c -> foo1.h -> foo2.h -> bar.c -> foo1.h -> bar.h -> NULL where "->" means the "next" pointer in struct symtab. With this patch, that turns into: objfile -> foo.c(cu) -> bar.c(cu) -> NULL | | v v foo.c bar.c | | v v foo1.h foo1.h | | v v foo2.h bar.h | | v v NULL NULL where "foo.c(cu)" and "bar.c(cu)" are struct compunit_symtab objects, and the files foo.c, etc. are struct symtab objects. So now, for example, when we want to iterate over all blockvectors we can now just iterate over the compunit_symtab list. Plus a lot of the data that was either unused or replicated for each symtab in a compilation unit now lives in struct compunit_symtab. E.g., the objfile pointer, the producer string, etc. I thought of moving "language" out of struct symtab but there is logic to try to compute the language based on previously seen files, and I think that's best left as is for now. With my standard monster benchmark with -readnow (which I can't actually do, but based on my calculations), whereas today the list requires 77MB to store all the struct symtabs, it now only requires 37MB. A modest space savings given the gigabytes needed for all the debug info, etc. Still, it's nice. Plus, whereas today we create a copy of dirname for each source file symtab in a compilation unit, we now only create one for the compunit. So this patch is basically just a data structure reorg, I don't expect significant performance improvements from it. Notes: 1) A followup patch can do a similar split for struct partial_symtab. I have left that until after I get the changes I want in to better utilize .gdb_index (it may affect how we do partial syms). 2) Another followup patch *could* rename struct symtab. The term "symtab" is ambiguous and has been a source of confusion. In this patch I'm leaving it alone, calling it the "historical" name of "filetabs", which is what they are now: just the file-name + line-table. gdb/ChangeLog: Split struct symtab into two: struct symtab and compunit_symtab. * amd64-tdep.c (amd64_skip_xmm_prologue): Fetch producer from compunit. * block.c (blockvector_for_pc_sect): Change "struct symtab *" argument to "struct compunit_symtab *". All callers updated. (set_block_compunit_symtab): Renamed from set_block_symtab. Change "struct symtab *" argument to "struct compunit_symtab *". All callers updated. (get_block_compunit_symtab): Renamed from get_block_symtab. Change result to "struct compunit_symtab *". All callers updated. (find_iterator_compunit_symtab): Renamed from find_iterator_symtab. Change result to "struct compunit_symtab *". All callers updated. * block.h (struct global_block) <compunit_symtab>: Renamed from symtab. hange type to "struct compunit_symtab *". All uses updated. (struct block_iterator) <d.compunit_symtab>: Renamed from "d.symtab". Change type to "struct compunit_symtab *". All uses updated. * buildsym.c (struct buildsym_compunit): New struct. (subfiles, buildsym_compdir, buildsym_objfile, main_subfile): Delete. (buildsym_compunit): New static global. (finish_block_internal): Update to fetch objfile from buildsym_compunit. (make_blockvector): Delete objfile argument. (start_subfile): Rewrite to use buildsym_compunit. Don't initialize debugformat, producer. (start_buildsym_compunit): New function. (free_buildsym_compunit): Renamed from free_subfiles_list. All callers updated. (patch_subfile_names): Rewrite to use buildsym_compunit. (get_compunit_symtab): New function. (get_macro_table): Delete argument comp_dir. All callers updated. (start_symtab): Change result to "struct compunit_symtab *". All callers updated. Create the subfile of the main source file. (watch_main_source_file_lossage): Rewrite to use buildsym_compunit. (reset_symtab_globals): Update. (end_symtab_get_static_block): Update to use buildsym_compunit. (end_symtab_without_blockvector): Rewrite. (end_symtab_with_blockvector): Change result to "struct compunit_symtab *". All callers updated. Update to use buildsym_compunit. Don't set symtab->dirname, instead set it in the compunit. Explicitly make sure main symtab is first in its list. Set debugformat, producer, blockvector, block_line_section, and macrotable in the compunit. (end_symtab_from_static_block): Change result to "struct compunit_symtab *". All callers updated. (end_symtab, end_expandable_symtab): Ditto. (set_missing_symtab): Change symtab argument to "struct compunit_symtab *". All callers updated. (augment_type_symtab): Ditto. (record_debugformat): Update to use buildsym_compunit. (record_producer): Update to use buildsym_compunit. * buildsym.h (struct subfile) <dirname>: Delete. <producer, debugformat>: Delete. <buildsym_compunit>: New member. (get_compunit_symtab): Declare. * dwarf2read.c (struct type_unit_group) <compunit_symtab>: Renamed from primary_symtab. Change type to "struct compunit_symtab *". All uses updated. (dwarf2_start_symtab): Change result to "struct compunit_symtab *". All callers updated. (dwarf_decode_macros): Delete comp_dir argument. All callers updated. (struct dwarf2_per_cu_quick_data) <compunit_symtab>: Renamed from symtab. Change type to "struct compunit_symtab *". All uses updated. (dw2_instantiate_symtab): Change result to "struct compunit_symtab *". All callers updated. (dw2_find_last_source_symtab): Ditto. (dw2_lookup_symbol): Ditto. (recursively_find_pc_sect_compunit_symtab): Renamed from recursively_find_pc_sect_symtab. Change result to "struct compunit_symtab *". All callers updated. (dw2_find_pc_sect_compunit_symtab): Renamed from dw2_find_pc_sect_symtab. Change result to "struct compunit_symtab *". All callers updated. (get_compunit_symtab): Renamed from get_symtab. Change result to "struct compunit_symtab *". All callers updated. (recursively_compute_inclusions): Change type of immediate_parent argument to "struct compunit_symtab *". All callers updated. (compute_compunit_symtab_includes): Renamed from compute_symtab_includes. All callers updated. Rewrite to compute includes of compunit_symtabs and not symtabs. (process_full_comp_unit): Update to work with struct compunit_symtab. (process_full_type_unit): Ditto. (dwarf_decode_lines_1): Delete argument comp_dir. All callers updated. (dwarf_decode_lines): Remove special case handling of main subfile. (macro_start_file): Delete argument comp_dir. All callers updated. (dwarf_decode_macro_bytes): Ditto. * guile/scm-block.c (bkscm_print_block_syms_progress_smob): Update to use struct compunit_symtab. * i386-tdep.c (i386_skip_prologue): Fetch producer from compunit. * jit.c (finalize_symtab): Build compunit_symtab. * jv-lang.c (get_java_class_symtab): Change result to "struct compunit_symtab *". All callers updated. * macroscope.c (sal_macro_scope): Fetch macro table from compunit. * macrotab.c (struct macro_table) <compunit_symtab>: Renamed from comp_dir. Change type to "struct compunit_symtab *". All uses updated. (new_macro_table): Change comp_dir argument to cust, "struct compunit_symtab *". All callers updated. * maint.c (struct cmd_stats) <nr_compunit_symtabs>: Renamed from nr_primary_symtabs. All uses updated. (count_symtabs_and_blocks): Update to handle compunits. (report_command_stats): Update output, "primary symtabs" renamed to "compunits". * mdebugread.c (new_symtab): Change result to "struct compunit_symtab *". All callers updated. (parse_procedure): Change type of search_symtab argument to "struct compunit_symtab *". All callers updated. * objfiles.c (objfile_relocate1): Loop over blockvectors in a separate loop. * objfiles.h (struct objfile) <compunit_symtabs>: Renamed from symtabs. Change type to "struct compunit_symtab *". All uses updated. (ALL_OBJFILE_FILETABS): Renamed from ALL_OBJFILE_SYMTABS. All uses updated. (ALL_OBJFILE_COMPUNITS): Renamed from ALL_OBJFILE_PRIMARY_SYMTABS. All uses updated. (ALL_FILETABS): Renamed from ALL_SYMTABS. All uses updated. (ALL_COMPUNITS): Renamed from ALL_PRIMARY_SYMTABS. All uses updated. * psympriv.h (struct partial_symtab) <compunit_symtab>: Renamed from symtab. Change type to "struct compunit_symtab *". All uses updated. * psymtab.c (psymtab_to_symtab): Change result type to "struct compunit_symtab *". All callers updated. (find_pc_sect_compunit_symtab_from_partial): Renamed from find_pc_sect_symtab_from_partial. Change result type to "struct compunit_symtab *". All callers updated. (lookup_symbol_aux_psymtabs): Change result type to "struct compunit_symtab *". All callers updated. (find_last_source_symtab_from_partial): Ditto. * python/py-symtab.c (stpy_get_producer): Fetch producer from compunit. * source.c (forget_cached_source_info_for_objfile): Fetch debugformat and macro_table from compunit. * symfile-debug.c (debug_qf_find_last_source_symtab): Change result type to "struct compunit_symtab *". All callers updated. (debug_qf_lookup_symbol): Ditto. (debug_qf_find_pc_sect_compunit_symtab): Renamed from debug_qf_find_pc_sect_symtab, change result type to "struct compunit_symtab *". All callers updated. * symfile.c (allocate_symtab): Delete objfile argument. New argument cust. (allocate_compunit_symtab): New function. (add_compunit_symtab_to_objfile): New function. * symfile.h (struct quick_symbol_functions) <lookup_symbol>: Change result type to "struct compunit_symtab *". All uses updated. <find_pc_sect_compunit_symtab>: Renamed from find_pc_sect_symtab. Change result type to "struct compunit_symtab *". All uses updated. * symmisc.c (print_objfile_statistics): Compute blockvector count in separate loop. (dump_symtab_1): Update test for primary source symtab. (maintenance_info_symtabs): Update to handle compunit symtabs. (maintenance_check_symtabs): Ditto. * symtab.c (set_primary_symtab): Delete. (compunit_primary_filetab): New function. (compunit_language): New function. (iterate_over_some_symtabs): Change type of arguments "first", "after_last" to "struct compunit_symtab *". All callers updated. Update to loop over symtabs in each compunit. (error_in_psymtab_expansion): Rename symtab argument to cust, and change type to "struct compunit_symtab *". All callers updated. (find_pc_sect_compunit_symtab): Renamed from find_pc_sect_symtab. Change result type to "struct compunit_symtab *". All callers updated. (find_pc_compunit_symtab): Renamed from find_pc_symtab. Change result type to "struct compunit_symtab *". All callers updated. (find_pc_sect_line): Only loop over symtabs within selected compunit instead of all symtabs in the objfile. * symtab.h (struct symtab) <blockvector>: Moved to compunit_symtab. <compunit_symtab> New member. <block_line_section>: Moved to compunit_symtab. <locations_valid>: Ditto. <epilogue_unwind_valid>: Ditto. <macro_table>: Ditto. <dirname>: Ditto. <debugformat>: Ditto. <producer>: Ditto. <objfile>: Ditto. <call_site_htab>: Ditto. <includes>: Ditto. <user>: Ditto. <primary>: Delete (SYMTAB_COMPUNIT): New macro. (SYMTAB_BLOCKVECTOR): Update definition. (SYMTAB_OBJFILE): Update definition. (SYMTAB_DIRNAME): Update definition. (struct compunit_symtab): New type. Common members among all source symtabs within a compilation unit moved here. All uses updated. (COMPUNIT_OBJFILE): New macro. (COMPUNIT_FILETABS): New macro. (COMPUNIT_DEBUGFORMAT): New macro. (COMPUNIT_PRODUCER): New macro. (COMPUNIT_DIRNAME): New macro. (COMPUNIT_BLOCKVECTOR): New macro. (COMPUNIT_BLOCK_LINE_SECTION): New macro. (COMPUNIT_LOCATIONS_VALID): New macro. (COMPUNIT_EPILOGUE_UNWIND_VALID): New macro. (COMPUNIT_CALL_SITE_HTAB): New macro. (COMPUNIT_MACRO_TABLE): New macro. (ALL_COMPUNIT_FILETABS): New macro. (compunit_symtab_ptr): New typedef. (DEF_VEC_P (compunit_symtab_ptr)): New vector type. gdb/testsuite/ChangeLog: * gdb.base/maint.exp: Update expected output.
2014-11-20 16:42:48 +01:00
2014-11-20 Doug Evans <xdje42@gmail.com>
* gdb.base/maint.exp: Update expected output.
Use 2-byte instead of 4-byte NOP on S390 in 'bp-permanent' test case The bp-permanent test case assumes that a NOP is exactly as long as a software breakpoint. This is not the case for the S390 "nop" instruction, which is 4 bytes long, while a software breakpoint is just 2 bytes long. The "nopr" instruction has the right size and can be used instead. Without this patch the test case fails on S390 when trying to continue after SIGTRAP on the permanent breakpoint: ... Continuing. Program received signal SIGILL, Illegal instruction. test () at /home/arnez/src/binutils-gdb/gdb/testsuite/gdb.base/bp-permanent.c:40 40 NOP; /* after permanent bp */ (gdb) FAIL: gdb.base/bp-permanent.exp: always_inserted=off, sw_watchpoint=0: basics: stop at permanent breakpoint With this patch the test case succeeds without any FAILs. gdb/testsuite/ChangeLog: * gdb.base/bp-permanent.c (NOP): Define as 2-byte instead of 4-byte instruction on S390.
2014-11-17 16:22:48 +01:00
2014-11-19 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/bp-permanent.c (NOP): Define as 2-byte instead of
4-byte instruction on S390.
[Ada] Ignore __XA types when redundant. Consider the following code which declares a variable A2 which is an array of arrays of integers. type Array2_First is array (24 .. 26) of Integer; type Array2_Second is array (1 .. 2) of Array2_First; A1 : Array1_Second := ((10, 11, 12), (13, 14, 15)); Trying to print the type of that variable currently yields: (gdb) ptype A2 type = array (1 .. 2, 24 .. 26) of integer This is not correct, as this is the description of a two-dimension array, which is different from an array of arrays. The expected output is: (gdb) ptype a2 type = array (1 .. 2) of foo_n926_029.array2_first GDB's struct type currently handles multi-dimension arrays the same way arrays of arrays, where each dimension is stored as a sub-array. The ada-valprint module considers that consecutive array layers are in fact multi-dimension arrays. For array of arrays, a typedef layer is introduced between the two arrays, creating a break between each array type. In our situation, A2 is a described as a typedef of an array type... .uleb128 0x8 # (DIE (0x125) DW_TAG_variable) .ascii "a2\0" # DW_AT_name .long 0xfc # DW_AT_type .uleb128 0x4 # (DIE (0xfc) DW_TAG_typedef) .long .LASF5 # DW_AT_name: "foo__array2_second" .long 0x107 # DW_AT_type .uleb128 0x5 # (DIE (0x107) DW_TAG_array_type) .long .LASF5 # DW_AT_name: "foo__array2_second" .long 0xb4 # DW_AT_type .uleb128 0x6 # (DIE (0x114) DW_TAG_subrange_type) .long 0x11b # DW_AT_type .byte 0x2 # DW_AT_upper_bound .byte 0 # end of children of DIE 0x107 ... whose element type is, as expected, a typedef to the sub-array type: .uleb128 0x4 # (DIE (0xb4) DW_TAG_typedef) .long .LASF4 # DW_AT_name: "foo__array2_first" .long 0xbf # DW_AT_type .uleb128 0x9 # (DIE (0xbf) DW_TAG_array_type) .long .LASF4 # DW_AT_name: "foo__array2_first" .long 0xd8 # DW_AT_GNAT_descriptive_type .long 0x1c5 # DW_AT_type .uleb128 0xa # (DIE (0xd0) DW_TAG_subrange_type) .long 0xf0 # DW_AT_type .byte 0x18 # DW_AT_lower_bound .byte 0x1a # DW_AT_upper_bound .byte 0 # end of children of DIE 0xbf The reason why things fails is that, during expression evaluation, GDB tries to "fix" A1's type. Because the sub-array has a parallel (descriptive) type (DIE 0xd8), GDB thinks that our array's index type must be dynamic and therefore needs to be fixed. This in turn causes the sub-array to be "fixed", which itself results in the typedef layer to be stripped. However, looking closer at the parallel type, we see... .uleb128 0xb # (DIE (0xd8) DW_TAG_structure_type) .long .LASF8 # DW_AT_name: "foo__array2_first___XA" [...] .uleb128 0xc # (DIE (0xe4) DW_TAG_member) .long .LASF10 # DW_AT_name: "foo__Tarray2_firstD1___XDLU_24__26" ... that all it tells us is that the array bounds are 24 and 26, which is already correctly provided by the array's DW_TAG_subrange_type bounds, meaning that this parallel type is just redundant. Parallel types in general are slowly being removed in favor of standard DWARF constructs. But in the meantime, this patch kills two birds with one stone: 1. It recognizes this situation where the XA type is useless, and saves an unnecessary range-type fixing; 2. It fixes the issue at hand because ignoring the XA type results in no type fixing being required, which allows the typedef layer to be preserved. gdb/ChangeLog: * ada-lang.c (ada_is_redundant_range_encoding): New function. (ada_is_redundant_index_type_desc): New function. (to_fixed_array_type): Ignore parallel XA type if redundant. gdb/testsuite/ChangeLog: * gdb.ada/arr_arr: New testcase. Tested on x86_64-linux.
2014-09-27 18:09:34 +02:00
2014-11-19 Joel Brobecker <brobecker@adacore.com>
* gdb.ada/arr_arr: New testcase.
varsize-limit error printing element of packed array... ... when that packed array is part of a discriminated record and one of the bounds is a discriminant. Consider the following code: type FUNNY_CHAR_T is (NUL, ' ', '"', '#', [etc]); type FUNNY_STR_T is array (POSITIVE range <>) of FUNNY_CHAR_T; pragma PACK (FUNNY_STR_T); type FUNNY_STRING_T (SIZE : NATURAL := 1) is record STR : FUNNY_STR_T (1 .. SIZE) := (others => '0'); LENGTH : NATURAL := 4; end record; TEST: FUNNY_STRING_T(100); GDB is able to print the value of variable "test" and "test.str". But not "test.str(1)": (gdb) p test $1 = (size => 100, str => (33 'A', nul <repeats 99 times>), length => 1) (gdb) p test.str $2 = (33 'A', nul <repeats 99 times>) (gdb) p test.str(1) object size is larger than varsize-limit The problem occurs during the phase where we are trying to resolve the expression subscript operation. On the one hand of the subscript operator, we have the result of the evaluation of "test.str", which is our packed array. We have the following code to handle packed arrays in particular: if (ada_is_constrained_packed_array_type (desc_base_type (value_type (argvec[0])))) argvec[0] = ada_coerce_to_simple_array (argvec[0]); This eventually leads to a call to constrained_packed_array_type to return the "simple array". This function relies on a parallel ___XA type, when available, to determine the bounds. In our case, we find type... failure__funny_string_t__T4b___XA" ... which has one field describing the bounds of our array as: failure__funny_string_t__T3b___XDLU_1__size The part that interests us is after the ___XD suffix or, in other words: "LU_1__size". What this means in GNAT encoding parlance is that the lower bound is 1, and that the upper bound is the value of "size". "size" is our discriminant in this case. Normally, we would access the record's discriminant in order to get the upper bound's value, but we do not have that information, here. We are in a mode where we are just trying to "fix" the type without an actual value. This is what the call to to_fixed_range_type is doing, and because the fix'ing fails, it ends up returning the ___XDLU type unmodified as our index type. This shouldn't be a problem, except that the later part of constrained_packed_array_type then uses that index_type to determine the array size, via a call to get_discrete_bounds. The problem is that the upper bound of the ___XDLU type is dynamic (in the DWARF sense) while get_discrete_bounds implicitly assumes that the bounds are static, and therefore accesses them using macros that assume the bounds values are constants: case TYPE_CODE_RANGE: *lowp = TYPE_LOW_BOUND (type); *highp = TYPE_HIGH_BOUND (type); This therefore returns a bogus value for the upper bound, leading to an unexpectedly large size for our array, which later triggers the varsize-limit guard we've seen above. This patch avoids the problem by adding special handling of dynamic range types. It also extends the documentation of the constrained_packed_array_type function to document what happens in this situation. gdb/ChangeLog: * ada-lang.c (constrained_packed_array_type): Set the length of the return array as if both bounds where zero if that returned array's index type is dynamic. gdb/testsuite/ChangeLog: * gdb.ada/pkd_arr_elem: New Testcase. Tested on x86_64-linux.
2014-09-12 03:38:04 +02:00
2014-11-19 Joel Brobecker <brobecker@adacore.com>
* gdb.ada/pkd_arr_elem: New Testcase.
I caught a few mingw32-specific failures for some of the gdb.reverse tests. FAIL: gdb.reverse/consecutive-precsave.exp: reload precord save file FAIL: gdb.reverse/finish-precsave.exp: reload precord save file FAIL: gdb.reverse/until-precsave.exp: reload core file FAIL: gdb.reverse/watch-precsave.exp: reload core file FAIL: gdb.reverse/step-precsave.exp: reload core file FAIL: gdb.reverse/break-precsave.exp: reload precord save file FAIL: gdb.reverse/sigall-precsave.exp: reload precord save file They happen for two reasons. - mingw32 does not define SIGTRAP, so upon recording a core file, the signal information will be missing, which in turn causes GDB to not display the stopping signal when it loads the same core file. An earlier message warns about this: "warning: Signal SIGTRAP does not exist on this system." - The testcase is crafted in a way that expects a pattern of the stopping signal message instead of a successful core file read message. The following patch fixes this by changing the old pattern to a more reasonable one, while still ignoring the fact that mingw32-based GDB does not record a SIGTRAP in a core file because it does not define it. gdb/testsuite/ 2014-11-18 Luis Machado <lgustavo@codesourcery.com> * gdb.reverse/break-precsave: Expect completion message for core file reads. * gdb.reverse/consecutive-precsave.exp: Likewise. * gdb.reverse/finish-precsave.exp: Likewise. * gdb.reverse/i386-precsave.exp: Likewise. * gdb.reverse/machinestate-precsave.exp: Likewise. * gdb.reverse/sigall-precsave.exp: Likewise. * gdb.reverse/solib-precsave.exp: Likewise. * gdb.reverse/step-precsave.exp: Likewise. * gdb.reverse/until-precsave.exp: Likewise. * gdb.reverse/watch-precsave.exp: Likewise.
2014-11-18 14:16:37 +01:00
2014-11-18 Luis Machado <lgustavo@codesourcery.com>
* gdb.reverse/break-precsave: Expect completion message for
core file reads.
* gdb.reverse/consecutive-precsave.exp: Likewise.
* gdb.reverse/finish-precsave.exp: Likewise.
* gdb.reverse/i386-precsave.exp: Likewise.
* gdb.reverse/machinestate-precsave.exp: Likewise.
* gdb.reverse/sigall-precsave.exp: Likewise.
* gdb.reverse/solib-precsave.exp: Likewise.
* gdb.reverse/step-precsave.exp: Likewise.
* gdb.reverse/until-precsave.exp: Likewise.
* gdb.reverse/watch-precsave.exp: Likewise.
GDB testsuite: More fixes for warnings with -std=gnu11 Fix some more C compiler warnings for missing function return types and implicit function declarations in the GDB testsuite. gdb/testsuite/ChangeLog: * gdb.base/bp-permanent.c: Include unistd.h. * gdb.python/py-framefilter-mi.c (main): Add return type. * gdb.python/py-framefilter.c (main): Likewise. * gdb.trace/actions-changed.c (main): Likewise.
2014-11-14 19:36:30 +01:00
2014-11-17 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/bp-permanent.c: Include unistd.h.
* gdb.python/py-framefilter-mi.c (main): Add return type.
* gdb.python/py-framefilter.c (main): Likewise.
* gdb.trace/actions-changed.c (main): Likewise.
Eliminate literal line numbers in mi-until.exp Remove literal line numbers from the regexps in mi-until.exp. Add appropriate eye-catchers to until.c and refer to those instead. This change fixes the test case after having disturbed the line numbering with the previous fix for compiler warnings with -std=gnu11. gdb/testsuite/ChangeLog: * gdb.mi/until.c: Add eye-catchers. * gdb.mi/mi-until.exp: Refer to eye-catchers instead of literal line numbers.
2014-11-14 19:21:21 +01:00
2014-11-17 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.mi/until.c: Add eye-catchers.
* gdb.mi/mi-until.exp: Refer to eye-catchers instead of literal
line numbers.
Drop remaining references to removed source lines in break1.c and ur1.c In some .exp files it was missed to remove the references to eye-catchers like "set breakpoint 9 here" when the non-prototype function header variants they belonged to were deleted. This patch cleans this up. gdb/testsuite/ChangeLog: * gdb.base/condbreak.exp: Drop references to removed non-prototype function header variants in break1.c. * gdb.base/ena-dis-br.exp: Likewise. * gdb.base/hbreak2.exp: Likewise. * gdb.reverse/until-precsave.exp: Drop references to removed non-prototype function header variants in ur1.c. * gdb.reverse/until-reverse.exp: Likewise.
2014-11-14 17:45:41 +01:00
2014-11-17 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/condbreak.exp: Drop references to removed non-prototype
function header variants in break1.c.
* gdb.base/ena-dis-br.exp: Likewise.
* gdb.base/hbreak2.exp: Likewise.
* gdb.reverse/until-precsave.exp: Drop references to removed
non-prototype function header variants in ur1.c.
* gdb.reverse/until-reverse.exp: Likewise.
dwarf.exp: In 64-bit units, emit also abbrev offset as a 64-bit field Dwarf::tu and Dwarf::cu allow selection of units with 64-bit offsets through an option. When selected, unit size is encoded properly, but offset to abbreviation unit is still encoded in a 4-byte field. This patch fixes the problem. Reproducer: Dwarf::assemble "blah.s" { tu {is_64 1 version 4 addr_size 8} 0x1122334455667788 the_type { type_unit {} { the_type: } } cu {is_64 1 version 4 addr_size 8} { compile_unit {{language @DW_LANG_C}} {} } } gdb/testsuite: * lib/dwarf.exp (Dwarf::cu, Dwarf::tu): Emit ${_cu_offset_size} bytes abbrev offset.
2014-11-17 01:31:47 +01:00
2014-11-17 Petr Machata <pmachata@redhat.com>
* lib/dwarf.exp (Dwarf::cu, Dwarf::tu): Emit
${_cu_offset_size} bytes abbrev offset.
PR symtab/17559 Basically the problem is that "symtab" is ambiguous. Is it the primary symtab (where we canonically think of blockvectors as being stored) or is it for a specific file (where each file's line table is stored) ? gdb_disassembly wants the symtab that contains the line table but is instead getting the primary symtab. gdb/ChangeLog: PR symtab/17559 * symtab.c (find_pc_line_symtab): New function. * symtab.h (find_pc_line_symtab): Declare. * disasm.c (gdb_disassembly): Call find_pc_line_symtab instead of find_pc_symtab. * tui/tui-disasm.c (tui_set_disassem_content): Ditto. * tui/tui-hooks.c (tui_selected_frame_level_changed_hook): Ditto. * tui/tui-source.c (tui_vertical_source_scroll): Ditto. * tui/tui-win.c (make_visible_with_new_height): Ditto. * tui/tui-winsource.c (tui_horizontal_source_scroll): Ditto. (tui_display_main): Call find_pc_line_symtab instead of find_pc_line. gdb/testsuite/ChangeLog: PR symtab/17559 * gdb.base/line-symtabs.exp: New file. * gdb.base/line-symtabs.c: New file. * gdb.base/line-symtabs.h: New file.
2014-11-15 19:08:34 +01:00
2014-11-15 Doug Evans <xdje42@gmail.com>
PR symtab/17559
* gdb.base/line-symtabs.exp: New file.
* gdb.base/line-symtabs.c: New file.
* gdb.base/line-symtabs.h: New file.
Fix dw2-ifort-parameter.exp fail with clang The patch <https://sourceware.org/ml/gdb-patches/2014-03/msg00202.html> fixed dw2-ifort-parameter.exp on powerpc64 by adding some labels to get the start and end address of function func. This should also fix the fail on thumb mode, however, this style is quite specific to gcc, and other compiler, such as clang, may not guarantee the order of global asms and functions. The test fails with clang: $ make check RUNTESTFLAGS='dw2-ifort-parameter.exp CC_FOR_TARGET=clang' (gdb) p/x param^M No symbol "param" in current context.^M (gdb) FAIL: gdb.dwarf2/dw2-ifort-parameter.exp: p/x param With this patch applied, dw2-ifort-parameter.exp still passes for gcc on arm thumb mode and popwerpc64, and it also passes for clang on x86_linux. gdb/testsuite: 2014-11-14 Yao Qi <yao@codesourcery.com> * gdb.dwarf2/dw2-ifort-parameter.c: Remove inline asm. (func): Add label func_label. * gdb.dwarf2/dw2-ifort-parameter.exp (Dwarf::assemble): Replace low_pc and high_pc with MACRO_AT_range. Replace name, low_pc and high_pc with MACRO_AT_func.
2014-11-14 01:53:09 +01:00
2014-11-14 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dw2-ifort-parameter.c: Remove inline asm.
(func): Add label func_label.
* gdb.dwarf2/dw2-ifort-parameter.exp (Dwarf::assemble):
Replace low_pc and high_pc with MACRO_AT_range.
Replace name, low_pc and high_pc with MACRO_AT_func.
Fix implptr-optimized-out.exp fail Hi, I see the fail in gdb.dwarf2/implptr-optimized-out.exp in thumb mode (gdb) p p->f^M No symbol "p" in current context.^M (gdb) FAIL: gdb.dwarf2/implptr-optimized-out.exp: p p->f and the crash on powerpc64 (gdb) continue^M Continuing.^M ^M Program received signal SIGSEGV, Segmentation fault.^M 0x7d82100810000828 in ?? () The cause of both is that we incorrectly set attribute low_pc, since main isn't resolved to function start address on these targets. In this patch, we replace attributes name, low_pc and high_pc with MACRO_AT_func. The fail on thumb mode is fixed, and crash on powerpc64 is fixed too. gdb/testsuite: 2014-11-14 Yao Qi <yao@codesourcery.com> * gdb.dwarf2/implptr-optimized-out.exp (Dwarf::assemble): Replace name, low_pc and high_pc with MACRO_AT_func.
2014-11-14 01:53:08 +01:00
2014-11-14 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/implptr-optimized-out.exp (Dwarf::assemble):
Replace name, low_pc and high_pc with MACRO_AT_func.
Use Dwarf::assemble in implptr-optimized-out.exp This patch is to use dwarf::assemble to generate debug information, and remove implptr-optimized-out.S as a result. gdb/testsuite: 2014-11-14 Yao Qi <yao@codesourcery.com> * gdb.dwarf2/implptr-optimized-out.exp: Use Dwarf::assemble to produce debug information. * gdb.dwarf2/implptr-optimized-out.S: Removed.
2014-11-14 01:53:08 +01:00
2014-11-14 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/implptr-optimized-out.exp: Use Dwarf::assemble to
produce debug information.
* gdb.dwarf2/implptr-optimized-out.S: Removed.
Get start and end address of main in dwz.exp On arm-none-eabi target thumb mode, I see the following fail, p the_int^M $2 = 99^M (gdb) FAIL: gdb.dwarf2/dwz.exp: p the_int and on powerpc64 target, we even can't get function main from object file, disassemble main^M No function contains specified address.^M (gdb) FAIL: gdb.dwarf2/dwz.exp: disassemble main This patch is to use MACRO_AT_func attribute to get the main's start address and end address correctly, and also remove some code dwz.exp getting main's length. This patch fixes fails on both thumb mode and powerpc64 target. PASS: gdb.dwarf2/dwz.exp: p other_int PASS: gdb.dwarf2/dwz.exp: p the_int gdb/testsuite: 2014-11-14 Yao Qi <yao@codesourcery.com> * gdb.dwarf2/dwz.exp: Remove the code to compile main.c to object and get function length. (Dwarf::assemble): Replace name, low_pc and high_pc attributes with MACRO_AT_func. (top-level): Replace gdb_compile and clean_restart with prepare_for_testing. * gdb.dwarf2/main.c (main): Add label main_label.
2014-11-14 01:53:08 +01:00
2014-11-14 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dwz.exp: Remove the code to compile main.c to
object and get function length.
(Dwarf::assemble): Replace name, low_pc and high_pc attributes
with MACRO_AT_func.
(top-level): Replace gdb_compile and clean_restart with
prepare_for_testing.
* gdb.dwarf2/main.c (main): Add label main_label.
DW attribute macro MACRO_AT_func and MACRO_AT_range This patch addes DW macro attributes MACRO_AT_func and MACRO_AT_range in dwarf assembler, which emits "DW_AT_low_pc func_start addr" and "DW_AT_high_pc func_end addr". func_start and func_end are computed automatically by proc function_range. These two attributes are pseudo attribute or macro attribute, which means they are not standard dwarf attribute in dwarf spec. Then can be substituted or expanded to standard attributes or macro attributes. See details in the comments to them. Dwarf assembler is extended to handle them. Now the attributes name/low_pc/high_pc can be replaced with MACRO_AT_func like this: subprogram { {name main} {low_pc main_start addr} {high_pc main_end addr} } becomes: subprogram { {MACRO_AT_func { main ${srcdir}/${subdir}/${srcfile} }} } users don't have to worry about the start and end of function main, and they only need to add a label main_label in main. gdb/testsuite: 2014-11-14 Yao Qi <yao@codesourcery.com> * lib/dwarf.exp (function_range): New procedure. (Dwarf::_handle_macro_at_func): New procedure. (Dwarf::_handle_macro_at_range): New procedure. (Dwarf): Handle MACRO_AT_func and MACRO_AT_range.
2014-11-14 01:53:08 +01:00
2014-11-14 Yao Qi <yao@codesourcery.com>
* lib/dwarf.exp (function_range): New procedure.
(Dwarf::_handle_macro_at_func): New procedure.
(Dwarf::_handle_macro_at_range): New procedure.
(Dwarf): Handle MACRO_AT_func and MACRO_AT_range.
New proc _handle_attribute This patch is to move some code to a new procedure _handle_attribute, which will be used in my following patches. gdb/testsuite: 2014-11-14 Yao Qi <yao@codesourcery.com> * lib/dwarf.exp (_handle_DW_TAG): Move some code to ... (_handle_attribute): New procedure.
2014-11-14 01:53:08 +01:00
2014-11-14 Yao Qi <yao@codesourcery.com>
* lib/dwarf.exp (_handle_DW_TAG): Move some code to ...
(_handle_attribute): New procedure.
GDB testsuite: Fix warnings with -std=gnu11 Since upstream GCC has changed the default C language dialect to 'gnu11', it yields multiple warnings in the GDB testsuite for missing function return types and implicit function declarations. This patch attempts to fix these. gdb/testsuite/ChangeLog: * gdb.ada/cond_lang/foo.c (callme): Add return type. * gdb.base/call-sc.c (zed): Likewise. * gdb.base/checkpoint.c (main): Likewise. * gdb.base/dump.c (main): Likewise. * gdb.base/gcore.c (main): Likewise. * gdb.base/huge.c (main): Likewise. * gdb.base/multi-forks.c (main): Likewise. * gdb.base/pr10179-a.c (main): Likewise. * gdb.base/savedregs.c (main): Likewise. * gdb.base/sigaltstack.c (main): Likewise. * gdb.base/siginfo.c (main): Likewise. * gdb.base/structs.c (zed): Likewise. * gdb.mi/mi-stack.c (callee3, callee2, callee1, main): Likewise. * gdb.mi/mi-syn-frame.c (main): Likewise. * gdb.mi/until.c (foo, main): Likewise. * gdb.base/global-var-nested-by-dso.c (b_main, c_main): Declare. * gdb.base/solib-weak.c (foo): Declare. * gdb.base/attach-twice.c: Include stdio.h. * gdb.base/weaklib1.c: Likewise. * gdb.base/weaklib2.c: Likewise. * gdb.base/catch-signal-fork.c: Include stdio.h and sys/wait.h. * gdb.mi/mi-condbreak-call-thr-state-mt.c: Include stdio.h and unistd.h. * gdb.base/attach-pie-misread.c: Include stdlib.h. * gdb.mi/mi-exit-code.c: Likewise. * gdb.base/break-interp-lib.c: Include string.h. * gdb.base/coremaker.c: Likewise. * gdb.base/testenv.c: Likewise. * gdb.python/py-finish-breakpoint.c: Likewise. * gdb.base/inferior-died.c: Include sys/wait.h. * gdb.base/fileio.c: Include time.h. * gdb.base/async-shell.c: Include unistd.h. * gdb.base/dprintf-non-stop.c: Likewise. * gdb.base/info-os.c: Likewise. * gdb.mi/mi-console.c: Likewise. * gdb.mi/watch-nonstop.c: Likewise. * gdb.python/py-events.c: Likewise. * gdb.base/async.c (baz): Move up before its invocation. * gdb.base/code_elim2.c (my_global_func): Likewise. * gdb.base/skip-solib-lib.c (multiply): Likewise. * gdb.base/advance.c (func2): Likewise.
2014-10-28 13:39:22 +01:00
2014-11-13 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.ada/cond_lang/foo.c (callme): Add return type.
* gdb.base/call-sc.c (zed): Likewise.
* gdb.base/checkpoint.c (main): Likewise.
* gdb.base/dump.c (main): Likewise.
* gdb.base/gcore.c (main): Likewise.
* gdb.base/huge.c (main): Likewise.
* gdb.base/multi-forks.c (main): Likewise.
* gdb.base/pr10179-a.c (main): Likewise.
* gdb.base/savedregs.c (main): Likewise.
* gdb.base/sigaltstack.c (main): Likewise.
* gdb.base/siginfo.c (main): Likewise.
* gdb.base/structs.c (zed): Likewise.
* gdb.mi/mi-stack.c (callee3, callee2, callee1, main): Likewise.
* gdb.mi/mi-syn-frame.c (main): Likewise.
* gdb.mi/until.c (foo, main): Likewise.
* gdb.base/global-var-nested-by-dso.c (b_main, c_main): Declare.
* gdb.base/solib-weak.c (foo): Declare.
* gdb.base/attach-twice.c: Include stdio.h.
* gdb.base/weaklib1.c: Likewise.
* gdb.base/weaklib2.c: Likewise.
* gdb.base/catch-signal-fork.c: Include stdio.h and sys/wait.h.
* gdb.mi/mi-condbreak-call-thr-state-mt.c: Include stdio.h and
unistd.h.
* gdb.base/attach-pie-misread.c: Include stdlib.h.
* gdb.mi/mi-exit-code.c: Likewise.
* gdb.base/break-interp-lib.c: Include string.h.
* gdb.base/coremaker.c: Likewise.
* gdb.base/testenv.c: Likewise.
* gdb.python/py-finish-breakpoint.c: Likewise.
* gdb.base/inferior-died.c: Include sys/wait.h.
* gdb.base/fileio.c: Include time.h.
* gdb.base/async-shell.c: Include unistd.h.
* gdb.base/dprintf-non-stop.c: Likewise.
* gdb.base/info-os.c: Likewise.
* gdb.mi/mi-console.c: Likewise.
* gdb.mi/watch-nonstop.c: Likewise.
* gdb.python/py-events.c: Likewise.
* gdb.base/async.c (baz): Move up before its invocation.
* gdb.base/code_elim2.c (my_global_func): Likewise.
* gdb.base/skip-solib-lib.c (multiply): Likewise.
* gdb.base/advance.c (func2): Likewise.
GDB testsuite: drop non-prototype C function header variants Remove many old-style function header variants in C source files of the GDB test suite, using the 'unifdef' tool with '-DPROTOTYPES=1'. gdb/testsuite/ChangeLog: * gdb.base/annota1.c: Remove #ifdef PROTOTYPES, keep prototyped variant. * gdb.base/annota3.c: Likewise. * gdb.base/async.c: Likewise. * gdb.base/average.c: Likewise. * gdb.base/call-ar-st.c: Likewise. * gdb.base/call-rt-st.c: Likewise. * gdb.base/call-sc.c: Likewise. * gdb.base/call-strs.c: Likewise. * gdb.base/ending-run.c: Likewise. * gdb.base/execd-prog.c: Likewise. * gdb.base/exprs.c: Likewise. * gdb.base/foll-exec.c: Likewise. * gdb.base/foll-fork.c: Likewise. * gdb.base/foll-vfork.c: Likewise. * gdb.base/funcargs.c: Likewise. * gdb.base/gcore.c: Likewise. * gdb.base/jump.c: Likewise. * gdb.base/langs0.c: Likewise. * gdb.base/langs1.c: Likewise. * gdb.base/langs2.c: Likewise. * gdb.base/mips_pro.c: Likewise. * gdb.base/nodebug.c: Likewise. * gdb.base/opaque0.c: Likewise. * gdb.base/opaque1.c: Likewise. * gdb.base/recurse.c: Likewise. * gdb.base/run.c: Likewise. * gdb.base/scope0.c: Likewise. * gdb.base/scope1.c: Likewise. * gdb.base/setshow.c: Likewise. * gdb.base/setvar.c: Likewise. * gdb.base/shmain.c: Likewise. * gdb.base/shr1.c: Likewise. * gdb.base/shr2.c: Likewise. * gdb.base/sigall.c: Likewise. * gdb.base/signals.c: Likewise. * gdb.base/so-indr-cl.c: Likewise. * gdb.base/solib2.c: Likewise. * gdb.base/structs.c: Likewise. * gdb.base/sum.c: Likewise. * gdb.base/vforked-prog.c: Likewise. * gdb.base/watchpoint.c: Likewise. * gdb.reverse/shr2.c: Likewise. * gdb.reverse/until-reverse.c: Likewise. * gdb.reverse/ur1.c: Likewise. * gdb.reverse/watch-reverse.c: Likewise.
2014-10-24 14:07:53 +02:00
2014-11-13 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/annota1.c: Remove #ifdef PROTOTYPES, keep prototyped
variant.
* gdb.base/annota3.c: Likewise.
* gdb.base/async.c: Likewise.
* gdb.base/average.c: Likewise.
* gdb.base/call-ar-st.c: Likewise.
* gdb.base/call-rt-st.c: Likewise.
* gdb.base/call-sc.c: Likewise.
* gdb.base/call-strs.c: Likewise.
* gdb.base/ending-run.c: Likewise.
* gdb.base/execd-prog.c: Likewise.
* gdb.base/exprs.c: Likewise.
* gdb.base/foll-exec.c: Likewise.
* gdb.base/foll-fork.c: Likewise.
* gdb.base/foll-vfork.c: Likewise.
* gdb.base/funcargs.c: Likewise.
* gdb.base/gcore.c: Likewise.
* gdb.base/jump.c: Likewise.
* gdb.base/langs0.c: Likewise.
* gdb.base/langs1.c: Likewise.
* gdb.base/langs2.c: Likewise.
* gdb.base/mips_pro.c: Likewise.
* gdb.base/nodebug.c: Likewise.
* gdb.base/opaque0.c: Likewise.
* gdb.base/opaque1.c: Likewise.
* gdb.base/recurse.c: Likewise.
* gdb.base/run.c: Likewise.
* gdb.base/scope0.c: Likewise.
* gdb.base/scope1.c: Likewise.
* gdb.base/setshow.c: Likewise.
* gdb.base/setvar.c: Likewise.
* gdb.base/shmain.c: Likewise.
* gdb.base/shr1.c: Likewise.
* gdb.base/shr2.c: Likewise.
* gdb.base/sigall.c: Likewise.
* gdb.base/signals.c: Likewise.
* gdb.base/so-indr-cl.c: Likewise.
* gdb.base/solib2.c: Likewise.
* gdb.base/structs.c: Likewise.
* gdb.base/sum.c: Likewise.
* gdb.base/vforked-prog.c: Likewise.
* gdb.base/watchpoint.c: Likewise.
* gdb.reverse/shr2.c: Likewise.
* gdb.reverse/until-reverse.c: Likewise.
* gdb.reverse/ur1.c: Likewise.
* gdb.reverse/watch-reverse.c: Likewise.
Drop non-prototype C function header variants: 'sepdebug' test case Remove old-style function header variants from sepdebug.c. Eliminate references to the removed locations "breakpoint 9" and "breakpoint 13" from sepdebug.exp. gdb/testsuite/ChangeLog: * gdb.base/sepdebug.c: Remove #ifdef PROTOTYPES, keep prototyped variant. * gdb.base/sepdebug.exp: Drop references to removed code.
2014-10-23 13:02:31 +02:00
2014-11-13 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/sepdebug.c: Remove #ifdef PROTOTYPES, keep prototyped
variant.
* gdb.base/sepdebug.exp: Drop references to removed code.
Drop non-prototype C function header variants: 'list' test case Remove old-style function header variants from list0.h and list1.c. Fill the removed lines with comments or empty lines, such that the line numbering is undisturbed. Changes to the line numbering would require heavy adjustments to list.exp, where many line numbers are hard-coded, as well as a fair amount of knowledge about the source code in and around certain lines. Thus the dependency on the line numbering can not be eliminated so easily, and it may not even be a useful goal for a "list" test case. Another option might be to adjust the literal line numbers in list.exp, but even that is not as straightforward as it may seem, since the test case expects certain source lines to be exactly n lines apart. gdb/testsuite/ChangeLog: * gdb.base/list0.h: Remove #ifdef PROTOTYPES, keep prototyped variant. Preserve original line numbering. * gdb.base/list1.c: Likewise.
2014-10-22 19:13:34 +02:00
2014-11-13 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/list0.h: Remove #ifdef PROTOTYPES, keep prototyped
variant. Preserve original line numbering.
* gdb.base/list1.c: Likewise.
Drop non-prototype C function header variants: 'break' test case Remove old-style function headers from break.c and break1.c. Adjust break.exp accordingly; in particular eliminate references to the removed locations "breakpoint 9, 13, and 16" from break.exp. gdb/testsuite/ChangeLog: * gdb.base/break.c: Remove #ifdef PROTOTYPES, keep prototyped variant. * gdb.base/break1.c: Likewise. * gdb.base/break.exp: Drop references to removed code.
2014-10-22 11:24:25 +02:00
2014-11-13 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/break.c: Remove #ifdef PROTOTYPES, keep prototyped
variant.
* gdb.base/break1.c: Likewise.
* gdb.base/break.exp: Drop references to removed code.
Drop non-prototype C function header variants: solib1.c Clean up solib1.c by removing the #ifdef PROTOTYPES conditional. gdb/testsuite/ChangeLog: * gdb.base/solib1.c: Remove #ifdef PROTOTYPES, keep prototyped variant.
2014-10-23 16:27:57 +02:00
2014-11-13 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/solib1.c: Remove #ifdef PROTOTYPES, keep prototyped
variant.
callfuncs.exp: Indent perform_all_tests() The previous patch did not indent perform_all_tests() correctly after moving the main logic into it, to avoid obscuring the functional changes. This patch fixes the indentation. gdb/testsuite/ChangeLog: * gdb.base/callfuncs.exp (perform_all_tests): Re-indent.
2014-11-04 14:50:42 +01:00
2014-11-13 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/callfuncs.exp (perform_all_tests): Re-indent.
Perform all tests in callfuncs.exp with and without C function prototypes In callfuncs.exp, compile callfuncs.c with and without C function header prototypes and execute all tests after each compilation. gdb/testsuite/ChangeLog: * gdb.base/callfuncs.exp: Remove 'prototypes' variable. Move main logic into perform_all_tests() and invoke it with and without function header prototypes. (do_function_calls): Remove conditional XFAIL for PR 5318. (rerun_and_prepare): Remove duplicate code. (perform_all_tests): New. Main logic moved here.
2014-11-04 13:55:30 +01:00
2014-11-13 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/callfuncs.exp: Remove 'prototypes' variable. Move main
logic into perform_all_tests() and invoke it with and without
function header prototypes.
(do_function_calls): Remove conditional XFAIL for PR 5318.
(rerun_and_prepare): Remove duplicate code.
(perform_all_tests): New. Main logic moved here.
'callfuncs' test case: Fixes in conditionally compiled code The C source file for the 'callfuncs' test case did not compile with -DNO_PROTOTYPES or -DPROTOTYPES. This patch fixes various syntax errors under #ifdef NO_PROTOTYPES and a small typo under #ifdef PROTOTYPES. gdb/testsuite/ChangeLog: * gdb.base/callfuncs.c (t_float_many_args): Fix syntax error in code guarded by #ifdef NO_PROTOTYPES. (t_double_many_args): Likewise. (DEF_FUNC_MANY_ARGS_1): Likewise. (DEF_FUNC_VALUES_1): Likewise. (t_structs_ldc): Renamed from t_structs_fc in conditional code guarded by #ifdef PROTOTYPES.
2014-10-22 19:46:29 +02:00
2014-11-13 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/callfuncs.c (t_float_many_args): Fix syntax error in
code guarded by #ifdef NO_PROTOTYPES.
(t_double_many_args): Likewise.
(DEF_FUNC_MANY_ARGS_1): Likewise.
(DEF_FUNC_VALUES_1): Likewise.
(t_structs_ldc): Renamed from t_structs_fc in conditional code
guarded by #ifdef PROTOTYPES.
Eliminate literal line numbers in mi-console.exp Remove the literal line number from a regexp in mi-console.exp. Add an appropriate eye-catcher to mi-console.c and refer to that instead. gdb/testsuite/ChangeLog: * gdb.mi/mi-console.c: Add eye-catcher. * gdb.mi/mi-console.exp (semihosted_string): Refer to eye-catcher instead of literal line number.
2014-10-28 16:19:08 +01:00
2014-11-13 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.mi/mi-console.c: Add eye-catcher.
* gdb.mi/mi-console.exp (semihosted_string): Refer to eye-catcher
instead of literal line number.
Eliminate literal line numbers in shlib-call.exp Remove the literal line number from a regexp in shlib-call.exp. Add an appropriate eye-catcher to shr2.c and refer to that instead. gdb/testsuite/ChangeLog: * gdb.base/shr2.c: Add eye-catcher. * gdb.base/shlib-call.exp: Refer to eye-catcher instead of literal line number.
2014-10-24 14:05:10 +02:00
2014-11-13 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/shr2.c: Add eye-catcher.
* gdb.base/shlib-call.exp: Refer to eye-catcher instead of literal
line number.
Eliminate literal line numbers in jump.exp Remove literal line numbers from the regexps in jump.exp. Add appropriate eye-catchers to jump.c and refer to those instead. gdb/testsuite/ChangeLog: * gdb.base/jump.c: Add eye-catchers. * gdb.base/jump.exp: Refer to eye-catchers instead of literal line numbers.
2014-10-24 13:57:22 +02:00
2014-11-13 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/jump.c: Add eye-catchers.
* gdb.base/jump.exp: Refer to eye-catchers instead of literal line
numbers.
Eliminate literal line numbers in foll-exec.exp Remove literal line numbers from the regexps in foll-exec.exp. Add appropriate eye-catchers to foll-exec.c and execd-proc.c and refer to those instead. gdb/testsuite/ChangeLog: * gdb.base/execd-prog.c: Add eye-catchers. * gdb.base/foll-exec.c: Likewise. * gdb.base/foll-exec.exp: Refer to eye-catchers instead of literal line numbers.
2014-10-24 13:04:56 +02:00
2014-11-13 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/execd-prog.c: Add eye-catchers.
* gdb.base/foll-exec.c: Likewise.
* gdb.base/foll-exec.exp: Refer to eye-catchers instead of literal
line numbers.
Eliminate literal line numbers in ending-run.exp Remove literal line numbers from the regexps in ending-run.exp. Add appropriate eye-catchers to ending-run.c and refer to those instead. gdb/testsuite/ChangeLog: * gdb.base/ending-run.c: Add eye-catchers. * gdb.base/ending-run.exp: Refer to eye-catchers instead of literal line numbers.
2014-10-24 11:24:01 +02:00
2014-11-13 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/ending-run.c: Add eye-catchers.
* gdb.base/ending-run.exp: Refer to eye-catchers instead of
literal line numbers.
Eliminate literal line numbers in call-rt-st.exp Remove literal line numbers from the regexps in call-rt-st.exp. Add appropriate eye-catchers to call-rt-st.c and refer to those instead. gdb/testsuite/ChangeLog: * gdb.base/call-rt-st.c: Add eye-catchers. * gdb.base/call-rt-st.exp: Refer to eye-catchers instead of literal line numbers.
2014-10-24 11:15:10 +02:00
2014-11-13 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/call-rt-st.c: Add eye-catchers.
* gdb.base/call-rt-st.exp: Refer to eye-catchers instead of
literal line numbers.
Eliminate literal line numbers in call-ar-st.exp Remove literal line numbers from the regexps in call-ar-st.exp. Add appropriate eye-catchers to call-ar-st.c and refer to those instead. gdb/testsuite/ChangeLog: * gdb.base/call-ar-st.c: Add eye-catchers. * gdb.base/call-ar-st.exp: Refer to eye-catchers instead of literal line numbers.
2014-10-23 18:00:21 +02:00
2014-11-13 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/call-ar-st.c: Add eye-catchers.
* gdb.base/call-ar-st.exp: Refer to eye-catchers instead of
literal line numbers.
Eliminate literal line numbers in dbx.exp Remove literal line numbers from the commands and regexps in dbx.exp. Add appropriate eye-catchers to average.c and sum.c and refer to those instead. gdb/testsuite/ChangeLog: * gdb.base/average.c: Add eye-catchers. * gdb.base/sum.c: Likewise. * gdb.base/dbx.exp: Use eye-catchers to determine line numbers for regexps dynamically.
2014-10-29 19:16:20 +01:00
2014-11-13 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/average.c: Add eye-catchers.
* gdb.base/sum.c: Likewise.
* gdb.base/dbx.exp: Use eye-catchers to determine line numbers for
regexps dynamically.
Eliminate literal line numbers in so-impl-ld.exp Remove literal line numbers from the regexps in so-impl-ld.exp. Add appropriate eye-catchers to solib1.c and refer to those instead. gdb/testsuite/ChangeLog: * gdb.base/solib1.c: Add eye-catchers. * gdb.base/so-impl-ld.exp: Match against eye-catchers instead of literal line numbers.
2014-10-23 15:56:52 +02:00
2014-11-13 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/solib1.c: Add eye-catchers.
* gdb.base/so-impl-ld.exp: Match against eye-catchers instead of
literal line numbers.
GDBserver: ctrl-c after leader has exited The target->request_interrupt callback implements the handling for ctrl-c. User types ctrl-c in GDB, GDB sends a \003 to the remote target, and the remote targets stops the program with a SIGINT, just like if the user typed ctrl-c in GDBserver's terminal. The trouble is that using kill_lwp(signal_pid, SIGINT) sends the SIGINT directly to the program's main thread. If that thread has exited already, then that kill won't do anything. Instead, send the SIGINT to the process group, just like GDB does (see inf-ptrace.c:inf_ptrace_stop). gdb.threads/leader-exit.exp is extended to cover the scenario. It fails against GDBserver before the patch. Tested on x86_64 Fedora 20, native and GDBserver. gdb/gdbserver/ 2014-11-12 Pedro Alves <palves@redhat.com> * linux-low.c (linux_request_interrupt): Always send a SIGINT to the process group instead of to a specific LWP. gdb/testsuite/ 2014-11-12 Pedro Alves <palves@redhat.com> * gdb.threads/leader-exit.exp: Test sending ctrl-c works after the leader has exited.
2014-11-12 12:17:39 +01:00
2014-11-12 Pedro Alves <palves@redhat.com>
* gdb.threads/leader-exit.exp: Test sending ctrl-c works after the
leader has exited.
fix skipping permanent breakpoints The gdb.arch/i386-bp_permanent.exp test is currently failing an assertion recently added: (gdb) stepi ../../src/gdb/infrun.c:2237: internal-error: resume: Assertion `sig != GDB_SIGNAL_0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) FAIL: gdb.arch/i386-bp_permanent.exp: Single stepping past permanent breakpoint. (GDB internal error) The assertion expects that the only reason we currently need to step a breakpoint instruction is when we have a signal to deliver. But when stepping a permanent breakpoint (with or without a signal) we also reach this code. The assertion is correct and the permanent breakpoints skipping code is wrong. Consider the case of the user doing "step/stepi" when stopped at a permanent breakpoint. GDB's `resume' calls the gdbarch_skip_permanent_breakpoint hook and then happily continues stepping: /* Normally, by the time we reach `resume', the breakpoints are either removed or inserted, as appropriate. The exception is if we're sitting at a permanent breakpoint; we need to step over it, but permanent breakpoints can't be removed. So we have to test for it here. */ if (breakpoint_here_p (aspace, pc) == permanent_breakpoint_here) { gdbarch_skip_permanent_breakpoint (gdbarch, regcache); } But since gdbarch_skip_permanent_breakpoint already advanced the PC manually, this ends up executing the instruction that is _after_ the breakpoint instruction. The user-visible result is that a single-step steps two instructions. The gdb.arch/i386-bp_permanent.exp test is actually ensuring that that's indeed how things work. It runs to an int3 instruction, does "stepi", and checks that "leave" was executed with that "stepi". Like this: (gdb) b *0x0804848c Breakpoint 2 at 0x804848c (gdb) c Continuing. Breakpoint 2, 0x0804848c in standard () (gdb) disassemble Dump of assembler code for function standard: 0x08048488 <+0>: push %ebp 0x08048489 <+1>: mov %esp,%ebp 0x0804848b <+3>: push %edi => 0x0804848c <+4>: int3 0x0804848d <+5>: leave 0x0804848e <+6>: ret 0x0804848f <+7>: nop (gdb) si 0x0804848e in standard () (gdb) disassemble Dump of assembler code for function standard: 0x08048488 <+0>: push %ebp 0x08048489 <+1>: mov %esp,%ebp 0x0804848b <+3>: push %edi 0x0804848c <+4>: int3 0x0804848d <+5>: leave => 0x0804848e <+6>: ret 0x0804848f <+7>: nop End of assembler dump. (gdb) One would instead expect that a stepi at 0x0804848c stops at 0x0804848d, _before_ the "leave" is executed. This commit changes GDB this way. Care is taken to make stepping into a signal handler when the step starts at a permanent breakpoint instruction work correctly. The patch adjusts gdb.arch/i386-bp_permanent.exp in this direction, and also makes it work on x86_64 (currently it only works on i*86). The patch also adds a new gdb.base/bp-permanent.exp test that exercises many different code paths related to stepping permanent breakpoints, including the stepping with signals cases. The test uses "hack/trick" to make it work on all (or most) platforms -- it doesn't really hard code a breakpoint instruction. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-11-12 Pedro Alves <palves@redhat.com> * infrun.c (resume): Clear the thread's 'stepped_breakpoint' flag. Rewrite stepping over a permanent breakpoint. (thread_still_needs_step_over, proceed): Don't set stepping_over_breakpoint for permanent breakpoints. (handle_signal_stop): Don't clear stepped_breakpoint. Also pull single-step breakpoints out of the target on hardware step targets. (process_event_stop_test): If stepping a permanent breakpoint doesn't hit the step-resume breakpoint, delete the step-resume breakpoint. (switch_back_to_stepped_thread): Also check if the stepped thread has advanced already on hardware step targets. (currently_stepping): Return true if the thread stepped a breakpoint. gdb/testsuite/ 2014-11-12 Pedro Alves <palves@redhat.com> * gdb.arch/i386-bp_permanent.c: New file. * gdb.arch/i386-bp_permanent.exp: Don't skip on x86_64. (srcfile): Set to i386-bp_permanent.c. (top level): Adjust to work in both 32-bit and 64-bit modes. Test that stepi does not execute the 'leave' instruction, instead of testing it does execute. * gdb.base/bp-permanent.c: New file. * gdb.base/bp-permanent.exp: New file.
2014-11-12 11:10:49 +01:00
2014-11-12 Pedro Alves <palves@redhat.com>
* gdb.arch/i386-bp_permanent.c: New file.
* gdb.arch/i386-bp_permanent.exp: Don't skip on x86_64.
(srcfile): Set to i386-bp_permanent.c.
(top level): Adjust to work in both 32-bit and 64-bit modes. Test
that stepi does not execute the 'leave' instruction, instead of
testing it does execute.
* gdb.base/bp-permanent.c: New file.
* gdb.base/bp-permanent.exp: New file.
PR 17564: Fix objfile search order for static symbols. When searching static symbols, gdb would search over all expanded symtabs of all objfiles, and if that fails only then would it search all partial/gdb_index tables of all objfiles. This means that the user could get a random instance of the symbol depending on what symtabs have been previously expanded. Now the search is consistent, searching each objfile completely before proceeding to the next one. gdb/ChangeLog: PR symtab/17564 * symtab.c (lookup_symbol_in_all_objfiles): Delete. (lookup_static_symbol): Move definition to new location and rewrite. (lookup_symbol_in_objfile): New function. (lookup_symbol_global_iterator_cb): Call it. gdb/testsuite/ChangeLog: PR symtab/17564 * gdb.base/symtab-search-order.exp: New file. * gdb.base/symtab-search-order.c: New file. * gdb.base/symtab-search-order-1.c: New file. * gdb.base/symtab-search-order-shlib-1.c: New file.
2014-11-11 00:48:49 +01:00
2014-11-10 Doug Evans <xdje42@gmail.com>
PR symtab/17564
* gdb.base/symtab-search-order.exp: New file.
* gdb.base/symtab-search-order.c: New file.
* gdb.base/symtab-search-order-1.c: New file.
* gdb.base/symtab-search-order-shlib-1.c: New file.
gdb.base/sigstep.exp: xfail gdb/17511 on i?86 Linux Running gdb.base/sigstep.exp with --target=i686-pc-linux-gnu on a 64-bit kernel naturally trips on PR gdb/17511 as well, given this is a kernel bug. I haven't really tested a real 32-bit kernel/machine, but given the code in question in the kernel is shared between 32-bit and 64-bit, I'm quite sure the bug triggers in those cases as well. So, simply xfail i?86-*-linux* too. gdb/testsuite/ 2014-11-07 Pedro Alves <palves@redhat.com> PR gdb/17511 * gdb.base/sigstep.exp (in_handler_map) <si+advance>: xfail i?86-*-linux*.
2014-11-07 16:20:47 +01:00
2014-11-07 Pedro Alves <palves@redhat.com>
PR gdb/17511
* gdb.base/sigstep.exp (in_handler_map) <si+advance>: xfail
i?86-*-linux*.
Fix evaluation of method calls under EVAL_SKIP. When evaluating method calls under EVAL_SKIP, the "object" and the arguments to the method should also be evaluated under EVAL_SKIP, instead of skipping to evaluate them as was being done previously. gdb/ChangeLog: PR c++/17494 * eval.c (evaluate_subexp_standard): Evaluate the "object" and the method args also under EVAL_SKIP when evaluating method calls under EVAL_SKIP. gdb/testsuite/ChangeLog: PR c++/17494 * gdb.cp/pr17494.cc: New file. * gdb.cp/pr17494.exp: New file.
2014-10-18 15:14:00 +02:00
2014-11-03 Siva Chandra Reddy <sivachandra@google.com>
PR c++/17494
* gdb.cp/pr17494.cc: New file.
* gdb.cp/pr17494.exp: New file.
Match the working directory on remote host The test in gdb.python/python.exp tests "extended-prompt" and expects working directory is printed. However, working directory on remote host doesn't have "gdb/testsuite", so the test fails on remote host like: set extended-prompt \w ^M ^M /home/yao FAIL: gdb.python/python.exp: set extended prompt working directory (timeout) This patch is to get the working directory first, and use it to match the output of "set extended-prompt \\w ". It works for remote host and non remote host. gdb/testsuite: 2014-11-02 Yao Qi <yao@codesourcery.com> * gdb.python/python.exp: Get working directory and match the output of "set extended-prompt \\w " with it.
2014-11-02 14:08:06 +01:00
2014-11-02 Yao Qi <yao@codesourcery.com>
* gdb.python/python.exp: Get working directory and match the
output of "set extended-prompt \\w " with it.
Add ability to add attributes to gdb.Objfile and gdb.Progspace objects. gdb/ChangeLog: * NEWS: Mention ability add attributes to gdb.Objfile and gdb.Progspace objects. * python/py-objfile.c (objfile_object): New member dict. (objfpy_dealloc): Py_XDECREF dict. (objfpy_initialize): Initialize dict. (objfile_getset): Add __dict__. (objfile_object_type): Set tp_dictoffset member. * python/py-progspace.c (progspace_object): New member dict. (pspy_dealloc): Py_XDECREF dict. (pspy_initialize): Initialize dict. (pspace_getset): Add __dict__. (pspace_object_type): Set tp_dictoffset member. gdb/doc/ChangeLog: * python.texi (Progspaces In Python): Document ability to add random attributes to gdb.Progspace objects. (Objfiles In Python): Document ability to add random attributes to gdb.objfile objects. gdb/testsuite/ChangeLog: * gdb.python/py-objfile.exp: Add tests for setting random attributes in objfiles. * gdb.python/py-progspace.exp: Add tests for setting random attributes in progspaces.
2014-10-31 01:05:17 +01:00
2014-10-30 Doug Evans <dje@google.com>
* gdb.python/py-objfile.exp: Add tests for setting random attributes
in objfiles.
* gdb.python/py-progspace.exp: Add tests for setting random attributes
in progspaces.
Skip tests that use cd for remote hosts Several GDB tests change directory before compiling the test program in order to test source file names that include directories. This doesn't work on a remote host because default_target_compile in DejaGnu's target.exp copies each source file with "[remote_download host $x]" which uses "[file tail $file] to strip off the directory of each file. If the source directory is remote mounted on the host, this also leaves copied files in the source directory. A similar skip is already used in gdb.test/fullname.exp: # We rely on being able to copy things around. if { [is_remote host] } { untested "setting breakpoints by full path" return -1 } This patch causes three GDB tests that use "cd" to be skipped for a remote host. For gdb.base/fullpath-expand.exp this eliminates two failures and prevents the test from leaving files fullpath-expand.c and fullpath-expand-func.c in gdb/testsuite. For gdb.base/realname-expand.exp it eliminates two failures. For gdb.linespec/macro-relative.exp it prevents file macro-relative.c from being left in gdb/testsuite/gdb.linespec/base/two. gdb/testsuite/ * gdb.base/fullpath-expand.exp: Skip for a remote host. * gdb.base/realname-expand.exp: Likewise. * gdb.linespec/macro-relative.exp: Likewise.
2014-10-30 12:48:10 +01:00
2014-10-30 Janis Johnson <janisjo@codesourcery.com>
* gdb.base/fullpath-expand.exp: Skip for a remote host.
* gdb.base/realname-expand.exp: Likewise.
* gdb.linespec/macro-relative.exp: Likewise.
This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29 19:25:27 +01:00
2014-10-29 Pedro Alves <palves@redhat.com>
PR gdb/17408
* gdb.threads/schedlock.c (some_function): New function.
(call_function): New global.
(MAYBE_CALL_SOME_FUNCTION): New macro.
(thread_function): Call it.
* gdb.threads/schedlock.exp (get_args): Add description parameter,
and use it instead of a global counter. Adjust all callers.
(get_current_thread): Use "find current thread" for test message
here rather than having all callers pass down the same string.
(goto_loop): New procedure, factored out from ...
(my_continue): ... this.
(step_ten_loops): Change parameter from test message to command to
use. Adjust.
(list_count): Delete global.
(check_result): New procedure, factored out from duplicate top
level code.
(continue tests): Wrap in with_test_prefix.
(test_step): New procedure, factored out from duplicate top level
code.
(top level): Test "step" in combination with all scheduler-locking
modes. Test "next" in combination with all scheduler-locking
modes, and in combination with stepping over a function call or
not.
* gdb.threads/next-bp-other-thread.c: New file.
* gdb.threads/next-bp-other-thread.exp: New file.
PR python/17372 - Python hangs when displaying help() This is more of a readline/terminal issue than a Python one. PR17372 is a regression in 7.8 caused by the fix for PR17072: commit 0017922d0292d8c374584f6100874580659c9973 Author: Pedro Alves <palves@redhat.com> Date: Mon Jul 14 19:55:32 2014 +0100 Background execution + pagination aborts readline/gdb gdb_readline_wrapper_line removes the handler after a line is processed. Usually, we'll end up re-displaying the prompt, and that reinstalls the handler. But if the output is coming out of handling a stop event, we don't re-display the prompt, and nothing restores the handler. So the next input wakes up the event loop and calls into readline, which aborts. ... gdb/ 2014-07-14 Pedro Alves <palves@redhat.com> PR gdb/17072 * top.c (gdb_readline_wrapper_line): Tweak comment. (gdb_readline_wrapper_cleanup): If readline is enabled, reinstall the input handler callback. The problem is that installing the input handler callback also preps the terminal, putting it in raw mode and with echo disabled, which is bad if we're going to call a command that assumes cooked/canonical mode, and echo enabled, like in the case of the PR, Python's interactive shell. Another example I came up with that doesn't depend on Python is starting a subshell with "(gdb) shell /bin/sh" from a multi-line command. Tests covering both these examples are added. The fix is to revert the original fix for PR gdb/17072, and instead restore the callback handler after processing an asynchronous target event. Furthermore, calling rl_callback_handler_install when we already have some input in readline's line buffer discards that input, which is obviously a bad thing to do while the user is typing. No specific test is added for that, because I first tried calling it even if the callback handler was still installed and that resulted in hundreds of failures in the testsuite. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR python/17372 * event-top.c (change_line_handler): Call gdb_rl_callback_handler_remove instead of rl_callback_handler_remove. (callback_handler_installed): New global. (gdb_rl_callback_handler_remove, gdb_rl_callback_handler_install) (gdb_rl_callback_handler_reinstall): New functions. (display_gdb_prompt): Call gdb_rl_callback_handler_remove and gdb_rl_callback_handler_install instead of rl_callback_handler_remove and rl_callback_handler_install. (gdb_disable_readline): Call gdb_rl_callback_handler_remove instead of rl_callback_handler_remove. * event-top.h (gdb_rl_callback_handler_remove) (gdb_rl_callback_handler_install) (gdb_rl_callback_handler_reinstall): New declarations. * infrun.c (reinstall_readline_callback_handler_cleanup): New cleanup function. (fetch_inferior_event): Install it. * top.c (gdb_readline_wrapper_line) Call gdb_rl_callback_handler_remove instead of rl_callback_handler_remove. (gdb_readline_wrapper_cleanup): Don't call rl_callback_handler_install. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR python/17372 * gdb.python/python.exp: Test a multi-line command that spawns interactive Python. * gdb.base/multi-line-starts-subshell.exp: New file.
2014-10-23 18:13:35 +02:00
2014-10-29 Pedro Alves <palves@redhat.com>
PR python/17372
* gdb.python/python.exp: Test a multi-line command that spawns
interactive Python.
* gdb.base/multi-line-starts-subshell.exp: New file.
Prepare directory in case test_system fails In gdb.base/fileio.c, some functions may depend on others. For example, test_rename renames a file to one directory which is created in test_system. That is means, if test_system fails, test_rename fails too, which is not a good practise, IMO. In test_system, system ("mkdir -p XX") is used to create directories needed for test_rename. In this patch, we use dejagnu remote_exec proc to create these directories on host. In my gdb testing, mingw32 host and arm-none-eabi target, system ("mkdir -p XX") doesn't work properly (this issue can be addressed separately), and this patch fixes the following fails. FAIL: gdb.base/fileio.exp: Renaming a directory to a non-empty directory returns ENOTEMPTY or EEXIST FAIL: gdb.base/fileio.exp: Unlink a file FAIL: gdb.base/fileio.exp: Unlinking a file in a directory w/o write access returns EACCES gdb/testsuite: 2014-10-29 Yao Qi <yao@codesourcery.com> * gdb.base/fileio.exp: Make directories on host.
2014-10-29 14:43:05 +01:00
2014-10-29 Yao Qi <yao@codesourcery.com>
* gdb.base/fileio.exp: Make directories on host.
Close the file in fileio.exp test I see the following fail in fileio.exp on mingw32 host gdb, rename 1: ret = -1, errno = 13^M ^M Breakpoint 2, stop () at fileio.c:76^M 76 static void stop () {}^M (gdb) FAIL: gdb.base/fileio.exp: Rename a file the test fails to rename a file which is not expected. The previous test test_write doesn't close the file, so the rename fails as a result on Windows. This patch fixes it by closing file in test_write, and the fail goes away. rename 1: ret = 0, errno = 0 OK^M ^M Breakpoint 2, stop () at fileio.c:76^M 76 static void stop () {}^M (gdb) PASS: gdb.base/fileio.exp: Rename a file gdb/testsuite: 2014-10-29 Yao Qi <yao@codesourcery.com> * gdb.base/fileio.c (test_write): Close the file.
2014-10-29 14:43:05 +01:00
2014-10-29 Yao Qi <yao@codesourcery.com>
* gdb.base/fileio.c (test_write): Close the file.
PR gdb/12623: non-stop crashes inferior, PC adjustment and 1-byte insns TL;DR - if we step an instruction that is as long as decr_pc_after_break (1-byte on x86) right after removing the breakpoint at PC, in non-stop mode, adjust_pc_after_break adjusts the PC, but it shouldn't. In non-stop mode, when a breakpoint is removed, it is moved to the "moribund locations" list. This is because other threads that are running may have tripped on that breakpoint as well, and we haven't heard about it. When a trap is reported, we check if perhaps it was such a deleted breakpoint that caused the trap. If so, we also need to adjust the PC (decr_pc_after_break). Now, say that, on x86: - a breakpoint was placed at an address where we have an instruction of the same length as decr_pc_after_break on this arch (1 on x86). - the breakpoint is removed, and thus put on the moribund locations list. - the thread is single-stepped. As there's no breakpoint inserted at PC anymore, the single-step actually executes the 1-byte instruction normally. GDB should _not_ adjust the PC for the resulting SIGTRAP. But, adjust_pc_after_break confuses the step SIGTRAP reported for this single-step as being a SIGTRAP for the moribund location of the breakpoint that used to be at the previous PC, and so infrun applies the decr_pc_after_break adjustment incorrectly. The confusion comes from the special case mentioned in the comment: static void adjust_pc_after_break (struct execution_control_state *ecs) { ... As a special case, we could have hardware single-stepped a software breakpoint. In this case (prev_pc == breakpoint_pc), we also need to back up to the breakpoint address. */ if (thread_has_single_step_breakpoints_set (ecs->event_thread) || !ptid_equal (ecs->ptid, inferior_ptid) || !currently_stepping (ecs->event_thread) || (ecs->event_thread->stepped_breakpoint && ecs->event_thread->prev_pc == breakpoint_pc)) regcache_write_pc (regcache, breakpoint_pc); The condition that incorrectly triggers is the "ecs->event_thread->prev_pc == breakpoint_pc" one. Afterwards, the next resume resume re-executes an instruction that had already executed, which if you're lucky, results in the inferior crashing. If you're unlucky, you'll get silent bad behavior... The fix is to remember that we stepped a breakpoint. Turns out the only case we step a breakpoint instruction today isn't covered by the testsuite. It's the case of a 'handle nostop" signal arriving while a step is in progress _and_ we have a software watchpoint, which forces always single-stepping. This commit extends sigstep.exp to cover that, and adds a new test for the adjust_pc_after_break issue. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/12623 * gdbthread.h (struct thread_info) <stepped_breakpoint>: New field. * infrun.c (resume) <stepping breakpoint instruction>: Set the thread's stepped_breakpoint field. Skip if reverse debugging. Add comment. (init_thread_stepping_state, handle_signal_stop): Clear the thread's stepped_breakpoint field. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/12623 * gdb.base/sigstep.c (no_handler): New global. (main): If 'no_handler is true, set the signal handlers to SIG_IGN. * gdb.base/sigstep.exp (breakpoint_over_handler): Add with_sw_watch and no_handler parameters. Handle them. (top level) <stepping over handler when stopped at a breakpoint test>: Add a test axis for testing with a software watchpoint, and another for testing with the signal handler set to SIG_IGN. * gdb.base/step-sw-breakpoint-adjust-pc.c: New file. * gdb.base/step-sw-breakpoint-adjust-pc.exp: New file.
2014-10-28 14:42:11 +01:00
2014-10-28 Pedro Alves <palves@redhat.com>
PR gdb/12623
* gdb.base/sigstep.c (no_handler): New global.
(main): If 'no_handler is true, set the signal handlers to
SIG_IGN.
* gdb.base/sigstep.exp (breakpoint_over_handler): Add
with_sw_watch and no_handler parameters. Handle them.
(top level) <stepping over handler when stopped at a breakpoint
test>: Add a test axis for testing with a software watchpoint, and
another for testing with the signal handler set to SIG_IGN.
* gdb.base/step-sw-breakpoint-adjust-pc.c: New file.
* gdb.base/step-sw-breakpoint-adjust-pc.exp: New file.
Test for PR gdb/17511, spurious SIGTRAP after stepping into+in signal handler I noticed that when I single-step into a signal handler with a pending/queued signal, the following single-steps while the program is in the signal handler leave $eflags.TF set. That means subsequent continues will trap after one instruction, resulting in a spurious SIGTRAP being reported to the user. This is a kernel bug; I've reported it to kernel devs (turned out to be a known bug). I'm seeing it on x86_64 Fedora 20 (Linux 3.16.4-200.fc20.x86_64), and I was told it's still not fixed upstream. This commit extends gdb.base/sigstep.exp to cover this use case, xfailed. Here's what the bug looks like: (gdb) start Temporary breakpoint 1, main () at si-handler.c:48 48 setup (); (gdb) next 50 global = 0; /* set break here */ Let's queue a signal, so we can step into the handler: (gdb) handle SIGUSR1 Signal Stop Print Pass to program Description SIGUSR1 Yes Yes Yes User defined signal 1 (gdb) queue-signal SIGUSR1 TF is not set: (gdb) display $eflags 1: $eflags = [ PF ZF IF ] Now step into the handler -- "si" does PTRACE_SINGLESTEP+SIGUSR1: (gdb) si sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF IF ] No TF yet. But another single-step... (gdb) si 0x0000000000400621 31 { 1: $eflags = [ PF ZF TF IF ] ... ends up with TF left set. This results in PTRACE_CONTINUE trapping after each instruction is executed: (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000000400624 in sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF TF IF ] (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. sigusr1_handler (sig=10) at si-handler.c:32 32 global = 0; 1: $eflags = [ PF ZF TF IF ] (gdb) Note that even another PTRACE_SINGLESTEP does not fix it: (gdb) si 33 } 1: $eflags = [ PF ZF TF IF ] (gdb) Eventually, it gets "fixed" by the rt_sigreturn syscall, when returning out of the handler: (gdb) bt #0 sigusr1_handler (sig=10) at si-handler.c:33 #1 <signal handler called> #2 main () at si-handler.c:50 (gdb) set disassemble-next-line on (gdb) si 0x0000000000400632 33 } 0x0000000000400631 <sigusr1_handler+17>: 5d pop %rbp => 0x0000000000400632 <sigusr1_handler+18>: c3 retq 1: $eflags = [ PF ZF TF IF ] (gdb) <signal handler called> => 0x0000003b36a358f0 <__restore_rt+0>: 48 c7 c0 0f 00 00 00 mov $0xf,%rax 1: $eflags = [ PF ZF TF IF ] (gdb) si <signal handler called> => 0x0000003b36a358f7 <__restore_rt+7>: 0f 05 syscall 1: $eflags = [ PF ZF TF IF ] (gdb) main () at si-handler.c:50 50 global = 0; /* set break here */ => 0x000000000040066b <main+9>: c7 05 cb 09 20 00 00 00 00 00 movl $0x0,0x2009cb(%rip) # 0x601040 <global> 1: $eflags = [ PF ZF IF ] (gdb) The bug doesn't happen if we instead PTRACE_CONTINUE into the signal handler -- e.g., set a breakpoint in the handler, queue a signal, and "continue". gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/17511 * gdb.base/sigstep.c (handler): Add a few more writes to 'done'. * gdb.base/sigstep.exp (other_handler_location): New global. (advance): Support stepping into the signal handler, and running commands while in the handler. (in_handler_map): New global. (top level): In the advance test, add combinations for getting into the handler with stepping commands, and for running commands in the handler. Add comment descripting the advancei tests.
2014-10-28 16:51:30 +01:00
2014-10-28 Pedro Alves <palves@redhat.com>
PR gdb/17511
* gdb.base/sigstep.c (handler): Add a few more writes to 'done'.
* gdb.base/sigstep.exp (other_handler_location): New global.
(advance): Support stepping into the signal handler, and running
commands while in the handler.
(in_handler_map): New global.
(top level): In the advance test, add combinations for getting
into the handler with stepping commands, and for running commands
in the handler. Add comment descripting the advancei tests.
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
2014-10-28 Pedro Alves <palves@redhat.com>
* gdb.base/sigstep.exp: Use build_executable instead of
prepare_for_testing.
(top level): Move code that starts GDB, runs to main and creates a
display to ...
(restart): ... this new procedure.
(top level): Move backtrace from signal handler test to ...
(validate_backtrace): ... this new procedure.
(advance, advancei): Rename parameter from 'i' to 'cmd'. Use
with_test_prefix. Always restart GDB.
(skip_to_handler): Rename parameter from 'i' to 'cmd'. Use
with_test_prefix. Always restart GDB. No need to delete
breakpoints after the test.
(test_skip_handler): Remove prefix parameter.
(skip_over_handler, breakpoint_to_handler)
(breakpoint_to_handler_entry, breakpoint_over_handler): Rename
parameter from 'i' to 'cmd'. Use with_test_prefix. Always
restart GDB. No need to delete breakpoints after the test.
(top level): Use foreach to call the test procedures with
different commands.
update bug numbers (GNATS -> Bugzilla) in a few signal related tests This makes it easier to find the bugs in Bugzilla. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigaltstack.exp: Update to use Bugzilla bug numbers instead of GNATS numbers. * gdb.base/sigbpt.exp: Likewise. * gdb.base/siginfo.exp: Likewise. * gdb.base/sigstep.exp: Likewise.
2014-10-28 15:32:51 +01:00
2014-10-28 Pedro Alves <palves@redhat.com>
* gdb.base/sigaltstack.exp: Update to use Bugzilla bug numbers
instead of GNATS numbers.
* gdb.base/sigbpt.exp: Likewise.
* gdb.base/siginfo.exp: Likewise.
* gdb.base/sigstep.exp: Likewise.
stepi/nexti: skip signal handler if "handle nostop" signal arrives I noticed that "si" behaves differently when a "handle nostop" signal arrives while the step is in progress, depending on whether the program was stopped at a breakpoint when "si" was entered. Specifically, in case GDB needs to step off a breakpoint, the handler is skipped and the program stops in the next "mainline" instruction. Otherwise, the "si" stops in the first instruction of the signal handler. I was surprised the testsuite doesn't catch this difference. Turns out gdb.base/sigstep.exp covers a bunch of cases related to stepping and signal handlers, but does not test stepi nor nexti, only step/next/continue. My first reaction was that stopping in the signal handler was the correct thing to do, as it's where the next user-visible instruction that is executed is. I considered then "nexti" -- a signal handler could be reasonably considered a subroutine call to step over, it'd seem intuitive to me that "nexti" would skip it. But then, I realized that signals that arrive while a plain/line "step" is in progress _also_ have their handler skipped. A user might well be excused for being confused by this, given: (gdb) help step Step program until it reaches a different source line. And the signal handler's sources will be in different source lines, after all. I think that having to explain that "stepi" steps into handlers, (and that "nexti" wouldn't according to my reasoning above), while "step" does not, is a sign of an awkward interface. E.g., if a user truly is interested in stepping into signal handlers, then it's odd that she has to either force the signal to "handle stop", or recall to do "stepi" whenever such a signal might be delivered. For that use case, it'd seem nicer to me if "step" also stepped into handlers. This suggests to me that we either need a global "step-into-handlers" setting, or perhaps better, make "handle pass/nopass stop/nostop print/noprint" have have an additional axis - "handle stepinto/nostepinto", so that the user could configure whether handlers for specific signals should be stepped into. In any case, I think it's simpler (and thus better) for all step commands to behave the same. This commit thus makes "si/ni" skip handlers for "handle nostop" signals that arrive while the command was already in progress, like step/next do. To be clear, nothing changes if the program was stopped for a signal, and the user enters a stepping command _then_ -- GDB still steps into the handler. The change concerns signals that don't cause a stop and that arrive while the step is in progress. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-27 Pedro Alves <palves@redhat.com> * infrun.c (handle_signal_stop): Also skip handlers when a random signal arrives while handling a "stepi" or a "nexti". Set the thread's 'step_after_step_resume_breakpoint' flag. gdb/doc/ 2014-10-27 Pedro Alves <palves@redhat.com> * gdb.texinfo (Continuing and Stepping): Add cross reference to info on stepping and signal handlers. (Signals): Explain stepping and signal handlers. Add context index entry, and cross references. gdb/testsuite/ 2014-10-27 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.c (dummy): New global. (main): Issue a couple writes to the new global. * gdb.base/sigstep.exp (get_next_pc, test_skip_handler): New procedures. (skip_over_handler): Use test_skip_handler. (top level): Call skip_over_handler for stepi and nexti too. (breakpoint_over_handler): Use test_skip_handler. (top level): Call breakpoint_over_handler for stepi and nexti too.
2014-10-27 21:24:59 +01:00
2014-10-27 Pedro Alves <palves@redhat.com>
* gdb.base/sigstep.c (dummy): New global.
(main): Issue a couple writes to the new global.
* gdb.base/sigstep.exp (get_next_pc, test_skip_handler): New
procedures.
(skip_over_handler): Use test_skip_handler.
(top level): Call skip_over_handler for stepi and nexti too.
(breakpoint_over_handler): Use test_skip_handler.
(top level): Call breakpoint_over_handler for stepi and nexti too.
Fix trace file fails on powerpc64 I see the following fails on powerpc64-linux, (gdb) target tfile tfile-basic.tf^M warning: Uploaded tracepoint 1 has no source location, using raw address^M Tracepoint 1 at 0x10012358^M Created tracepoint 1 for target's tracepoint 1 at 0x10012358.^M (gdb) PASS: gdb.trace/tfile.exp: target tfile tfile-basic.tf info trace^M Num Type Disp Enb Address What^M 1 tracepoint keep y 0x0000000010012358 <write_basic_trace_file>^M installed on target^M (gdb) FAIL: gdb.trace/tfile.exp: info tracepoints on trace file -target-select tfile tfile-basic.tf^M =thread-group-started,id="i1",pid="1"^M =thread-created,id="1",group-id="i1"^M &"warning: Uploaded tracepoint 1 has no source location, using raw address\n"^M =breakpoint-created,bkpt={number="1",type="tracepoint",disp="keep",enabled="y", addr="0x0000000010012358",at="<write_basic_trace_file>",thread-groups=["i1"], times="0",installed="y",original-location="*0x10012358"}^M ~"Created tracepoint 1 for target's tracepoint 1 at 0x10012358.\n"^M ^connected^M (gdb) ^M FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: select trace file These fails are caused by writing function descriptor address into trace file instead of function address. This patch is to teach tfile.c to write function address on powerpc64 target. With this patch applied, fails in tfile.exp and mi-traceframe-changed.exp are fixed. Is it OK? gdb/testsuite: 2014-10-27 Yao Qi <yao@codesourcery.com> * gdb.trace/tfile.c (adjust_function_address) [__powerpc64__ && _CALL_ELF != 2]: Get function address from function descriptor.
2014-10-27 09:37:38 +01:00
2014-10-27 Yao Qi <yao@codesourcery.com>
* gdb.trace/tfile.c (adjust_function_address)
[__powerpc64__ && _CALL_ELF != 2]: Get function address from
function descriptor.
Follow-fork message printing improvements This commit modifies the code that prints attach and detach messages related to following fork and vfork. The changes include using target_terminal_ours_for_output instead of target_terminal_ours, printing "vfork" instead of "fork" for all vfork-related messages, and using _() for the format strings of all of the messages. We also add a "detach" message for when a fork parent is detached. Previously in this case the only message was notification of attaching to the child. We still do not print any messages when following the parent and detaching the child (the default). The rationale for this is that from the user's perspective the new child was never attached. Note that all of these messages are only printed when 'verbose' is set or when debugging is turned on. The tests gdb.base/foll-fork.exp and gdb.base/foll-vfork.exp were modified to check for the new message. Tested on x64 Ubuntu Lucid, native only. gdb/ChangeLog: * infrun.c (follow_fork_inferior): Update fork message printing to use target_terminal_ours_for_output instead of target_terminal_ours, to use _() for all format strings, to print "vfork" instead of "fork" for vforks, and to add a detach message. (handle_vfork_child_exec_or_exit): Update message printing to use target_terminal_ours_for_output instead of target_terminal_ours, to use _() for all format strings, and to fix some formatting. gdb/testsuite/ChangeLog: * gdb.base/foll-fork.exp (test_follow_fork, catch_fork_child_follow): Check for updated fork messages emitted from infrun.c. * gdb.base/foll-vfork.exp (vfork_parent_follow_through_step, vfork_parent_follow_to_bp, vfork_and_exec_child_follow_to_main_bp, vfork_and_exec_child_follow_through_step): Check for updated vfork messages emitted from infrun.c.
2014-10-24 20:36:06 +02:00
2014-10-24 Don Breazeal <donb@codesourcery.com>
* gdb.base/foll-fork.exp (test_follow_fork,
catch_fork_child_follow): Check for updated fork messages emitted
from infrun.c.
* gdb.base/foll-vfork.exp (vfork_parent_follow_through_step,
vfork_parent_follow_to_bp, vfork_and_exec_child_follow_to_main_bp,
vfork_and_exec_child_follow_through_step): Check for updated vfork
messages emitted from infrun.c.
Remove Vax Ultrix and VAX BSD support Built and tested on x86_64 Fedora 20, with --enable-targets=all. gdb/ 2014-10-24 Pedro Alves <palves@redhat.com> * Makefile.in (ALLDEPFILES): Remove vax-nat.c. * NEWS (Removed targets): Add VAX BSD and VAX Ultrix. * config/vax/vax.mh: Delete. * configure.host: Move vax-*-bsd* and vax-*-ultrix* to the obsolete configurations section. * configure.tgt (vax-*-*): Don't mention 4.2BSD nor Ultrix. * vax-nat.c: Delete file. gdb/testsuite/ 2014-10-24 Pedro Alves <palves@redhat.com> * gdb.base/corefile.exp: Remove references to ultrix. * gdb.base/interrupt.exp: Likewise. * gdb.base/whatis.exp: Likewise. * gdb.gdb/selftest.exp: Likewise. * gdb.threads/manythreads.exp: Likewise. * gdb.threads/print-threads.exp: Likewise. * gdb.threads/pthreads.exp:: Likewise. * gdb.threads/schedlock.exp: Likewise.
2014-10-17 15:49:04 +02:00
2014-10-24 Pedro Alves <palves@redhat.com>
* gdb.base/corefile.exp: Remove references to ultrix.
* gdb.base/interrupt.exp: Likewise.
* gdb.base/whatis.exp: Likewise.
* gdb.gdb/selftest.exp: Likewise.
* gdb.threads/manythreads.exp: Likewise.
* gdb.threads/print-threads.exp: Likewise.
* gdb.threads/pthreads.exp:: Likewise.
* gdb.threads/schedlock.exp: Likewise.
Guard a call to TYPE_TARGET_TYPE in gnuv3_pass_by_reference. gdb/ChangeLog: * gnu-v3-abi.c (gnuv3_pass_by_reference): Call TYPE_TARGET_TYPE on the arg type of a constructor only if it is of reference type. gdb/testsuite/ChangeLog: * gdb.cp/non-trivial-retval.cc: Add a test case. * gdb.cp/non-trivial-retval.exp: Add a test.
2014-10-16 16:14:13 +02:00
2014-10-24 Siva Chandra Reddy <sivachandra@google.com>
* gdb.cp/non-trivial-retval.cc: Add a test case.
* gdb.cp/non-trivial-retval.exp: Add a test.
Rename py-objfile-script-gdb.py.in to py-objfile-script-gdb.py Patch <https://sourceware.org/ml/gdb-patches/2011-07/msg00225.html> was to fix the problem that py-objfile-script-gdb.py is removed after an in-tree build and test. As a result of the previous patch (we don't remove files copied to host any more), this patch is no longer needed. This patch is to revert it logically. gdb/testsuite: 2014-10-20 Yao Qi <yao@codesourcery.com> * gdb.python/py-objfile-script-gdb.py.in: Rename it to ... * gdb.python/py-objfile-script-gdb.py: New file. * gdb.python/py-objfile-script.exp: Update reference to py-objfile-script-gdb.py.in. Use gdb_remote_donwload instead of remote_download. Remove the dest file.
2014-09-29 15:37:32 +02:00
2014-10-20 Yao Qi <yao@codesourcery.com>
* gdb.python/py-objfile-script-gdb.py.in: Rename it to ...
* gdb.python/py-objfile-script-gdb.py: New file.
* gdb.python/py-objfile-script.exp: Update reference to
py-objfile-script-gdb.py.in. Use gdb_remote_donwload instead
of remote_download. Remove the dest file.
Don't remove files copied to host Nowadays, if we do in-tree build and run tests sequentially, some source files are removed, due to the following pattern: set pi_txt [gdb_remote_download host ${srcdir}/${subdir}/pi.txt] remote_exec host "rm -f $pi_txt" If testing is run sequentially, file ${srcdir}/${subdir}/pi.txt is copied to ${objdir}/${subdir}/pi.txt. However, ${objdir} is ${srcdir} in the in-tree build/test, so the file is coped to itself, as a nop. As a result, the file in source is removed at the end of test. This patch fixes this problem by not removing files copied to host in each test. This patch also addresses the question we've had that why don't we keep files copied to host because they are needed to reproduce certain fails. gdb/testsuite: 2014-10-20 Yao Qi <yao@codesourcery.com> * gdb.base/checkpoint.exp: Don't remove file copied on host. * gdb.base/step-line.exp: Likewise. * gdb.dwarf2/dw2-anonymous-func.exp: Likewise. * gdb.dwarf2/dw2-basic.exp: Likewise. * gdb.dwarf2/dw2-compressed.exp: Likewise. * gdb.dwarf2/dw2-filename.exp: Likewise. * gdb.dwarf2/dw2-intercu.exp: Likewise. * gdb.dwarf2/dw2-intermix.exp: Likewise. * gdb.dwarf2/dw2-producer.exp: Likewise. * gdb.dwarf2/mac-fileno.exp: Likewise. * gdb.python/py-frame-args.exp: Likewise. * gdb.python/py-framefilter.exp: Likewise. * gdb.python/py-mi.exp: Likewise. * gdb.python/py-objfile-script.exp: Likewise * gdb.python/py-pp-integral.exp: Likewise. * gdb.python/py-pp-re-notag.exp: Likewise. * gdb.python/py-prettyprint.exp: Likewise. * gdb.python/py-section-script.exp: Likewise. * gdb.python/py-typeprint.exp: Likewise. * gdb.python/py-xmethods.exp: Likewise. * gdb.stabs/weird.exp: Likewise. * gdb.xml/tdesc-regs.exp: Likewise.
2014-09-29 14:47:30 +02:00
2014-10-20 Yao Qi <yao@codesourcery.com>
* gdb.base/checkpoint.exp: Don't remove file copied on host.
* gdb.base/step-line.exp: Likewise.
* gdb.dwarf2/dw2-anonymous-func.exp: Likewise.
* gdb.dwarf2/dw2-basic.exp: Likewise.
* gdb.dwarf2/dw2-compressed.exp: Likewise.
* gdb.dwarf2/dw2-filename.exp: Likewise.
* gdb.dwarf2/dw2-intercu.exp: Likewise.
* gdb.dwarf2/dw2-intermix.exp: Likewise.
* gdb.dwarf2/dw2-producer.exp: Likewise.
* gdb.dwarf2/mac-fileno.exp: Likewise.
* gdb.python/py-frame-args.exp: Likewise.
* gdb.python/py-framefilter.exp: Likewise.
* gdb.python/py-mi.exp: Likewise.
* gdb.python/py-objfile-script.exp: Likewise
* gdb.python/py-pp-integral.exp: Likewise.
* gdb.python/py-pp-re-notag.exp: Likewise.
* gdb.python/py-prettyprint.exp: Likewise.
* gdb.python/py-section-script.exp: Likewise.
* gdb.python/py-typeprint.exp: Likewise.
* gdb.python/py-xmethods.exp: Likewise.
* gdb.stabs/weird.exp: Likewise.
* gdb.xml/tdesc-regs.exp: Likewise.
Fix the gdb.dwarf2/dw2-dir-file-name.exp test on MIPS This patch fixes the failures that occur with the gdb.dwarf2/dw2-dir-file-name.exp test on 64-bit MIPS and compressed MIPS ISAs (i.e. MIPS16 and microMIPS). The failures on 64-bit occur because the generated DWARF address information is always 32-bit, which causes the upper 32-bits of addresses to be truncated and causes breakpoints to be set on the wrong address if any of the upper 32-bits are non-zero. I suspect that other 64-bit architectures get away with it because they place all their instructions at a VMA lower than 2^32 by default. This patch causes 64-bit addresses to be generated if a 64-bit target is detected. The failures on MIPS16 and microMIPS occur because the breakpoint address needs to have the LSB set to 1 (used to indicate that the code is compressed). However, the function name is interpreted as a data label, causing GDB to set breakpoints at even addresses. This is fixed by explicitly adding a '.insn' directive (see https://sourceware.org/binutils/docs/as/MIPS-insn.html) after the label on MIPS only. gdb/testsuite/ 2014-10-18 Kwok Cheung Yeung <kcy@codesourcery.com> * gdb.dwarf2/dw2-dir-file-name.exp (addr_len): New. (out_cu): Use addr_len for the size of addresses. (out_line): Likewise. Size DW_LNE_set_address instruction according to addr_len. * gdb.dwarf2/dw2-dir-file-name.c (START_INSNS): New. (FUNC): Add START_INSNS to definition.
2014-10-18 22:45:36 +02:00
2014-10-18 Kwok Cheung Yeung <kcy@codesourcery.com>
* gdb.dwarf2/dw2-dir-file-name.exp (addr_len): New.
(out_cu): Use addr_len for the size of addresses.
(out_line): Likewise. Size DW_LNE_set_address instruction
according to addr_len.
* gdb.dwarf2/dw2-dir-file-name.c (START_INSNS): New.
(FUNC): Add START_INSNS to definition.
Skip testing argv[0] on target argv[0] isn't available I see the following two fails on arm-none-eabi target, because argv[0] isn't available. print argv[0]^M $1 = 0x1f78 "/dev/null"^M (gdb) FAIL: gdb.base/argv0-symlink.exp: kept file symbolic link name print argv[0]^M $1 = 0x1f78 "/dev/null"^M (gdb) FAIL: gdb.base/argv0-symlink.exp: kept directory symbolic link name My first thought is to check [target_info exists noargs], and skip the test if it returns true. However, noargs is set in gdbserver board files, so argv0-symlink.exp will be skipped on gdbserver board file. The change is too aggressive. When the program is running with gdbserver, argv[1] to argv[N] aren't available, but argv[0] is. Fortunately, argv0-symlink.exp only requires argv[0]. argv0-symlink.exp can be run with gdbserver board file, as what we do now. What we need to check is whether argv[0] is available, so I add a new proc gdb_has_argv0 to do so by starting a program, and check argc/argv[0] to see whether argv[0] is available. Dan fixed the similar problem by checking noargs, which is too strong. https://sourceware.org/ml/gdb-patches/2010-02/msg00398.html as a result, the test is skipped on gdbserver. This patch fixed it too. gdb/testsuite: 2014-10-18 Yao Qi <yao@codesourcery.com> * gdb.base/argv0-symlink.exp: Check argv[0] value if gdb_has_argv0 return true. * gdb.guile/scm-value.exp (test_value_in_inferior): Don't check [target_info exists noargs], check [gdb_has_argv0] instead. * gdb.python/py-value.exp (test_value_in_inferior): Likewise. * lib/gdb.exp (gdb_has_argv0, gdb_has_argv0_1): New procedures.
2014-10-14 09:40:15 +02:00
2014-10-18 Yao Qi <yao@codesourcery.com>
* gdb.base/argv0-symlink.exp: Check argv[0] value if
gdb_has_argv0 return true.
* gdb.guile/scm-value.exp (test_value_in_inferior): Don't
check [target_info exists noargs], check [gdb_has_argv0]
instead.
* gdb.python/py-value.exp (test_value_in_inferior): Likewise.
* lib/gdb.exp (gdb_has_argv0, gdb_has_argv0_1): New
procedures.
New python event "clear_objfiles". If one is watching new_objfile events in python, it helps to know when the list of objfiles is cleared. This patch adds a new clear_objfiles event to support this. This patch is all just cut-n-paste-n-tweak derived from the new_objfiles event. gdb/ChangeLog: * NEWS: Mention new event gdb.clear_objfiles. * python/py-event.h (emit_clear_objfiles_event): Clear * python/py-events.h (events_object): New member clear_objfiles. * python/py-evts.c (gdbpy_initialize_py_events): Add clear_objfiles event. * python/py-inferior.c (python_new_objfile): If objfile is NULL, emit clear_objfiles event. * python/py-newobjfileevent.c (create_clear_objfiles_event_object): New function. (emit_clear_objfiles_event): New function. (clear_objfiles): New event. * python/python-internal.h (gdbpy_initialize_clear_objfiles_event): Declare. * python/python.c (_initialize_python): Call gdbpy_initialize_clear_objfiles_event. gdb/doc/ChangeLog: * python.texi (Events In Python): Document clear_objfiles event. gdb/testsuite/ChangeLog: * gdb.python/py-events.exp: Update expected output for clear_objfiles event. * gdb.python/py-events.py: Add clear_objfiles event.
2014-10-17 20:12:17 +02:00
2014-10-17 Doug Evans <dje@google.com>
* gdb.python/py-events.exp: Update expected output for clear_objfiles
event.
* gdb.python/py-events.py: Add clear_objfiles event.
Add gdb.Objfile.progspace attribute. gdb/ChangeLog: * NEWS: Mention new gdb.Objfile.progspace attribute. * python/py-objfile.c (objfpy_get_progspace): New function. (objfile_getset): New entry for "progspace". gdb/doc/ChangeLog: * python.texi (Objfiles In Python): Document new progspace attribute. gdb/testsuite/ChangeLog: * gdb.python/py-objfile.exp: Test progspace attribute.
2014-10-17 19:57:26 +02:00
2014-10-17 Doug Evans <dje@google.com>
* gdb.python/py-objfile.exp: Test progspace attribute.
Fix mingw32 failures due to incorrect directory separator in pattern Some testcases, mostly gdb.reverse ones, assume the presence of a '/' directory separator before the source file name. This is incorrect for mingw32 hosts, generating false failures for those tests. I attempted to catch most of the occurrences of the pattern ".*/$srcfile" and replaced them with ".*$srcfile". The latter is used elsewhere in the testsuite. The resulting patch is attached. I also see other occurrences of the same assumption throughout the testsuite, but usually they are arguments for function calls and i seem to recall either the test harness or GDB deals with those paths properly. gdb/testsuite: 2014-10-17 Luis Machado <lgustavo@codesourcery.com> * gdb.guile/scm-breakpoint.exp: Do not assume any directory separators when matching source file paths. * gdb.python/py-breakpoint.exp: Likewise. * gdb.reverse/break-precsave.exp: Likewise. * gdb.reverse/break-reverse.exp: Likewise. * gdb.reverse/consecutive-precsave.exp: Likewise. * gdb.reverse/finish-precsave.exp: Likewise. * gdb.reverse/finish-reverse-bkpt.exp: Likewise. * gdb.reverse/finish-reverse.exp: Likewise. * gdb.reverse/i386-precsave.exp: Likewise. * gdb.reverse/i387-env-reverse.exp: Likewise. * gdb.reverse/i387-stack-reverse.exp: Likewise. * gdb.reverse/machinestate-precsave.exp: Likewise. * gdb.reverse/machinestate.exp: Likewise. * gdb.reverse/sigall-precsave.exp: Likewise. * gdb.reverse/solib-precsave.exp: Likewise. * gdb.reverse/step-precsave.exp: Likewise. * gdb.reverse/until-precsave.exp: Likewise. * gdb.reverse/watch-precsave.exp: Likewise. * gdb.reverse/watch-reverse.exp: Likewise.
2014-10-17 16:28:17 +02:00
2014-10-17 Luis Machado <lgustavo@codesourcery.com>
* gdb.guile/scm-breakpoint.exp: Do not assume any
directory separators when matching source file paths.
* gdb.python/py-breakpoint.exp: Likewise.
* gdb.reverse/break-precsave.exp: Likewise.
* gdb.reverse/break-reverse.exp: Likewise.
* gdb.reverse/consecutive-precsave.exp: Likewise.
* gdb.reverse/finish-precsave.exp: Likewise.
* gdb.reverse/finish-reverse-bkpt.exp: Likewise.
* gdb.reverse/finish-reverse.exp: Likewise.
* gdb.reverse/i386-precsave.exp: Likewise.
* gdb.reverse/i387-env-reverse.exp: Likewise.
* gdb.reverse/i387-stack-reverse.exp: Likewise.
* gdb.reverse/machinestate-precsave.exp: Likewise.
* gdb.reverse/machinestate.exp: Likewise.
* gdb.reverse/sigall-precsave.exp: Likewise.
* gdb.reverse/solib-precsave.exp: Likewise.
* gdb.reverse/step-precsave.exp: Likewise.
* gdb.reverse/until-precsave.exp: Likewise.
* gdb.reverse/watch-precsave.exp: Likewise.
* gdb.reverse/watch-reverse.exp: Likewise.
Copy xml files to host When I run test with board file local-remote-host-native.exp, I see the following warning, $ make check RUNTESTFLAGS="--host_board=local-remote-host-native --target_board=local-remote-host-native tdesc-arch.exp HOST_DIR=/tmp/foo/" (gdb) set tdesc filename ../../../../git/gdb/testsuite/gdb.xml/trivial.xml^M warning: Could not open "../../../../git/gdb/testsuite/gdb.xml/trivial.xml" (gdb) quit^ because "${srcdir}/gdb.xml/trivial.xml" doesn't exist on host. This patch is to copy trivial.xml to host and the warning goes away. (gdb) set tdesc filename /tmp/foo/trivial.xml^M (gdb) quit^ tdesc-regs.exp has the similar problem that single-reg.xml may not exist on host at all, and it should be copied to host too. gdb/testsuite: 2014-10-17 Yao Qi <yao@codesourcery.com> * lib/gdb.exp (gdb_skip_xml_test): Copy trivial.xml to host. * gdb.xml/tdesc-regs.exp: Copy single-reg.xml to host.
2014-08-15 05:28:39 +02:00
2014-10-17 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (gdb_skip_xml_test): Copy trivial.xml to host.
* gdb.xml/tdesc-regs.exp: Copy single-reg.xml to host.
PR gdb/17471: Repeating a background command makes it foreground When we repeat a command, by just pressing <ret>, the input from the previous command is reused for the new command invocation. When an execution command strips the "&" out of its incoming argument string, to detect background execution, we poke a '\0' directly to the incoming argument string. Combine both, and a repeat of a background command loses the "&". This is actually only visible if args other than "&" are specified (e.g., "c 1&" or "next 2&" or "c -a&"), as in the special case of "&" alone (e.g. "c&") doesn't actually clobber the incoming string. Fix this by making strip_bg_char return a new string instead of poking a hole in the input string. New test included. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-17 Pedro Alves <palves@redhat.com> PR gdb/17471 * infcmd.c (strip_bg_char): Change prototype and rewrite. Now returns a copy of the input. (run_command_1, continue_command, step_1, jump_command) (signal_command, until_command, advance_command, finish_command) (attach_command): Adjust and install a cleanup to free the stripped args. gdb/testsuite/ 2014-10-17 Pedro Alves <palves@redhat.com> PR gdb/17471 * gdb.base/bg-execution-repeat.c: New file. * gdb.base/bg-execution-repeat.exp: New file.
2014-10-17 14:31:26 +02:00
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17471
* gdb.base/bg-execution-repeat.c: New file.
* gdb.base/bg-execution-repeat.exp: New file.
PR gdb/17300: Input after "c -a" crashes readline/GDB If all threads in the target were already running when the user does "c -a", nothing puts the inferior's terminal settings in effect and removes stdin from the event loop, which we must when running a foreground command. The result is that user input afterwards crashes readline/gdb: (gdb) start Temporary breakpoint 1 at 0x4005d4: file continue-all-already-running.c, line 23. Starting program: continue-all-already-running Temporary breakpoint 1, main () at continue-all-already-running.c:23 23 sleep (10); (gdb) c -a& Continuing. (gdb) c -a Continuing. p 1 readline: readline_callback_read_char() called with no handler! Aborted (core dumped) $ Backtrace: Program received signal SIGABRT, Aborted. 0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (top-gdb) p 1 $1 = 1 (top-gdb) bt #0 0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x0000003b36a36f68 in __GI_abort () at abort.c:89 #2 0x0000000000784aa9 in rl_callback_read_char () at readline/callback.c:116 #3 0x0000000000619181 in rl_callback_read_char_wrapper (client_data=0x0) at gdb/event-top.c:167 #4 0x0000000000619557 in stdin_event_handler (error=0, client_data=0x0) at gdb/event-top.c:373 #5 0x000000000061814a in handle_file_event (data=...) at gdb/event-loop.c:763 #6 0x0000000000617631 in process_event () at gdb/event-loop.c:340 #7 0x00000000006176f8 in gdb_do_one_event () at gdb/event-loop.c:404 #8 0x0000000000617748 in start_event_loop () at gdb/event-loop.c:429 #9 0x00000000006191b3 in cli_command_loop (data=0x0) at gdb/event-top.c:182 #10 0x000000000060f538 in current_interp_command_loop () at gdb/interps.c:318 #11 0x0000000000610701 in captured_command_loop (data=0x0) at gdb/main.c:323 #12 0x000000000060c3f5 in catch_errors (func=0x6106e6 <captured_command_loop>, func_args=0x0, errstring=0x9002c1 "", mask=RETURN_MASK_ALL) at gdb/exceptions.c:237 #13 0x0000000000611bff in captured_main (data=0x7fffffffd780) at gdb/main.c:1151 #14 0x000000000060c3f5 in catch_errors (func=0x610afe <captured_main>, func_args=0x7fffffffd780, errstring=0x9002c1 "", mask=RETURN_MASK_ALL) at gdb/exceptions.c:237 #15 0x0000000000611c28 in gdb_main (args=0x7fffffffd780) at gdb/main.c:1159 #16 0x000000000045ef97 in main (argc=5, argv=0x7fffffffd888) at gdb/gdb.c:32 (top-gdb) Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-17 Pedro Alves <palves@redhat.com> PR gdb/17300 * infcmd.c (continue_1): If continuing all threads in the foreground, make sure the inferior's terminal settings are put in effect. gdb/testsuite/ 2014-10-17 Pedro Alves <palves@redhat.com> PR gdb/17300 * gdb.base/continue-all-already-running.c: New file. * gdb.base/continue-all-already-running.exp: New file.
2014-10-17 14:31:25 +02:00
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17300
* gdb.base/continue-all-already-running.c: New file.
* gdb.base/continue-all-already-running.exp: New file.
PR gdb/17472: With annotations, input while executing in the foreground crashes readline/GDB Jan caught an intermittent GDB crash with the annota1.exp test: Starting program: .../gdb/testsuite/gdb.base/annota1 ^M [...] FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout) [...] readline: readline_callback_read_char() called with no handler!^M ERROR: Process no longer exists All we need to is to continue the inferior in the foreground, and type a command while the inferior is running. E.g.: (gdb) set annotate 2 ▒▒pre-prompt (gdb) ▒▒prompt c ▒▒post-prompt Continuing. ▒▒starting ▒▒frames-invalid *inferior is running now* p 1<ret> readline: readline_callback_read_char() called with no handler! Aborted (core dumped) $ When we run a foreground execution command we call target_terminal_inferior to stop GDB from processing input, and to put the inferior's terminal settings in effect. Then we tell readline to hide the prompt with display_gdb_prompt, which clears readline's input callback too. When the target stops, we call target_terminal_ours, which re-installs stdin in the event loop, and then we redisplay the prompt, reinstalling the readline callbacks. However, when annotations are in effect, the "frames-invalid" annotation code calls target_terminal_ours after 'resume' had already called target_terminal_inferior: (top-gdb) bt #0 0x000000000056b82f in annotate_frames_invalid () at gdb/annotate.c:219 #1 0x000000000072e6cc in reinit_frame_cache () at gdb/frame.c:1705 #2 0x0000000000594bb9 in registers_changed_ptid (ptid=...) at gdb/regcache.c:612 #3 0x000000000064cca1 in target_resume (ptid=..., step=1, signal=GDB_SIGNAL_0) at gdb/target.c:2136 #4 0x00000000005f57af in resume (step=1, sig=GDB_SIGNAL_0) at gdb/infrun.c:2263 #5 0x00000000005f6051 in proceed (addr=18446744073709551615, siggnal=GDB_SIGNAL_DEFAULT, step=1) at gdb/infrun.c:2613 And then once we hide the prompt and remove readline's input handler callback, we're in a bad state. We end up with the target running supposedly in the foreground, but with stdin still installed on the event loop. Any input then calls into readline, which aborts because no rl_linefunc callback handler is installed: Program received signal SIGABRT, Aborted. 0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (top-gdb) bt #0 0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x0000003b36a36f68 in __GI_abort () at abort.c:89 During symbol reading, debug info gives source 9 included from file at zero line 0. During symbol reading, debug info gives command-line macro definition with non-zero line 19: _STDC_PREDEF_H 1. #2 0x0000000000784a25 in rl_callback_read_char () at src/readline/callback.c:116 #3 0x0000000000619111 in rl_callback_read_char_wrapper (client_data=0x0) at src/gdb/event-top.c:167 #4 0x00000000006194e7 in stdin_event_handler (error=0, client_data=0x0) at src/gdb/event-top.c:373 #5 0x00000000006180da in handle_file_event (data=...) at src/gdb/event-loop.c:763 #6 0x00000000006175c1 in process_event () at src/gdb/event-loop.c:340 #7 0x0000000000617688 in gdb_do_one_event () at src/gdb/event-loop.c:404 #8 0x00000000006176d8 in start_event_loop () at src/gdb/event-loop.c:429 #9 0x0000000000619143 in cli_command_loop (data=0x0) at src/gdb/event-top.c:182 #10 0x000000000060f4c8 in current_interp_command_loop () at src/gdb/interps.c:318 #11 0x0000000000610691 in captured_command_loop (data=0x0) at src/gdb/main.c:323 #12 0x000000000060c385 in catch_errors (func=0x610676 <captured_command_loop>, func_args=0x0, errstring=0x900241 "", mask=RETURN_MASK_ALL) at src/gdb/exceptions.c:237 #13 0x0000000000611b8f in captured_main (data=0x7fffffffd7b0) at src/gdb/main.c:1151 #14 0x000000000060c385 in catch_errors (func=0x610a8e <captured_main>, func_args=0x7fffffffd7b0, errstring=0x900241 "", mask=RETURN_MASK_ALL) at src/gdb/exceptions.c:237 #15 0x0000000000611bb8 in gdb_main (args=0x7fffffffd7b0) at src/gdb/main.c:1159 #16 0x000000000045ef57 in main (argc=3, argv=0x7fffffffd8b8) at src/gdb/gdb.c:32 The fix is to make the annotation code call target_terminal_inferior again after printing, if the inferior's settings were in effect. While at it, when we're doing output only, instead of target_terminal_ours, we should call target_terminal_ours_for_output. The latter doesn't actually remove stdin from the event loop, and also leaves SIGINT forwarded to the target. New test included. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-17 Pedro Alves <palves@redhat.com> PR gdb/17472 * annotate.c (annotate_breakpoints_invalid): Use target_terminal_our_for_output instead of target_terminal_ours. Give back the terminal to the target. (annotate_frames_invalid): Likewise. gdb/testsuite/ 2014-10-17 Pedro Alves <palves@redhat.com> PR gdb/17472 * gdb.base/annota-input-while-running.c: New file. * gdb.base/annota-input-while-running.exp: New file.
2014-10-17 14:31:25 +02:00
2014-10-17 Pedro Alves <palves@redhat.com>
PR gdb/17472
* gdb.base/annota-input-while-running.c: New file.
* gdb.base/annota-input-while-running.exp: New file.
Delete Tru64 support This commit does most of the mechanical removal. IOW, the easy part. procfs.c isn't touched beyond removing a couple obvious bits that are guarded by a couple macros defined in config/alpha/nm-osf3.h. Going beyond that for procfs.c & co would be a harder excision that potentially affects Solaris. Some comments in the generic alpha code ABIs that may still be relevant and I wouldn't know what to do with them. That can always be done on a separate pass, preferably by someone who can test on alpha. A couple other spots have references to OSF/Tru64 and related files being removed, but it felt like removing them would make things worse, not better. We can revisit those when we next need to touch that code. I didn't remove a reference to osf in testsuite/lib/future.exp, as I believe that code is imported from DejaGNU. Built and tested on x86_64 Fedora 20, with --enable-targets=all. Tested that building for --target=alpha-osf3 on x86_64 Fedora 20 fails with: checking for default auto-load directory... $debugdir:$datadir/auto-load checking for default auto-load safe-path... $debugdir:$datadir/auto-load *** Configuration alpha-unknown-osf3 is obsolete. *** Support has been REMOVED. make[1]: *** [configure-gdb] Error 1 make[1]: Leaving directory `build-osf' make: *** [all] Error 2 gdb/ 2014-10-17 Pedro Alves <palves@redhat.com> * Makefile.in (ALL_64_TARGET_OBS): Remove alpha-osf1-tdep.o. (HFILES_NO_SRCDIR): Remove config/alpha/nm-osf3.h. (ALLDEPFILES): Remove alpha-nat.c, alpha-osf1-tdep.c and solib-osf.c. * NEWS: Mention that support for alpha*-*-osf* has been removed. * ada-lang.h [__alpha__ && __osf__] (ADA_KNOWN_RUNTIME_FILE_NAME_PATTERNS): Delete. * alpha-nat.c, alpha-osf1-tdep.c: Delete files. * alpha-tdep.c (alpha_gdbarch_init): Remove reference to GDB_OSABI_OSF1. * config/alpha/alpha-osf3.mh, config/alpha/nm-osf3.h: Delete files. * config/djgpp/fnchange.lst (config/alpha/alpha-osf1.mh) (config/alpha/alpha-osf2.mh, config/alpha/alpha-osf3.mh): Delete. * configure: Regenerate. * configure.ac: Remove references to osf. * configure.host: Handle alpha*-*-osf* in the obsolete hosts section. Remove all other references to osf. * configure.tgt: Add alpha*-*-osf* to the obsolete targets section. Remove all other references to osf. * dec-thread.c: Delete file. * defs.h (GDB_OSABI_OSF1): Delete. * inferior.h (START_INFERIOR_TRAPS_EXPECTED): New unconditionally defined. * osabi.c (gdb_osabi_names): Delete "OSF/1". * procfs.c (procfs_debug_inferior) [PROCFS_DONT_TRACE_FAULTS]: Delete code. (unconditionally_kill_inferior) [PROCFS_NEED_CLEAR_CURSIG_FOR_KILL]: Delete code. * solib-osf.c: Delete file. gdb/testsuite/ 2014-10-17 Pedro Alves <palves@redhat.com> * gdb.base/callfuncs.exp: emove references to osf. * gdb.base/sigall.exp: Likewise. * gdb.gdb/selftest.exp: Likewise. * gdb.hp/gdb.base-hp/callfwmall.exp: Likewise. * gdb.mi/non-stop.c: Likewise. * gdb.mi/pthreads.c: Likewise. * gdb.reverse/sigall-precsave.exp: Likewise. * gdb.reverse/sigall-reverse.exp: Likewise. * gdb.threads/pthreads.c: Likewise. * gdb.threads/pthreads.exp: Likewise. gdb/doc/ 2014-10-17 Pedro Alves <palves@redhat.com> * gdb.texinfo (Ada Tasks and Core Files): Delete mention of Tru64. (SVR4 Process Information): Delete mention of OSF/1.
2014-10-17 12:18:59 +02:00
2014-10-17 Pedro Alves <palves@redhat.com>
* gdb.base/callfuncs.exp: emove references to osf.
* gdb.base/sigall.exp: Likewise.
* gdb.gdb/selftest.exp: Likewise.
* gdb.hp/gdb.base-hp/callfwmall.exp: Likewise.
* gdb.mi/non-stop.c: Likewise.
* gdb.mi/pthreads.c: Likewise.
* gdb.reverse/sigall-precsave.exp: Likewise.
* gdb.reverse/sigall-reverse.exp: Likewise.
* gdb.threads/pthreads.c: Likewise.
* gdb.threads/pthreads.exp: Likewise.
Don't check target_info exists noargs in commands.exp I am confused by the noargs checking at each proc in commands.exp, if [target_info exists noargs] { verbose "Skipping progvar_simple_while_test because of noargs." return } gdb_test_no_output "set args 5" "set args in progvar_simple_while_test" if { ![runto factorial] } then { gdb_suppress_tests } # Don't depend upon argument passing, since most simulators don't # currently support it. Bash value variable to be what we want. gdb_test "p value=5" ".*" "set value to 5 in progvar_simple_if_test #2" They are conflicting to me. If the argument passing can't be done on the target, we skip this test, why do we still have to set value below? On the other hand, the test case is compiled with -DFAKEARGV, it doesn't get anything from argv[1], why do we need to skip it if noargs is true? I don't find any useful clues from the git log, as the code is quite old, predating import to sourceware cvs. However, I find something useful from the ChangeLog. Thu Jul 20 13:28:36 1995 Jeffrey A. Law <law@rtl.cygnus.com> ..... * gdb.base/commands.exp: Protect tests which need arguments with $noargs conditionals. Mon Apr 21 13:38:58 1997 Fred Fish <fnf@cygnus.com> * gdb.base/run.c: Use FAKEARGV to build test executable that does not require a command line arg, since most simulators don't currently support passing such an arg into the simulated program. * gdb.base/commands.exp: Change tests to insert the proper value as the arg to the first recursive factorial call. Change compilation line to define FAKEARGV at compile time. Jeff added noargs checking as argument is passed to the inferior. Then, I presume Fred wanted to run this test on simulators which don't support argument passing, and change the code not get input from argv. (I guess) noargs wasn't set in simulator board files at that moment. Since Fred changed test to set input by gdb, instead of getting input from argv, the test should be able to run on target doesn't support argument passing, such as simulator and gdbserver. This patch is to remove these checks to noargs and "set args". I run commands.exp with these board files, and no fail is found - unix and native-gdbserver - arm-none-eabi with qemu - gdbserver on arm-linux-gnueabi with qemu gdb/testsuite: 2014-10-17 Yao Qi <yao@codesourcery.com> * gdb.base/commands.exp (gdbvar_complex_if_while_test): Don't check 'target_info exists noargs'. (test_command_prompt_position): Likewise. (progvar_simple_if_test): Don't check 'target_info exists noargs'. Remove "set args". (progvar_simple_while_test): Likewise. (progvar_complex_if_while_test): Likewise. (if_while_breakpoint_command_test): Likewise. (infrun_breakpoint_command_test): Likewise. (breakpoint_command_test): Likewise. (watchpoint_command_test): Likewise. (bp_deleted_in_command_test): Likewise. (temporary_breakpoint_commands): Likewise.
2014-10-10 15:17:11 +02:00
2014-10-17 Yao Qi <yao@codesourcery.com>
* gdb.base/commands.exp (gdbvar_complex_if_while_test): Don't
check 'target_info exists noargs'.
(test_command_prompt_position): Likewise.
(progvar_simple_if_test): Don't check 'target_info exists noargs'.
Remove "set args".
(progvar_simple_while_test): Likewise.
(progvar_complex_if_while_test): Likewise.
(if_while_breakpoint_command_test): Likewise.
(infrun_breakpoint_command_test): Likewise.
(breakpoint_command_test): Likewise.
(watchpoint_command_test): Likewise.
(bp_deleted_in_command_test): Likewise.
(temporary_breakpoint_commands): Likewise.
Don't check noargs in remotetimeout.exp The condition [target_info exists noargs] is checked when remotetimeout.exp was added https://sourceware.org/ml/gdb-patches/2005-02/msg00052.html noargs means GDB does not support argument passing for inferior, rather than doesn't support argument passing to GDB. remotetimeout.exp passes -l to GDB only, doesn't pass any arguments to the inferior. This patch is to remove such unnecessary checking, and remotetimeout.exp then can be run with native-gdbserver board file. gdb/testsuite: 2014-10-16 Yao Qi <yao@codesourcery.com> * gdb.base/remotetimeout.exp: Remove noargs checking.
2014-10-10 14:52:25 +02:00
2014-10-16 Yao Qi <yao@codesourcery.com>
* gdb.base/remotetimeout.exp: Remove noargs checking.
Put single-step breakpoints on the bp_location chain This patch makes single-step breakpoints "real" breakpoints on the global location list. There are several benefits to this: - It removes the currently limitation that only 2 single-step breakpoints can be inserted. See an example here of a discussion around a case that wants more than 2, possibly unbounded: https://sourceware.org/ml/gdb-patches/2014-03/msg00663.html - makes software single-step work on read-only code regions. The logic to convert a software breakpoint to a hardware breakpoint if the memory map says the breakpoint address is in read only memory is in insert_bp_location. Because software single-step breakpoints bypass all that go and straight to target_insert_breakpoint, we can't software single-step over read only memory. This patch removes that limitation, and adds a test that makes sure that works, by forcing a code region to read-only with "mem LOW HIGH ro" and then stepping through that. - Fixes PR breakpoints/9649 This is an assertion failure in insert_single_step_breakpoint in breakpoint.c, because we may leave stale single-step breakpoints behind on error. The tests for stepping through read-only regions exercise the root cause of the bug, which is that we leave single-step breakpoints behind if we fail to insert any single-step breakpoint. Deleting the single-step breakpoints in resume_cleanups, delete_just_stopped_threads_infrun_breakpoints, and fetch_inferior_event fixes this. Without that, we'd no longer hit the assertion, as that code is deleted, but we'd instead run into errors/warnings trying to insert/remove the stale breakpoints on next resume. - Paves the way to have multiple threads software single-stepping at the same time, leaving update_global_location_list to worry about duplicate locations. - Makes the moribund location machinery aware of software single-step breakpoints, paving the way to enable software single-step on non-stop, instead of forcing serialized displaced stepping for all single steps. - It's generaly cleaner. We no longer have to play games with single-step breakpoints inserted at the same address as regular breakpoints, like we recently had to do for 7.8. See this discussion: https://sourceware.org/ml/gdb-patches/2014-06/msg00052.html. Tested on x86_64 Fedora 20, on top of my 'single-step breakpoints on x86' series. gdb/ 2014-10-15 Pedro Alves <palves@redhat.com> PR breakpoints/9649 * breakpoint.c (single_step_breakpoints, single_step_gdbarch): Delete array globals. (single_step_breakpoints): New global. (breakpoint_xfer_memory): Remove special handling for single-step breakpoints. (update_breakpoints_after_exec): Delete bp_single_step breakpoints. (detach_breakpoints): Remove special handling for single-step breakpoints. (breakpoint_init_inferior): Delete bp_single_step breakpoints. (bpstat_stop_status): Add comment. (bpstat_what, bptype_string, print_one_breakpoint_location) (adjust_breakpoint_address, init_bp_location): Handle bp_single_step. (new_single_step_breakpoint): New function. (set_momentary_breakpoint, bkpt_remove_location): Remove special handling for single-step breakpoints. (insert_single_step_breakpoint, single_step_breakpoints_inserted) (remove_single_step_breakpoints, cancel_single_step_breakpoints): Rewrite. (detach_single_step_breakpoints, find_single_step_breakpoint): Delete functions. (breakpoint_has_location_inserted_here): New function. (single_step_breakpoint_inserted_here_p): Rewrite. * breakpoint.h: Remove FIXME. (enum bptype) <bp_single_step>: New enum value. (insert_single_step_breakpoint): Update comment. * infrun.c (resume_cleanups) (delete_step_thread_step_resume_breakpoint): Remove single-step breakpoints. (fetch_inferior_event): Install a cleanup that removes infrun breakpoints. (switch_back_to_stepped_thread) <expect thread advanced also>: Clear step-over info. gdb/testsuite/ 2014-10-15 Pedro Alves <palves@redhat.com> PR breakpoints/9649 * gdb.base/breakpoint-in-ro-region.c (main): Add more instructions. * gdb.base/breakpoint-in-ro-region.exp (probe_target_hardware_step): New procedure. (top level): Probe hardware stepping and hardware breakpoint support. Test stepping through a read-only region, with both "breakpoint auto-hw" on and off and both "always-inserted" on and off.
2014-10-15 21:18:31 +02:00
2014-10-15 Pedro Alves <palves@redhat.com>
PR breakpoints/9649
* gdb.base/breakpoint-in-ro-region.c (main): Add more instructions.
* gdb.base/breakpoint-in-ro-region.exp
(probe_target_hardware_step): New procedure.
(top level): Probe hardware stepping and hardware breakpoint
support. Test stepping through a read-only region, with both
"breakpoint auto-hw" on and off and both "always-inserted" on and
off.
Remove d-support.c and use gdb_demangle for demangling D symbols. gdb/ChangeLog * Makefile.in (SFILES): Remove d-support.c. (COMMON_OBS): Remove d-support.o. * d-lang.h (d_parse_symbol): Remove declaration. * d-lang.c (d_demangle): Use gdb_demangle to demangle D symbols. * d-support.c: Remove file. gdb/testsuite/ChangeLog * gdb.dlang/demangle.exp: Update for demangling changes.
2014-10-15 20:28:19 +02:00
2014-10-15 Iain Buclaw <ibuclaw@gdcproject.org>
* gdb.dlang/demangle.exp: Update for demangling changes.
Add new non-trial return value tests. gdb/testsuite/ChangeLog: * gdb.cp/non-trivial-retval.cc: Add new test cases. * gdb.cp/non-trivial-retval.exp: Add new tests.
2014-09-09 15:46:14 +02:00
2014-10-15 Siva Chandra Reddy <sivachandra@google.com>
* gdb.cp/non-trivial-retval.cc: Add new test cases.
* gdb.cp/non-trivial-retval.exp: Add new tests.
Non trivial return value tests. gdb/testsuite/ChangeLog: PR c++/13403 PR c++/15154 * gdb.cp/non-trivial-retval.cc: New file. * gdb.cp/non-trivial-retval.exp: New file.
2014-09-08 16:04:59 +02:00
2014-10-15 Siva Chandra Reddy <sivachandra@google.com>
PR c++/13403
PR c++/15154
* gdb.cp/non-trivial-retval.cc: New file.
* gdb.cp/non-trivial-retval.exp: New file.
Fix py-parameter.exp for remote host Test gdb.python/py-parameter.exp expects output "$srcdir/$subdir:\$cdir:\$cwd", but proc gdb_reinitialize_dir doesn't set $srcdir/$subdir in search directories on remote host because it doesn't exist on remote host. proc gdb_reinitialize_dir { subdir } { global gdb_prompt if [is_remote host] { return "" } It causes the fail below: (gdb) python print (gdb.parameter ('directories'))^M /tmp/gdb:$cdir:$cwd^M (gdb) FAIL: gdb.python/py-parameter.exp: python print (gdb.parameter ('directories')) This patch is to fix this fail by not matching $srcdir/$subdir on remote host. gdb/testsuite: 2014-10-15 Yao Qi <yao@codesourcery.com> * gdb.python/py-parameter.exp: Don't match $srcdir/$subdir on remote host.
2014-09-15 13:06:22 +02:00
2014-10-15 Yao Qi <yao@codesourcery.com>
* gdb.python/py-parameter.exp: Don't match $srcdir/$subdir on
remote host.
Fix file name matching on remote host. I see the following fails in the remote host testing we do for mingw32 hosted GDB, python print (symtab[1][0].symtab)^M python.c^M (gdb) FAIL: gdb.python/python.exp: Test decode_line current locationn filename python print (symtab[1][0].symtab)^M python.c^M (gdb) FAIL: gdb.python/python.exp: Test decode_line python.c:26 filename The test cases doesn't consider remote host and assumes that directory on build also exists on host. In this patch, we only match file base name if host is remote, otherwise, match file with dir name. gdb/testsuite: 2014-10-15 Yao Qi <yao@codesourcery.com> * gdb.python/py-symbol.exp: Match file base name if host is remote, otherwise match file name with dir name. * gdb.python/py-symtab.exp: Likewise. * gdb.python/python.exp: Likewise.
2014-09-15 11:40:54 +02:00
2014-10-15 Yao Qi <yao@codesourcery.com>
* gdb.python/py-symbol.exp: Match file base name if host is
remote, otherwise match file name with dir name.
* gdb.python/py-symtab.exp: Likewise.
* gdb.python/python.exp: Likewise.
Clean up gdb.python/ tests This patch is to clean up various gdb.python/*.exp tests, such as removing trailing ".*" from the pattern and fix one typo I find during reading the code. gdb/testsuite: 2014-10-15 Yao Qi <yao@codesourcery.com> * gdb.python/python.exp: Remove trailing ".*". Fix typo locationn. * gdb.python/py-symbol.exp: Remove trailing ".*" in the pattern. * gdb.python/py-symtab.exp: Likewise.
2014-09-15 10:41:39 +02:00
2014-10-15 Yao Qi <yao@codesourcery.com>
* gdb.python/py-symbol.exp: Remove trailing ".*" in the
pattern.
* gdb.python/py-symtab.exp: Likewise.
* gdb.python/python.exp: Remove trailing ".*". Fix typo
locationn.
[Ada] Error adding/subtracting pointer value to/from integral. When trying to evaluate an expression which adds a pointer and an integral, the evaluation succeeds if the pointer is on the left handside of the operator, but not when it is on the right handside: (gdb) p something'address + 0 $1 = (system.address) 0x613418 <pck.something> (gdb) p 0 + something'address Argument to arithmetic operation not a number or boolean. Same issue when doing subtractions: (gdb) p something'address - 0 $2 = (system.address) 0x613418 <pck.something> (gdb) p 0 - something'address Argument to arithmetic operation not a number or boolean. This patch enhances the Ada expression evaluator to handle these two situations. gdb/ChangeLog: * ada-lang.c (ada_evaluate_subexp) <BINOP_ADD>: Add handling of the case where the second operand is a pointer. <BINOP_SUB>: Likewise. gdb/testsuite/ChangeLog: * gdb.ada/addr_arith: New testcase. Tested on x86_64-linux.
2014-10-09 18:37:17 +02:00
2014-10-14 Joel Brobecker <brobecker@adacore.com>
* gdb.ada/addr_arith: New testcase.
gdb.dwarf2: Testsuite 64-bit pointer truncation fixes * gdb.dwarf2/dw2-case-insensitive-debug.S: Handle 64-bit pointers. * gdb.dwarf2/dw2-case-insensitive.exp: Update accordingly. * gdb.dwarf2/dw2-skip-prologue.S: Handle 64-bit pointers. * gdb.dwarf2/dw2-skip-prologue.exp: Update accordingly.
2014-10-14 22:16:07 +02:00
2014-10-14 Maciej W. Rozycki <macro@codesourcery.com>
* gdb.dwarf2/dw2-case-insensitive-debug.S: Handle 64-bit pointers.
* gdb.dwarf2/dw2-case-insensitive.exp: Update accordingly.
* gdb.dwarf2/dw2-skip-prologue.S: Handle 64-bit pointers.
* gdb.dwarf2/dw2-skip-prologue.exp: Update accordingly.
Explicitly use language_c when evaluating a SDT probe argument Joel contacted me offlist with a question about a warning that one of his customers was seeing. The message came from the new linker-debugger interface, which uses SDT probes internally. The warning said: (gdb) run [...] warning: Probes-based dynamic linker interface failed. Reverting to original interface. Argument to arithmetic operation not a number or boolean. This should not have happened in the environment the customer was using (RHEL-6.x), so I found it strange. Another thing caught my attention: the last message, saying "Argument to arithmetic operation not a number or boolean.". Joel kindly investigated the issue further, and found the answer for this. To quote him: (gdb) set lang c (gdb) p 48+$ebp $4 = (void *) 0xffffd0f8 So far so good. But... (gdb) set lang ada (gdb) p 48+$ebp Argument to arithmetic operation not a number or boolean. Ooops! Interestingly, if you revert the order of the operands... (gdb) p $ebp+48 $5 = (access void) 0xffffd0f8 So the problem is doing pointer arithmetics when the language is set to Ada. I remembered that, during the parsing and the evaluation of SDT probe arguments, the code sets the language as current_language, because, at that time, I thought it was not necessary to worry about the language given that the code implements its own parser. I was wrong. So here is a patch to fix that, by setting the language as C, which should guarantee that the maths are done in the right way (TM). It was somewhat hard to find a reproducer for this issue. In the end, what I had to do was to create a testcase that used the %ebp register on some displacement (e.g., "-4(%ebp)"), which finally triggered the bug. I am not sure why I could not trigger it when using other registers, but I did not want to spend too much time investigating this issue, which seemed like an Ada issue. Also, because of this peculiar way to trigger the problem, the testcase only covers x86-like targets (i.e., i*86 and x86_64 with -m32). Joel kindly tested this for me, and it worked. I also ran a full regression test here on my Fedora 20 x86_64, and everything is fine. I will push this patch in a few days if there are no comments. gdb/ChangeLog: 2014-10-14 Sergio Durigan Junior <sergiodj@redhat.com> * stap-probe.c (stap_parse_argument): Initialize expout explicitly using language_c, instead of current_language. gdb/testsuite/ChangeLog: 2014-10-14 Sergio Durigan Junior <sergiodj@redhat.com> * gdb.arch/stap-eval-lang-ada.S: Likewise. * gdb.arch/stap-eval-lang-ada.c: Likewise. * gdb.arch/stap-eval-lang-ada.exp: New file.
2014-10-14 20:31:09 +02:00
2014-10-14 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.arch/stap-eval-lang-ada.S: Likewise.
* gdb.arch/stap-eval-lang-ada.c: Likewise.
* gdb.arch/stap-eval-lang-ada.exp: New file.
Fix fail in mi-var-child.exp and mi-var-display.exp Hi, I see the following fails on arm-none-eabi target, -var-list-children --simple-values struct_declarations ^M ^done,numchild="11",children=[...,child={name="struct_declarations.func_ptr_struct",exp="func_ptr_struct",numchild="0",value="0x0 <_ftext>",type="struct _struct_decl (*)(int, char *, long)",thread-id="1"},child={name="struct_declarations.func_ptr_ptr",exp="func_ptr_ptr",numchild="0",value="0x0 <_ftext>",type="struct _struct_decl *(*)(int, char *, long)",thread-id="1"},... (gdb) ^M FAIL: gdb.mi/mi-var-child.exp: listing of children, simple types: names, type and values, complex types: names and types -var-set-format weird.func_ptr_ptr natural^M ^done,format="natural",value="0x0 <_ftext>"^M (gdb) ^M FAIL: gdb.mi/mi-var-display.exp: set format variable weird.func_ptr_ptr in natural In the test, "0x0" is expected, but "0x0 <_ftext>" is in the output. Function pointers point to address zero, and tests assume there is no symbol on address zero. However, on my arm-none-eabi target, there is a code symbol _ftext on address zero, and test fails. Note that "set print symbol off" doesn't take effect for function pointer. int (*f) (void); f = main; (gdb) p f $1 = (int (*)(void)) 0x8048400 <main> (gdb) set print symbol off (gdb) p f $2 = (int (*)(void)) 0x8048400 <main> In order to erase the difference, we can assign some function address explicitly to function pointer, so the test behaves in a unique way. In this patch, we assign nothing1 and nothing2 to function pointers func_ptr_struct and func_ptr_ptr respectively, and update test as the source file is changed. gdb/testsuite: 2014-10-14 Yao Qi <yao@codesourcery.com> * gdb.mi/mi-var-child.c (nothing1): New function. (nothing2): New function. (do_children_tests): Set function pointers by nothing1 and nothing2. * gdb.mi/mi-var-child.exp: Step over new added statements. Update test to match the new output. * gdb.mi/var-cmd.c (nothing1): New function. (nothing2): New function. (do_children_tests): Set function pointers by nothing1 and nothing2. * gdb.mi/mi-var-display.exp: Update test to match output. Step to the line specified by $line_dct_nothing. Increase the number of lines to step.
2014-08-30 15:30:36 +02:00
2014-10-14 Yao Qi <yao@codesourcery.com>
* gdb.mi/mi-var-child.c (nothing1): New function.
(nothing2): New function.
(do_children_tests): Set function pointers by nothing1 and
nothing2.
* gdb.mi/mi-var-child.exp: Step over new added statements.
Update test to match the new output.
* gdb.mi/var-cmd.c (nothing1): New function.
(nothing2): New function.
(do_children_tests): Set function pointers by nothing1 and
nothing2.
* gdb.mi/mi-var-display.exp: Update test to match output.
Step to the line specified by $line_dct_nothing.
Increase the number of lines to step.
Use mi_varobj_update in mi-var-child.exp and mi2-var-child.exp Hi, I modify mi-var-child.exp and find that the pattern to match the output of -var-update * is quite complicated. However, it can be simplified by using mi_varobj_update. That is what this patch does. gdb/testsuite: 2014-10-14 Yao Qi <yao@codesourcery.com> * gdb.mi/mi-var-child.exp: Use mi_varobj_update to simplify tests. * gdb.mi/mi2-var-child.exp: Likewise.
2014-08-23 14:24:07 +02:00
2014-10-14 Yao Qi <yao@codesourcery.com>
* gdb.mi/mi-var-child.exp: Use mi_varobj_update to simplify
tests.
* gdb.mi/mi2-var-child.exp: Likewise.
Change name of file name test in py-objfile.exp. Tests should each have their own name. gdb/testsuite/ChangeLog: * gdb.python/py-objfile.exp: Change name of file name test.
2014-10-13 23:50:32 +02:00
2014-10-13 Doug Evans <dje@google.com>
* gdb.python/py-objfile.exp: Change name of file name test.
Fix dw2-op-out-param.S CU offset values. This test will pass if the CU is the first CU in the binary. If libc debugging info is installed it may not be, in which case the CU offset values are wrong. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-op-out-param.S: Make DW_FORM_ref4 values be the offset from the start of the CU.
2014-10-13 23:05:34 +02:00
2014-10-13 Doug Evans <dje@google.com>
* gdb.dwarf2/dw2-op-out-param.S: Make DW_FORM_ref4 values be the offset
from the start of the CU.
Fix "save breakpoints" for "catch" command gdb/ChangeLog 2014-10-13 Miroslav Franc <mfranc@redhat.com> Jan Kratochvil <jan.kratochvil@redhat.com> Fix "save breakpoints" for "catch" command. * break-catch-sig.c (signal_catchpoint_print_recreate): Add trailing newline. gdb/testsuite/ChangeLog 2014-10-13 Jan Kratochvil <jan.kratochvil@redhat.com> Yao Qi <yao@codesourcery.com> Fix "save breakpoints" for "catch" command. * gdb.base/catch-signal.exp: Add gdb_breakpoint "main". Remove -nonewline. Match also the added "main" line.
2014-10-13 13:39:48 +02:00
2014-10-13 Jan Kratochvil <jan.kratochvil@redhat.com>
Yao Qi <yao@codesourcery.com>
Fix "save breakpoints" for "catch" command.
* gdb.base/catch-signal.exp: Add gdb_breakpoint "main".
Remove -nonewline. Match also the added "main" line.
Fix "save breakpoints" for "disable $bpnum" command. gdb/ChangeLog 2014-10-12 Miroslav Franc <mfranc@redhat.com> Fix "save breakpoints" for "disable $bpnum" command. * breakpoint.c (save_breakpoints): Add $bpnum for disable. gdb/testsuite/ChangeLog 2014-10-12 Jan Kratochvil <jan.kratochvil@redhat.com> Fix "save breakpoints" for "disable $bpnum" command. * gdb.base/save-bp.c (main): Add label. * gdb.base/save-bp.exp: Add 8th disabled breakpoint. Match it.
2014-10-12 21:52:39 +02:00
2014-10-12 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix "save breakpoints" for "disable $bpnum" command.
* gdb.base/save-bp.c (main): Add label.
* gdb.base/save-bp.exp: Add 8th disabled breakpoint. Match it.
Use gdb_test_sequence in gdb.base/save-bp.exp. But IMO it is a functionality regression as: * gdb_test_sequence permits arbitary number of lines of text between those lines being matched. Former regex string did not allow it. This may make a difference if GDB regresses by printing some unexpected line after the breakpoint info line (like a "silent" line). > * \[\r\n\]+ can be used to anchor the beginning of the pattern, in the sense > of Perl regex ^ /m match. At least I have found such cases in existing > *.exp files so I used that. Using ^ really does not work. > > But I am not aware how to do Perl regex $ /m match. Using $ really does > not work. But this means that for example the trailing > ( \\((host|target) evals\\))? > on the line > "\[\r\n\]+\[ \t\]+stop only if i == 1( \\((host|target) evals\\))?" > originally made sense there but now it can be removed as it has no longer > any functionality there - it will match now any trailing line garbage. by Yao Qi: In this test case, ( \\((host|target) evals\\))? isn't needed in the pattern. What we test here is to save breakpoints into file and restore them from file. The contents saved in file are: break save-bp.c:31 condition $bpnum i == 1 the information about the place where the condition is evaluated isn't saved, so we don't need to check. Breakpoint save and restore has nothing to do with where the condition is evaluated (host or target). I am fine to leave it here now. gdb/testsuite/ChangeLog 2014-10-09 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.base/save-bp.exp (info break): Use gdb_test_sequence.
2014-10-12 21:47:13 +02:00
2014-10-12 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/save-bp.exp (info break): Use gdb_test_sequence.
Enable qTStatus packet in case it is disabled Nowadays, we are using command "tstatus" to send a packet to GDBserver in order to check the connection. However, on the target doesn't support tracepoint, the following error is emitted before sending any packet to GDBserver. tstatus^M Trace can not be run on this target.^M (gdb) FAIL: gdb.server/server-kill.exp: tstatus qTStatus is disabled after receiving the empty reply during connecting to the remote target. When the test executes command "tstatus" again, remote_get_trace_status returns -1 at the very beginning, and no RSP packet is sent out. This patch is to enable qTStatus packet again. gdb/testsuite: 2014-10-11 Yao Qi <yao@codesourcery.com> * gdb.server/server-kill.exp: Execute command "set remote trace-status-packet on" before "tstatus".
2014-10-08 05:25:31 +02:00
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.server/server-kill.exp: Execute command
"set remote trace-status-packet on" before "tstatus".
Get GDBserver pid on remote target Hi, We see the following fail in the real remote testing... (gdb) Executing on target: kill -9 29808 (timeout = 300) spawn [open ...]^M sh: 1: kill: No such process The test tries to kill gdbserver in this way: set server_pid [exp_pid -i [board_info target fileid]] remote_exec target "kill -9 $server_pid" in native testing, we'll get the pid of spawned gdbserver, however, in remote testing, we'll get the pid of ssh session, since we start gdbserver on the remote target through ssh. The pid on build doesn't exist on target. In this patch, we tweak server-kill.c to get the parent pid, which is the pid of GDBserver. GDB gets it and kill GDBserver on target. gdb/testsuite: 2014-10-11 Yao Qi <yao@codesourcery.com> * gdb.server/server-kill.c: Include sys/types.h and unistd.h. (main): Call getppid. * gdb.server/server-kill.exp: Set breakpoint on line "i = 0;" and continue to it. Read variable "server_pid".
2014-09-30 15:08:15 +02:00
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.server/server-kill.c: Include sys/types.h and unistd.h.
(main): Call getppid.
* gdb.server/server-kill.exp: Set breakpoint on line "i = 0;"
and continue to it. Read variable "server_pid".
Clean up server-kill.exp This patch is to remove some lines which looks unnecessary. These lines were added when server-kill.exp was added. In the version 1, https://sourceware.org/ml/gdb-patches/2013-03/msg00691.html the test calls runto_main and delete breakpoint on main, +if ![runto_main] { + return -1 +} + +# Otherwise the breakpoint at 'main' would not cause insert breakpoints during +# first step. +delete_breakpoints However, in the version 2 https://sourceware.org/ml/gdb-patches/2013-03/msg00854.html runto_main is removed but delete_breakpoints is still there. AFAICS, the line of delete_breakpoints can be removed too. gdb/testsuite: 2014-10-11 Yao Qi <yao@codesourcery.com> * gdb.server/server-kill.exp: Remove "delete_breakpoints".
2014-10-08 04:04:22 +02:00
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.server/server-kill.exp: Remove "delete_breakpoints".
No longer pull thread list explicitly As the result of the patch below, GDB updates thread list when a stop is presented to user. The tests don't have to fetch thread list explicitly. [PATCH 3/3] Fix non-stop regressions caused by "breakpoints always-inserted off" changes https://sourceware.org/ml/gdb-patches/2014-09/msg00734.html This patch is to remove the test code updating thread list. Run these three tests many times on arm-linux-gnueabi and x86-linux. No regressions. gdb/testsuite: 2014-10-11 Yao Qi <yao@codesourcery.com> * gdb.threads/thread-find.exp: Don't execute command "info threads". * gdb.threads/attach-into-signal.exp (corefunc): Likewise. * gdb.threads/linux-dp.exp: Don't check the condition $threads_created equals to zero.
2014-10-08 16:26:27 +02:00
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.threads/thread-find.exp: Don't execute command
"info threads".
* gdb.threads/attach-into-signal.exp (corefunc): Likewise.
* gdb.threads/linux-dp.exp: Don't check the condition
$threads_created equals to zero.
Delete IRIX support This does most of the mechanical removal. IOW, the easy part. This doesn't touch procfs.c as that'd be a harder excision, potentially affecting Solaris. mips-tdep.c is left alone. E.g., I didn't delete the GDB_OSABI_IRIX enum value, nor references to it in mips-tdep.c. Some comments mentioning IRIX ABIs may still be relevant and I wouldn't know what to do with them. in That can always be done on a separate pass, preferably by someone who can test on MIPS. I didn't remove a reference to IRIX in testsuite/lib/future.exp, as I believe that code is imported from DejaGNU. Built and tested on x86_64 Fedora 20, with --enable-targets=all. Tested that building for --target=mips-sgi-irix6 on x86_64 Fedora 20 fails with: checking for default auto-load directory... $debugdir:$datadir/auto-load checking for default auto-load safe-path... $debugdir:$datadir/auto-load *** Configuration mips-sgi-irix6 is obsolete. *** Support has been REMOVED. make[1]: *** [configure-gdb] Error 1 make[1]: Leaving directory `/home/pedro/gdb/mygit/build-irix' make: *** [all] Error 2 gdb/ 2014-10-10 Pedro Alves <palves@redhat.com> * Makefile.in (ALL_TARGET_OBS): Remove mips-irix-tdep.o and solib-irix.o. (ALLDEPFILES): Remove mips-irix-tdep.c and solib-irix.c. (HFILES_NO_SRCDIR): Remove solib-irix.h. * NEWS: Mention that support for mips-sgi-irix5* mips-sgi-irix6* and been removed. * config/mips/irix5.mh, config/mips/irix6.mh: Delete files. * configure.ac: Remove references to IRIX. * configure.host: Add *-*-irix* to the obsolete hosts section. Remove all other references to irix. * irix5-nat.c, mips-irix-tdep.c, solib-irix.c, solib-irix.h: Delete files. gdb/testsuite/ 2014-10-10 Pedro Alves <palves@redhat.com> * gdb.base/bigcore.exp: Remove references to IRIX. * gdb.base/funcargs.exp: Likewise. * gdb.base/interrupt.exp: Likewise. * gdb.base/mips_pro.exp: Likewise. * gdb.base/nodebug.exp: Likewise. * gdb.base/setvar.exp: Likewise. * lib/gdb.exp (gdb_compile_shlib): Remove mips-sgi-irix* case.
2014-10-10 19:18:52 +02:00
2014-10-10 Pedro Alves <palves@redhat.com>
* gdb.base/bigcore.exp: Remove references to IRIX.
* gdb.base/funcargs.exp: Likewise.
* gdb.base/interrupt.exp: Likewise.
* gdb.base/mips_pro.exp: Likewise.
* gdb.base/nodebug.exp: Likewise.
* gdb.base/setvar.exp: Likewise.
* lib/gdb.exp (gdb_compile_shlib): Remove mips-sgi-irix* case.
PR symtab/14466: Work around PR libc/13097 "linux-vdso.so.1" With upstream glibc, GDB prints: warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? A bug's been filed for glibc a few years back: http://sourceware.org/bugzilla/show_bug.cgi?id=13097 but it's still not resolved. It's not clear whether there's even consensus that this is indeed a glibc bug. It would actually be nice if GDB also listed the vDSO in the shared library list, but there are some design considerations with that: - the vDSO is mapped by the kernel, not userspace, therefore we should load its symbols right from the process's start of life, even before glibc / the userspace loader sets up the initial DSO list. The program might even be using a custom loader or no loader. - that kind of hints at that solib.c should handle retrieving shared library lists from more than one source, and that symfile-mem.c's loading of the vDSO would be converted to load and relocate the vDSO's bfd behind the target_so_ops interface. - and then, once glibc links in the vDSO to its DSO list, we'd need to either: a) somehow hand over the vDSO from one target_so_ops to the other b) simply keep hiding glibc's entry. And then b) seems the simplest. With that in mind, this patch simply discards the vDSO from glibc's reported shared library list. We can match the vDSO address range with the addresses found iterating the dynamic linker list, to tell which dynamic linker entry is the vDSO. Tested on x86_64 Fedora 20. gdb/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * solib-svr4.c (svr4_read_so_list): Rename to ... (svr4_current_sos_1): ... this and change the function comment. (svr4_current_sos): New function. gdb/testsuite/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * gdb.base/vdso-warning.c: New file. * gdb.base/vdso-warning.exp: New file.
2014-10-10 16:57:13 +02:00
2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
PR symtab/14466
* gdb.base/vdso-warning.c: New file.
* gdb.base/vdso-warning.exp: New file.
gdb.base/structs.c (main): Don't run forever. gdb/testsuite/ChangeLog: * gdb.base/structs.c (main): Don't run forever.
2014-10-02 22:07:40 +02:00
2014-10-02 Doug Evans <dje@google.com>
* gdb.base/structs.c (main): Don't run forever.
gdb.threads/manythreads.exp: clean up and add comment In git b57bacec, I said: > With that in place, the need to delay "Program received signal FOO" > was actually caught by the manythreads.exp test. Without that bit, I > was getting: > > [Thread 0x7ffff7f13700 (LWP 4499) exited] > [New Thread 0x7ffff7f0b700 (LWP 4500)] > ^C > Program received signal SIGINT, Interrupt. > [New Thread 0x7ffff7f03700 (LWP 4501)] <<< new output > [Switching to Thread 0x7ffff7f0b700 (LWP 4500)] > __GI___nptl_death_event () at events.c:31 > 31 { > (gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1 > > That is, I was now getting "New Thread" lines after the "Program > received signal" line, and the test doesn't expect them. As the > number of new threads discovered before and after the "Program > received signal" output is unbounded, it's much nicer to defer > "Program received signal" until after synching the thread list, thus > close to the "switching to thread" output and "current frame/source" > info: > > [Thread 0x7ffff7863700 (LWP 7647) exited] > ^C[New Thread 0x7ffff786b700 (LWP 7648)] > > Program received signal SIGINT, Interrupt. > [Switching to Thread 0x7ffff7fc4740 (LWP 6243)] > __GI___nptl_create_event () at events.c:25 > 25 { > (gdb) PASS: gdb.threads/manythreads.exp: stop threads 1 This commit factors out the two places in the test that are effected by this, and adds there a destilled version of the comment above. gdb/testsuite/ 2014-10-02 Pedro Alves <palves@redhat.com> * gdb.threads/manythreads.exp (interrupt_and_wait): New procedure. (top level) <stop threads 1, stop threads 2>: Use it.
2014-09-24 19:59:42 +02:00
2014-10-02 Pedro Alves <palves@redhat.com>
* gdb.threads/manythreads.exp (interrupt_and_wait): New procedure.
(top level) <stop threads 1, stop threads 2>: Use it.
Fix non-stop regressions caused by "breakpoints always-inserted off" changes Commit a25a5a45 (Fix "breakpoint always-inserted off"; remove "breakpoint always-inserted auto") regressed non-stop remote debugging. This was exposed by mi-nsintrall.exp intermittently failing with a spurious SIGTRAP. The problem is that when debugging with "target remote", new threads the target has spawned but have never reported a stop aren't visible to GDB until it explicitly resyncs its thread list with the target's. For example, in a program like this: int main (void) { pthread_t child_thread; pthread_create (&child_thread, NULL, child_function, NULL); return 0; <<<< set breakpoint here } If the user sets a breakpoint at the "return" statement, and runs the program, when that breakpoint hit is reported, GDB is only aware of the main thread. So if we base the decision to remove or insert breakpoints from the target based on whether all the threads we know about are stopped, we'll miss that child_thread is running, and thus we'll remove breakpoints from the target, even through they should still remain inserted, otherwise child_thread will miss them. The break-while-running.exp test actually should also be exposing this thread-list-out-of-synch problem. That test sets a breakpoint while the main thread is stopped, but other threads are running. Because other threads are running, the breakpoint is supposed to be inserted immediately. But, unless something forces a refetch of the thread list, like, e.g., "info threads", GDB won't be aware of the other threads that had been spawned by the main thread, and so won't insert new or old breakpoints in the target. And it turns out that the test is exactly doing an explicit "info threads", masking out the problem... This commit adjust the test to exercise the case of not issuing "info threads". The test then fails without the GDB fix. In the ni-nsintrall.exp case, what happens is that several threads hit the same breakpoint, and when the first thread reports the stop, because GDB wasn't aware other threads exist, all threads known to GDB are found stopped, so GDB removes the breakpoints from the target. The other threads follow up with SIGTRAPs too for that same breakpoint, which has already been removed. For the first few threads, the moribund breakpoints machinery suppresses the SIGTRAPs, but after a few events (precisely '3 * thread_count () + 1' at the time the breakpoint was removed, see update_global_location_list), the moribund breakpoint machinery is no longer aware of the removed breakpoint, and the SIGTRAP is reported as a spurious stop. The fix is naturally then to stop assuming that if no thread in the list is executing, then the target is fully stopped. We can't know that until we fully sync the thread list. Because updating the thread list on every stop would be too much RSP traffic, I chose instead to update it whenever we're about to present a stop to the user. Actually updating the thread list at that point happens to be an item I had added to the local/remote parity wiki page a while ago: Native GNU/Linux debugging adds new threads to the thread list as the program creates them "The [New Thread foo] messages". Remote debugging can't do that, and it's arguable whether we shouldn't even stop native debugging from doing that, as it hinders inferior performance. However, a related issue is that with remote targets (and gdbserver), even after the program stops, the user still needs to do "info threads" to pull an updated thread list. This, should most likely be addressed, so that GDB pulls the list itself, perhaps just before presenting a stop to the user. With that in place, the need to delay "Program received signal FOO" was actually caught by the manythreads.exp test. Without that bit, I was getting: [Thread 0x7ffff7f13700 (LWP 4499) exited] [New Thread 0x7ffff7f0b700 (LWP 4500)] ^C Program received signal SIGINT, Interrupt. [New Thread 0x7ffff7f03700 (LWP 4501)] <<< new output [Switching to Thread 0x7ffff7f0b700 (LWP 4500)] __GI___nptl_death_event () at events.c:31 31 { (gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1 That is, I was now getting "New Thread" lines after the "Program received signal" line, and the test doesn't expect them. As the number of new threads discovered before and after the "Program received signal" output is unbounded, it's much nicer to defer "Program received signal" until after synching the thread list, thus close to the "switching to thread" output and "current frame/source" info: [Thread 0x7ffff7863700 (LWP 7647) exited] ^C[New Thread 0x7ffff786b700 (LWP 7648)] Program received signal SIGINT, Interrupt. [Switching to Thread 0x7ffff7fc4740 (LWP 6243)] __GI___nptl_create_event () at events.c:25 25 { (gdb) PASS: gdb.threads/manythreads.exp: stop threads 1 Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-02 Pedro Alves <palves@redhat.com> * breakpoint.c (breakpoints_should_be_inserted_now): Use threads_are_executing. * breakpoint.h (breakpoints_should_be_inserted_now): Add describing comment. * gdbthread.h (threads_are_executing): Declare. (handle_signal_stop) <random signals>: Don't print about the signal here if stopping. (end_stepping_range): Don't notify observers here. (normal_stop): Update the thread list. If stopped by a random signal or a stepping range ended, notify observers. * thread.c (threads_executing): New global. (init_thread_list): Clear 'threads_executing'. (set_executing): Set or clear 'threads_executing'. (threads_are_executing): New function. (update_threads_executing): New function. (update_thread_list): Use it. gdb/testsuite/ 2014-10-02 Pedro Alves <palves@redhat.com> * gdb.threads/break-while-running.exp (test): Add new 'update_thread_list' argument. Skip "info threads" if false. (top level): Add new 'update_thread_list' axis.
2014-10-02 10:55:38 +02:00
2014-10-02 Pedro Alves <palves@redhat.com>
* gdb.threads/break-while-running.exp (test): Add new
'update_thread_list' argument. Skip "info threads" if false.
(top level): Add new 'update_thread_list' axis.
PR17431: following execs with "breakpoint always-inserted on" Following an exec with "breakpoint always-inserted on" tries to insert breakpoints in the new image at the addresses the symbols had in the old image. With "always-inserted off", we see: gdb gdb.multi/multi-arch-exec -ex "set breakpoint always-inserted off" GNU gdb (GDB) 7.8.50.20140924-cvs ... (gdb) b main Breakpoint 1 at 0x400664: file gdb.multi/multi-arch-exec.c, line 24. ^^^^^^^^ (gdb) c The program is not being run. (gdb) r Starting program: testsuite/gdb.multi/multi-arch-exec Breakpoint 1, main () at gdb/testsuite/gdb.multi/multi-arch-exec.c:24 24 execl (BASEDIR "/multi-arch-exec-hello", (gdb) c Continuing. process 9212 is executing new program: gdb/testsuite/gdb.multi/multi-arch-exec-hello Breakpoint 1, main () at gdb/testsuite/gdb.multi/hello.c:40 40 bar(); (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x080484e4 in main at gdb/testsuite/gdb.multi/hello.c:40 ^^^^^^^^^^ breakpoint already hit 2 times (gdb) Note how main was 0x400664 in multi-arch-exec, and 0x080484e4 in gdb.multi/hello. With "always-inserted on", we get: Breakpoint 1, main () at gdb/testsuite/gdb.multi/multi-arch-exec.c:24 24 execl (BASEDIR "/multi-arch-exec-hello", (gdb) c Continuing. infrun: target_wait (-1, status) = infrun: 9444 [process 9444], infrun: status->kind = execd infrun: infwait_normal_state infrun: TARGET_WAITKIND_EXECD Warning: Cannot insert breakpoint 1. Cannot access memory at address 0x400664 (gdb) That is, GDB is trying to insert a breakpoint at 0x400664, after the exec, and then that address happens to not be mapped at all in the new image. The problem is that update_breakpoints_after_exec is creating breakpoints, which ends up in update_global_location_list immediately inserting breakpoints if "breakpoints always-inserted" is "on". update_breakpoints_after_exec is called very early when we see an exec event. At that point, we haven't loaded the symbols of the new post-exec image yet, and thus haven't reset breakpoint's addresses to whatever they may be in the new image. All we should be doing in update_breakpoints_after_exec is deleting breakpoints that no longer make sense after an exec. So the fix removes those breakpoint creations. The question is then, if not here, where are those breakpoints re-created? Turns out we don't need to do anything else, because at the end of follow_exec, we call breakpoint_re_set, whose tail is also creating exactly the same breakpoints update_breakpoints_after_exec is currently creating: breakpoint_re_set (void) { ... create_overlay_event_breakpoint (); create_longjmp_master_breakpoint (); create_std_terminate_master_breakpoint (); create_exception_master_breakpoint (); } A new test is added to exercise this. Tested on x86_64 Fedora 20. gdb/ 2014-10-02 Pedro Alves <palves@redhat.com> PR breakpoints/17431 * breakpoint.c (update_breakpoints_after_exec): Don't create overlay, longjmp, std terminate nor exception breakpoints here. gdb/testsuite/ 2014-10-02 Pedro Alves <palves@redhat.com> PR breakpoints/17431 * gdb.base/execl-update-breakpoints.c: New file. * gdb.base/execl-update-breakpoints.exp: New file.
2014-10-02 10:55:38 +02:00
2014-10-02 Pedro Alves <palves@redhat.com>
PR breakpoints/17431
* gdb.base/execl-update-breakpoints.c: New file.
* gdb.base/execl-update-breakpoints.exp: New file.
Really fail inserting software breakpoints on read-only regions Currently, with "set breakpoint auto-hw off", we'll still try to insert a software breakpoint at addresses covered by supposedly read-only or inacessible regions: (top-gdb) mem 0x443000 0x450000 ro (top-gdb) set mem inaccessible-by-default off (top-gdb) disassemble Dump of assembler code for function main: 0x0000000000443956 <+34>: movq $0x0,0x10(%rax) => 0x000000000044395e <+42>: movq $0x0,0x18(%rax) 0x0000000000443966 <+50>: mov -0x24(%rbp),%eax 0x0000000000443969 <+53>: mov %eax,-0x20(%rbp) End of assembler dump. (top-gdb) b *0x0000000000443969 Breakpoint 5 at 0x443969: file ../../src/gdb/gdb.c, line 29. (top-gdb) c Continuing. warning: cannot set software breakpoint at readonly address 0x443969 Breakpoint 5, 0x0000000000443969 in main (argc=1, argv=0x7fffffffd918) at ../../src/gdb/gdb.c:29 29 args.argc = argc; (top-gdb) We warn, saying that the insertion can't be done, but then proceed attempting the insertion anyway, and in case of manually added regions, the insert actually succeeds. This is a regression; GDB used to fail inserting the breakpoint. More below. I stumbled on this as I wrote a test that manually sets up a read-only memory region with the "mem" command, in order to test GDB's behavior with breakpoints set on read-only regions, even when the real memory the breakpoints are set at isn't really read-only. I wanted that in order to add a test that exercises software single-stepping through read-only regions. Note that the memory regions that target_memory_map returns aren't like e.g., what would expect to see in /proc/PID/maps on Linux. Instead, they're the physical memory map from the _debuggers_ perspective. E.g., a read-only region would be real ROM or flash memory, while a read-only+execute mapping in /proc/PID/maps is still read-write to the debugger (otherwise the debugger wouldn't be able to set software breakpoints in the code segment). If one tries to manually write to memory that falls within a memory region that is known to be read-only, with e.g., "p foo = 1", then we hit a check in memory_xfer_partial_1 before the write mananges to make it to the target side. But writing a software/memory breakpoint nowadays goes through target_write_raw_memory, and unlike when writing memory with TARGET_OBJECT_MEMORY, nothing on the TARGET_OBJECT_RAW_MEMORY path checks whether we're trying to write to a read-only region. At the time "breakpoint auto-hw" was added, we didn't have the TARGET_OBJECT_MEMORY vs TARGET_OBJECT_RAW_MEMORY target object distinction yet, and the code path in memory_xfer_partial that blocks writes to read-only memory was hit for memory breakpoints too. With GDB 6.8 we had: warning: cannot set software breakpoint at readonly address 0000000000443943 Warning: Cannot insert breakpoint 1. Error accessing memory address 0x443943: Input/output error. So I started out by fixing this by adding the memory region validation to TARGET_OBJECT_RAW_MEMORY too. But later, when testing against GDBserver, I realized that that would only block software/memory breakpoints GDB itself inserts with gdb/mem-break.c. If a target has a to_insert_breakpoint method, the insertion request will still pass through to the target. So I ended up converting the "cannot set breakpoint" warning in breakpoint.c to a real error return, thus blocking the insertion sooner. With that, we'll end up no longer needing the TARGET_OBJECT_RAW_MEMORY changes once software single-step breakpoints are converted to real breakpoints. We need them today as software single-step breakpoints bypass insert_bp_location. But, it'll be best to leave that in as safeguard anyway, for other direct uses of TARGET_OBJECT_RAW_MEMORY. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-01 Pedro Alves <palves@redhat.com> * breakpoint.c (insert_bp_location): Error out if inserting a software breakpoint at a read-only address. * target.c (memory_xfer_check_region): New function, factored out from ... (memory_xfer_partial_1): ... this. Make the 'reg_len' local a ULONGEST. (target_xfer_partial) <TARGET_OBJECT_RAW_MEMORY>: Check the access against the memory region attributes. gdb/testsuite/ 2014-10-01 Pedro Alves <palves@redhat.com> * gdb.base/breakpoint-in-ro-region.c: New file. * gdb.base/breakpoint-in-ro-region.exp: New file.
2014-10-02 00:31:55 +02:00
2014-10-01 Pedro Alves <palves@redhat.com>
* gdb.base/breakpoint-in-ro-region.c: New file.
* gdb.base/breakpoint-in-ro-region.exp: New file.
Exit code of exited inferiors in -list-thread-groups Don't reset the exit code at inferior exit and print it in -list-thread-groups. gdb/ChangeLog: * NEWS: Announce new exit-code field in -list-thread-groups output. * inferior.c (exit_inferior_1): Don't clear exit code. (inferior_appeared): Clear exit code. * mi/mi-main.c (print_one_inferior): Add printing of the exit code. gdb/testsuite/ChangeLog: * gdb.mi/mi-exit-code.exp: New file. * gdb.mi/mi-exit-code.c: New file. gdb/doc/ChangeLog: * gdb.texinfo (Miscellaneous gdb/mi Commands): Document new exit-code field in -list-thread-groups output.
2014-09-29 23:33:09 +02:00
2014-10-01 Simon Marchi <simon.marchi@ericsson.com>
* gdb.mi/mi-exit-code.exp: New file.
* gdb.mi/mi-exit-code.c: New file.
Error in build_executable_own_libs for non-native target gdb/testsuite: 2014-09-30 Yao Qi <yao@codesourcery.com> * lib/prelink-support.exp (build_executable_own_libs): Error if the target isn't native.
2014-09-28 05:43:46 +02:00
2014-09-30 Yao Qi <yao@codesourcery.com>
* lib/prelink-support.exp (build_executable_own_libs): Error if
the target isn't native.
Skip dlopen-libpthread.exp in cross testing I see the following fails on arm-linux-gnueabi, result of ldd build-git/arm/gdb/testsuite/gdb.threads/dlopen-libpthread.so is 1 output of ldd build-git/arm/gdb/testsuite/gdb.threads/dlopen-libpthread.so is not a dynamic executable child process exited abnormally FAIL: gdb.threads/dlopen-libpthread.exp: ldd dlopen-libpthread.so FAIL: gdb.threads/dlopen-libpthread.exp: ldd dlopen-libpthread.so output contains libs the test script invokes ldd (on host) for the target libraries, which is wrong. ldd can't be cross because it invokes dynamic linker with LD_TRACE_LOADED_OBJECTS and gets the dependent libraries. My first reaction to this problem is to execute ld.so on the target (like remote_exec target). When I start to hack proc build_executable_own_libs, I find it has assumptions here and there that the native testing is performed. Then I check the callers of build_executable_own_libs, and they are all skipped if isnative is false. It is reasonable to do the same in dlopen-libpthread.exp too. gdb/testsuite: 2014-09-30 Yao Qi <yao@codesourcery.com> * gdb.threads/dlopen-libpthread.exp: Skip it if isnative is false.
2014-09-25 09:50:07 +02:00
2014-09-30 Yao Qi <yao@codesourcery.com>
* gdb.threads/dlopen-libpthread.exp: Skip it if isnative is
false.
Fix "breakpoint always-inserted off"; remove "breakpoint always-inserted auto" By default, GDB removes all breakpoints from the target when the target stops and the prompt is given back to the user. This is useful in case GDB crashes while the user is interacting, as otherwise, there's a higher chance breakpoints would be left planted on the target. But, as long as any thread is running free, we need to make sure to keep breakpoints inserted, lest a thread misses a breakpoint. With that in mind, in preparation for non-stop mode, we added a "breakpoint always-inserted on" mode. This traded off the extra crash protection for never having threads miss breakpoints, and in addition is more efficient if there's a ton of breakpoints to remove/insert at each user command (e.g., at each "step"). When we added non-stop mode, and for a period, we required users to manually set "always-inserted on" when they enabled non-stop mode, as otherwise GDB removes all breakpoints from the target as soon as any thread stops, which means the other threads still running will miss breakpoints. The test added by this patch exercises this. That soon revealed a nuisance, and so later we added an extra "breakpoint always-inserted auto" mode, that made GDB behave like "always-inserted on" when non-stop was enabled, and "always-inserted off" when non-stop was disabled. "auto" was made the default at the same time. In hindsight, this "auto" setting was unnecessary, and not the ideal solution. Non-stop mode does depends on breakpoints always-inserted mode, but only as long as any thread is running. If no thread is running, no breakpoint can be missed. The same is true for all-stop too. E.g., if, in all-stop mode, and the user does: (gdb) c& (gdb) b foo That breakpoint at "foo" should be inserted immediately, but it currently isn't -- currently it'll end up inserted only if the target happens to trip on some event, and is re-resumed, e.g., an internal breakpoint triggers that doesn't cause a user-visible stop, and so we end up in keep_going calling insert_breakpoints. The test added by this patch also covers this. IOW, no matter whether in non-stop or all-stop, if the target fully stops, we can remove breakpoints. And no matter whether in all-stop or non-stop, if any thread is running in the target, then we need breakpoints to be immediately inserted. And then, if the target has global breakpoints, we need to keep breakpoints even when the target is stopped. So with that in mind, and aiming at reducing all-stop vs non-stop differences for all-stop-on-stop-of-non-stop, this patch fixes "breakpoint always-inserted off" to not remove breakpoints from the target until it fully stops, and then removes the "auto" setting as unnecessary. I propose removing it straight away rather than keeping it as an alias, unless someone complains they have scripts that need it and that can't adjust. Tested on x86_64 Fedora 20. gdb/ 2014-09-22 Pedro Alves <palves@redhat.com> * NEWS: Mention merge of "breakpoint always-inserted" modes "off" and "auto" merged. * breakpoint.c (enum ugll_insert_mode): New enum. (always_inserted_mode): Now a plain boolean. (show_always_inserted_mode): No longer handle AUTO_BOOLEAN_AUTO. (breakpoints_always_inserted_mode): Delete. (breakpoints_should_be_inserted_now): New function. (insert_breakpoints): Pass UGLL_INSERT to update_global_location_list instead of calling insert_breakpoint_locations manually. (create_solib_event_breakpoint_1): New, factored out from ... (create_solib_event_breakpoint): ... this. (create_and_insert_solib_event_breakpoint): Use create_solib_event_breakpoint_1 instead of calling insert_breakpoint_locations manually. (update_global_location_list): Change parameter type from boolean to enum ugll_insert_mode. All callers adjusted. Adjust to use breakpoints_should_be_inserted_now and handle UGLL_INSERT. (update_global_location_list_nothrow): Change parameter type from boolean to enum ugll_insert_mode. (_initialize_breakpoint): "breakpoint always-inserted" option is now a boolean command. Update help text. * breakpoint.h (breakpoints_always_inserted_mode): Delete declaration. (breakpoints_should_be_inserted_now): New declaration. * infrun.c (handle_inferior_event) <TARGET_WAITKIND_LOADED>: Remove breakpoints_always_inserted_mode check. (normal_stop): Adjust to use breakpoints_should_be_inserted_now. * remote.c (remote_start_remote): Likewise. gdb/doc/ 2014-09-22 Pedro Alves <palves@redhat.com> * gdb.texinfo (Set Breaks): Document that "set breakpoint always-inserted off" is the default mode now. Delete documentation of "set breakpoint always-inserted auto". gdb/testsuite/ 2014-09-22 Pedro Alves <palves@redhat.com> * gdb.threads/break-while-running.exp: New file. * gdb.threads/break-while-running.c: New file.
2014-09-22 10:56:55 +02:00
2014-09-22 Pedro Alves <palves@redhat.com>
* gdb.threads/break-while-running.exp: New file.
* gdb.threads/break-while-running.c: New file.
Run dw2-var-zero-addr.exp with --readnow This patch is to extend dw2-var-zero-add.exp to cover the case that partial symtabl is not used while full symtab is used, in order to cover the changes in patch 2/3. This patch restarts GDB with --readnow and does the same test again. gdb/testsuite: 2014-09-19 Yao Qi <yao@codesourcery.com> * gdb.dwarf2/dw2-var-zero-addr.exp: Move test into new proc test. Invoke test. Restart GDB with --readnow and invoke test again.
2014-08-18 03:57:40 +02:00
2014-09-19 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dw2-var-zero-addr.exp: Move test into new proc test.
Invoke test. Restart GDB with --readnow and invoke test again.
Check function is GC'ed I see the following fail on arm-none-eabi target, (gdb) b 24^M Breakpoint 1 at 0x4: file ../../../../git/gdb/testsuite/gdb.base/break-on-linker-gcd-function.cc, line 24.^M (gdb) FAIL: gdb.base/break-on-linker-gcd-function.exp: b 24 Currently, we are using flag has_section_at_zero to determine whether address zero in debug info means the corresponding code has been GC'ed, like this: case DW_LNE_set_address: address = read_address (abfd, line_ptr, cu, &bytes_read); if (address == 0 && !dwarf2_per_objfile->has_section_at_zero) { /* This line table is for a function which has been GCd by the linker. Ignore it. PR gdb/12528 */ However, this is incorrect on some bare metal targets, as .text section is located at 0x0, so dwarf2_per_objfile->has_section_at_zero is true. If a function is GC'ed by linker, the address is zero. GDB thinks address zero is a function's address rather than this function is GC'ed. In this patch, we choose 'lowpc' got in read_file_scope to check whether 'lowpc' is greater than zero. If it isn't, address zero really means the function is GC'ed. In this patch, we pass 'lowpc' in read_file_scope through handle_DW_AT_stmt_list and dwarf_decode_lines, and to dwarf_decode_lines_1 finally. This patch fixes the fail above. This patch also covers the path that partial symbol isn't used, which is tested by starting gdb with --readnow option. It is regression tested on x86-linux with target_board=dwarf4-gdb-index, and arm-none-eabi. OK to apply? gdb: 2014-09-19 Yao Qi <yao@codesourcery.com> * dwarf2read.c (dwarf_decode_lines): Update declaration. (handle_DW_AT_stmt_list): Add argument 'lowpc'. Update comments. Callers update. (dwarf_decode_lines): Likewise. (dwarf_decode_lines_1): Add argument 'lowpc'. Update comments. Skip the line table if 'lowpc' is greater than 'address'. Don't check dwarf2_per_objfile->has_section_at_zero. gdb/testsuite: 2014-09-19 Yao Qi <yao@codesourcery.com> * gdb.base/break-on-linker-gcd-function.exp: Move test into new proc set_breakpoint_on_gcd_function. Invoke set_breakpoint_on_gcd_function. Restart GDB with --readnow and invoke set_breakpoint_on_gcd_function again.
2014-08-04 08:57:22 +02:00
2014-09-19 Yao Qi <yao@codesourcery.com>
* gdb.base/break-on-linker-gcd-function.exp: Move test into new
proc set_breakpoint_on_gcd_function. Invoke
set_breakpoint_on_gcd_function. Restart GDB with --readnow and
invoke set_breakpoint_on_gcd_function again.
New "producer" attribute of python gdb.Symtab. gdb/ChangeLog: * NEWS: Mention new "producer" attribute of gdb.Symtab. * python/py-symtab.c (stpy_get_producer): New function. (symtab_object_getset): Add "producer" attribute. gdb/doc/ChangeLog: * python.texi (Symbol Tables In Python): Document "producer" attribute of gdb.Symtab objects. gdb/testsuite/ChangeLog: * gdb.dwarf2/symtab-producer.exp: New file.
2014-09-18 19:09:12 +02:00
2014-09-18 Doug Evans <dje@google.com>
* gdb.dwarf2/symtab-producer.exp: New file.
Add test for global variable that is nested by another DSO This is just a testcase addition that I am proposing for upstream GDB. We have this in our internal tree, and the related RH bug is: <https://bugzilla.redhat.com/show_bug.cgi?id=809179> (You might not be able to see all the comments without privileges.) This bug is about a global variable that got incorrectly displayed by GDB. This bug has already been fixed a long time ago by Joel's commit: commit 19630284f570790ebf6d50bfb43caa1f125ee88a Author: Joel Brobecker <brobecker@gnat.com> Date: Tue Jun 5 13:50:50 2012 +0000 But I think a testcase for it wouldn't hurt. So, consider the following scenario: $ cat solib1.c int test; void c_main (void) { test = 42; } $ cat solib2.c int test; void b_main (void) { test = 42; } $ cat main.c int main (int argc, char *argv[]) { c_main (); b_main (); return 0; } $ gcc -g -fPIC -shared -o libSO1.so -c solib1.c $ gcc -g -fPIC -shared -o libSO2.so -c solib2.c $ gcc -g -o main -L$PWD -lSO1 -lSO2 main.c $ LD_LIBRARY_PATH=. gdb -q -batch -ex 'b c_main' -ex r -ex n -ex 'p test' ./main ... $1 = 0 This happened with GDB before Joel's commit above. Now, things work and GDB is able to correctly display the nested global variable: $ LD_LIBRARY_PATH=. gdb -q -batch -ex 'b c_main' -ex r -ex n -ex 'p test' ./main ... $1 = 42 The testcase attached tests this behavior. gdb/testsuite/ChangeLog: 2014-09-16 Sergio Durigan Junior <sergiodj@redhat.com> * gdb.base/global-var-nested-by-dso-solib1.c: New file. * gdb.base/global-var-nested-by-dso-solib2.c: Likewise. * gdb.base/global-var-nested-by-dso.c: Likewise. * gdb.base/global-var-nested-by-dso.exp: Likewise.
2014-09-17 04:54:03 +02:00
2014-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/global-var-nested-by-dso-solib1.c: New file.
* gdb.base/global-var-nested-by-dso-solib2.c: Likewise.
* gdb.base/global-var-nested-by-dso.c: Likewise.
* gdb.base/global-var-nested-by-dso.exp: Likewise.
gdb.base/watch-bitfields.exp: Improve test Make test messages unique and a couple other tweaks. gdb/testsuite/ 2014-09-16 Sergio Durigan Junior <sergiodj@redhat.com> Pedro Alves <palves@redhat.com> * gdb.base/watch-bitfields.exp: Pass string other than test file name to prepare_for_testing. (watch): New procedure. (expect_watchpoint): Use with_test_prefix. (top level): Factor out tests to ... (test_watch_location, test_regular_watch): ... these new procedures, and use with_test_prefix and gdb_continue_to_end.
2014-09-16 18:55:20 +02:00
2014-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
* gdb.base/watch-bitfields.exp: Pass string other than test file
name to prepare_for_testing.
(watch): New procedure.
(expect_watchpoint): Use with_test_prefix.
(top level): Factor out tests to ...
(test_watch_location, test_regular_watch): ... these new
procedures, and use with_test_prefix and gdb_continue_to_end.
Fix PR12526: -location watchpoints for bitfield arguments PR 12526 reports that -location watchpoints against bitfield arguments trigger false positives when bits around the bitfield, but not the bitfield itself, are modified. This happens because -location watchpoints naturally operate at the byte level, not at the bit level. When the address of a bitfield lvalue is taken, information about the bitfield (i.e. its offset and size) is lost in the process. This information must first be retained throughout the lifetime of the -location watchpoint. This patch achieves this by adding two new fields to the watchpoint struct: val_bitpos and val_bitsize. These fields are set when a watchpoint is first defined in watch_command_1. They are both equal to zero if the watchpoint is not a -location watchpoint or if the argument is not a bitfield. Then these bitfield parameters are used inside update_watchpoint and watchpoint_check to extract the actual value of the bitfield from the watchpoint address, with the help of a local helper function extract_bitfield_from_watchpoint_value. Finally when creating a HW breakpoint pointing to a bitfield, we optimize the address and length of the breakpoint. By skipping over the bytes that don't cover the bitfield, this step reduces the frequency at which a read watchpoint for the bitfield is triggered. It also reduces the number of times a false-positive call to check_watchpoint is triggered for a write watchpoint. gdb/ PR breakpoints/12526 * breakpoint.h (struct watchpoint): New fields val_bitpos and val_bitsize. * breakpoint.c (watch_command_1): Use these fields to retain bitfield information. (extract_bitfield_from_watchpoint_value): New function. (watchpoint_check): Use it. (update_watchpoint): Use it. Optimize the address and length of a HW watchpoint pointing to a bitfield. * value.h (unpack_value_bitfield): New prototype. * value.c (unpack_value_bitfield): Make extern. gdb/testsuite/ PR breakpoints/12526 * gdb.base/watch-bitfields.exp: New file. * gdb.base/watch-bitfields.c: New file.
2014-09-16 18:40:06 +02:00
2014-09-16 Patrick Palka <patrick@parcs.ath.cx>
PR breakpoints/12526
* gdb.base/watch-bitfields.exp: New file.
* gdb.base/watch-bitfields.c: New file.
Fix watchpoint-stops-at-right-insn.exp Silly typo... gdb/testsuite/ 2014-09-16 Pedro Alves <palves@redhat.com> * gdb.base/watchpoint-stops-at-right-insn.exp (test): Compare software and hardware addresses, not software address against itself.
2014-09-16 15:27:57 +02:00
2014-09-16 Pedro Alves <palves@redhat.com>
* gdb.base/watchpoint-stops-at-right-insn.exp (test): Compare
software and hardware addresses, not software address against
itself.
Add test to make sure GDB knows which "kind" of watchpoint the target has This adds a test that makes sure GDB knows whether the target has continuable, or non-continuable watchpoints. That is, the test confirms that GDB presents a watchpoint value change at the first instruction right after the instruction that changes memory. gdb/testsuite/ChangeLog: 2014-09-16 Pedro Alves <palves@redhat.com> * gdb.base/watchpoint-stops-at-right-insn.c: New file. * gdb.base/watchpoint-stops-at-right-insn.exp: New file.
2014-09-16 15:05:06 +02:00
2014-09-16 Pedro Alves <palves@redhat.com>
* gdb.base/watchpoint-stops-at-right-insn.c: New file.
* gdb.base/watchpoint-stops-at-right-insn.exp: New file.
Remove support for testing against dead "target vxworks" "target vxworks" and friends have been removed 10 years ago already: commit e84ecc995d6a5e4e9114d3cea61717b8a573afb6 Author: Andrew Cagney <cagney@redhat.com> AuthorDate: Sat Nov 13 23:10:02 2004 +0000 2004-11-13 Andrew Cagney <cagney@gnu.org> * configure.tgt: Delete i[34567]86-*-vxworks*, m68*-netx-*, m68*-*-vxworks*, mips*-*-vxworks*, powerpc-*-vxworks*, and sparc-*-vxworks*. * NEWS: Mention that vxworks was deleted. (...) * remote-vxmips.c, remote-vx.c: Delete. * remote-vx68.c: Delete. (...) This removes related leftover cruft from the testsuite. Tested on x86_64 Fedora 20, native and gdbserver. gdb/testsuite/ 2014-09-16 Pedro Alves <palves@redhat.com> * config/vx.exp, config/vxworks.exp, config/vxworks29k.exp: Delete files. * gdb.base/a2-run.exp: Remove all code guarded by istarget "*-*-vxworks*" throughout. * gdb.base/break.exp: Likewise. * gdb.base/default.exp: Likewise. * gdb.base/scope.exp: Likewise. * gdb.base/sepdebug.exp: Likewise. * gdb.base/break.c: Remove all code guarded by #ifdef vxworks throughout. * gdb.base/run.c: Likewise. * gdb.base/sepdebug.c: Likewise. * gdb.hp/gdb.aCC/run.c: Likewise. * gdb.reverse/until-reverse.c: Likewise. * lib/gdb.exp (gdb_compile): Remove is_vxworks branch.
2014-09-16 13:37:03 +02:00
2014-09-16 Pedro Alves <palves@redhat.com>
* config/vx.exp, config/vxworks.exp, config/vxworks29k.exp: Delete
files.
* gdb.base/a2-run.exp: Remove all code guarded by istarget
"*-*-vxworks*" throughout.
* gdb.base/break.exp: Likewise.
* gdb.base/default.exp: Likewise.
* gdb.base/scope.exp: Likewise.
* gdb.base/sepdebug.exp: Likewise.
* gdb.base/break.c: Remove all code guarded by #ifdef vxworks
throughout.
* gdb.base/run.c: Likewise.
* gdb.base/sepdebug.c: Likewise.
* gdb.hp/gdb.aCC/run.c: Likewise.
* gdb.reverse/until-reverse.c: Likewise.
* lib/gdb.exp (gdb_compile): Remove is_vxworks branch.
Another board file for remote host In the recent review to my patch about copying files to remote host, we find that we need a board file which is more closely mapped real remote host testing to improve coverage. With the board file local-remote-host-native.exp, DejaGNU copies files to $build/gdb/testsuite/remote-host to emulate the effect of remote host. Is it OK? gdb/testsuite: 2014-09-16 Yao Qi <yao@codesourcery.com> * boards/local-remote-host-native.exp: New file.
2014-08-28 15:27:40 +02:00
2014-09-16 Yao Qi <yao@codesourcery.com>
* boards/local-remote-host-native.exp: New file.
Fix set up of queue-signal.exp test. The test does a backtrace to see which thread (#2 or #3) is assigned to which SIGUSR (1 or 2). If the main thread gets to all_threads_running before the sigusr threads get to their entry point, then the function name isn't in the backtrace and the test fails. Alas this version of the code is within epsilon of what I started with, and then over-simplified things.
2014-09-14 19:48:38 +02:00
2014-09-14 Doug Evans <xdje42@gmail.com>
* gdb.threads/queue-signal.c (thread_count): New variable.
(thread_count_mutex, thread_count_condvar): New variables.
(incr_thread_count, wait_all_threads_running): New functions.
(main): Wait for all threads to be in their thread functions.
New command queue-signal. If I want to change the signalled state of multiple threads it's a bit cumbersome to do with the "signal" command. What you really want is a way to set the signal state of the desired threads and then just do "continue". This patch adds a new command, queue-signal, to accomplish this. Basically "signal N" == "queue-signal N" + "continue". That's not precisely true in that "signal" can be used to inject any signal, including signals set to "nopass"; whereas "queue-signal" just queues the signal as if the thread stopped because of it. "nopass" handling is done when the thread is resumed which "queue-signal" doesn't do. One could add extra complexity to allow queue-signal to be used to deliver "nopass" signals like the "signal" command. I have no current need for it so in the interests of incremental complexity, I have left such support out and just have the code flag an error if one tries to queue a nopass signal. gdb/ChangeLog: * NEWS: Mention new "queue-signal" command. * infcmd.c (queue_signal_command): New function. (_initialize_infcmd): Add new queue-signal command. gdb/doc/ChangeLog: * gdb.texinfo (Signaling): Document new queue-signal command. gdb/testsuite/ChangeLog: * gdb.threads/queue-signal.c: New file. * gdb.threads/queue-signal.exp: New file.
2014-09-14 06:44:00 +02:00
2014-09-13 Doug Evans <xdje42@gmail.com>
* gdb.threads/queue-signal.c: New file.
* gdb.threads/queue-signal.exp: New file.
Pass plain-text prompt to with_gdb_prompt. I had occasion to use with_gdb_prompt in a test for the patch for PR 17314 and was passing the plain text prompt as the value, "(top-gdb)", instead of a regexp, "\(top-gdb\)" (expressed as "\\(top-gdb\\)" in TCL). I then discovered that in order to restore the prompt gdb passes the original value of $gdb_prompt to "set prompt", which works because "set prompt \(gdb\) " is equivalent to "set prompt (gdb) ". Perhaps I'm being overly cautious but this feels a bit subtle, but at any rate as an API choice I'd much rather pass the plain text form to with_gdb_prompt. I also discovered that the initial value of gdb_prompt is set in two places to two different values. At the global level gdb.exp sets it to "\[(\]gdb\[)\]" and default_gdb_init sets it to "\\(gdb\\)". The former form is undesirable as an argument to "set prompt", but it's not clear to me that just deleting this code won't break anything. Thus I just changed the value to be consistent and added a comment. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_prompt): Add comment and change initial value to be consistent with what default_gdb_init uses. (with_gdb_prompt): Change form of PROMPT argument from a regexp to the plain text of the prompt. Add some logging printfs. * gdb.perf/disassemble.exp: Update call to with_gdb_prompt.
2014-09-14 00:52:15 +02:00
2014-09-13 Doug Evans <xdje42@gmail.com>
* lib/gdb.exp (gdb_prompt): Add comment and change initial value to
be consistent with what default_gdb_init uses.
(with_gdb_prompt): Change form of PROMPT argument from a regexp to
the plain text of the prompt. Add some logging printfs.
* gdb.perf/disassemble.exp: Update call to with_gdb_prompt.
after gdb_run_cmd, gdb_expect -> gdb_test_multiple/gdb_test See: https://sourceware.org/ml/gdb-patches/2014-09/msg00404.html We have a number of places that do gdb_run_cmd followed by gdb_expect, when it would be better to use gdb_test_multiple or gdb_test. This converts all that "grep gdb_run_cmd -A 2 | grep gdb_expect" found. Tested on x86_64 Fedora 20, native and gdbserver. gdb/testsuite/ 2014-09-12 Pedro Alves <palves@redhat.com> * gdb.arch/gdb1558.exp: Replace uses of gdb_expect after gdb_run_cmd with gdb_test_multiple or gdb_test throughout. * gdb.arch/i386-size-overlap.exp: Likewise. * gdb.arch/i386-size.exp: Likewise. * gdb.arch/i386-unwind.exp: Likewise. * gdb.base/a2-run.exp: Likewise. * gdb.base/break.exp: Likewise. * gdb.base/charset.exp: Likewise. * gdb.base/chng-syms.exp: Likewise. * gdb.base/commands.exp: Likewise. * gdb.base/dbx.exp: Likewise. * gdb.base/find.exp: Likewise. * gdb.base/funcargs.exp: Likewise. * gdb.base/jit-simple.exp: Likewise. * gdb.base/reread.exp: Likewise. * gdb.base/sepdebug.exp: Likewise. * gdb.base/step-bt.exp: Likewise. * gdb.cp/mb-inline.exp: Likewise. * gdb.cp/mb-templates.exp: Likewise. * gdb.objc/basicclass.exp: Likewise. * gdb.threads/killed.exp: Likewise.
2014-09-12 23:16:31 +02:00
2014-09-12 Pedro Alves <palves@redhat.com>
* gdb.arch/gdb1558.exp: Replace uses of gdb_expect after
gdb_run_cmd with gdb_test_multiple or gdb_test throughout.
* gdb.arch/i386-size-overlap.exp: Likewise.
* gdb.arch/i386-size.exp: Likewise.
* gdb.arch/i386-unwind.exp: Likewise.
* gdb.base/a2-run.exp: Likewise.
* gdb.base/break.exp: Likewise.
* gdb.base/charset.exp: Likewise.
* gdb.base/chng-syms.exp: Likewise.
* gdb.base/commands.exp: Likewise.
* gdb.base/dbx.exp: Likewise.
* gdb.base/find.exp: Likewise.
* gdb.base/funcargs.exp: Likewise.
* gdb.base/jit-simple.exp: Likewise.
* gdb.base/reread.exp: Likewise.
* gdb.base/sepdebug.exp: Likewise.
* gdb.base/step-bt.exp: Likewise.
* gdb.cp/mb-inline.exp: Likewise.
* gdb.cp/mb-templates.exp: Likewise.
* gdb.objc/basicclass.exp: Likewise.
* gdb.threads/killed.exp: Likewise.
PR tdep/17379: Fix internal-error when stack pointer is invalid. The problem is that rs6000_frame_cache attempts to read the stack backchain via read_memory_unsigned_integer, which throws an exception if the stack pointer is invalid. With this patch, it calls safe_read_memory_integer instead, which doesn't throw an exception and allows for safe handling of that situation. gdb/ChangeLog 2014-09-12 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com> Ulrich Weigand  <uweigand@de.ibm.com> PR tdep/17379 * rs6000-tdep.c (rs6000_frame_cache): Use safe_read_memory_integer instead of read_memory_unsigned_integer. gdb/testcase/ChangeLog 2014-09-12 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com> PR tdep/17379 * gdb.arch/powerpc-stackless.S: New file. * gdb.arch/powerpc-stackless.exp: New file.
2014-09-12 14:20:25 +02:00
2014-09-12 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
PR tdep/17379
* gdb.arch/powerpc-stackless.S: New file.
* gdb.arch/powerpc-stackless.exp: New file.
testsuite: Fix runaway attach processes I have started seeing occasional runaway 'attach' processes these days. I cannot be certain it is really caused by this patch, for example grep 'FAIL.*cmdline attach run' does not show anything in my logs. But as I remember this 'attach' runaway process always happened in GDB (but I do not remember it in the past months) I think it would be most safe to just solve it forever by [attached]. gdb/testsuite/ChangeLog 2014-09-12 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.base/attach.c: Include unistd.h. (main): Call alarm. Add label postloop. * gdb.base/attach.exp (do_attach_tests): Use gdb_get_line_number, gdb_breakpoint, gdb_continue_to_breakpoint. (test_command_line_attach_run): Kill ${testpid} in one exit path.
2014-09-12 13:39:04 +02:00
2014-09-12 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/attach.c: Include unistd.h.
(main): Call alarm. Add label postloop.
* gdb.base/attach.exp (do_attach_tests): Use gdb_get_line_number,
gdb_breakpoint, gdb_continue_to_breakpoint.
(test_command_line_attach_run): Kill ${testpid} in one exit path.
gdb/17347 - Regression: GDB stopped on run with attached process Doing: gdb --pid=PID -ex run Results in GDB getting a SIGTTIN, and thus ending stopped. That's usually indicative of a missing target_terminal_ours call. E.g., from the PR: $ sleep 1h & p=$!; sleep 0.1; gdb -batch sleep $p -ex run [1] 28263 [1] Killed sleep 1h [2]+ Stopped gdb -batch sleep $p -ex run The workaround is doing: gdb -ex "attach $PID" -ex "run" instead of gdb [-p] $PID -ex "run" With the former, gdb waits for the attach command to complete before moving on to the "run" command, because the interpreter is in sync mode at this point, within execute_command. But for the latter, attach_command is called directly from captured_main, and thus misses that waiting. IOW, "run" is running before the attach continuation has run, before the program stops and attach completes. The broken terminal settings are just one symptom of that. Any command that queries or requires input results in the same. The fix is to wait in catch_command_errors (which is specific to main.c nowadays), just like we wait in execute_command. gdb/ChangeLog: 2014-09-11 Pedro Alves <palves@redhat.com> PR gdb/17347 * main.c: Include "infrun.h". (catch_command_errors, catch_command_errors_const): Wait for the foreground command to complete. * top.c (maybe_wait_sync_command_done): New function, factored out from ... (maybe_wait_sync_command_done): ... here. * top.h (maybe_wait_sync_command_done): New declaration. gdb/testsuite/ChangeLog: 2014-09-11 Pedro Alves <palves@redhat.com> PR gdb/17347 * lib/gdb.exp (gdb_spawn_with_cmdline_opts): New procedure. * gdb.base/attach.exp (test_command_line_attach_run): New procedure. (top level): Call it.
2014-09-11 14:04:15 +02:00
2014-09-11 Pedro Alves <palves@redhat.com>
PR gdb/17347
* lib/gdb.exp (gdb_spawn_with_cmdline_opts): New procedure.
* gdb.base/attach.exp (test_command_line_attach_run): New
procedure.
(top level): Call it.
testsuite: refactor spawn and wait for attach Several places in the testsuite have a copy of a snippet of code that spawns a test program, waits a bit, and then does some PID munging for Cygwin. This is in order to have GDB attach to the spawned program. This refactors all that to a common procedure. (multi-attach.exp wants to spawn multiple processes, so this makes the new procedure's interface work with lists.) Tested on x86_64 Fedora 20. gdb/testsuite/ChangeLog: 2014-09-11 Pedro Alves <palves@redhat.com> * lib/gdb.exp (spawn_wait_for_attach): New procedure. * gdb.base/attach.exp (do_attach_tests, do_call_attach_tests) (do_command_attach_tests): Use spawn_wait_for_attach. * gdb.base/solib-overlap.exp: Likewise. * gdb.multi/multi-attach.exp: Likewise. * gdb.python/py-prompt.exp: Likewise. * gdb.python/py-sync-interp.exp: Likewise. * gdb.server/ext-attach.exp: Likewise.
2014-09-11 14:04:14 +02:00
2014-09-11 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (spawn_wait_for_attach): New procedure.
* gdb.base/attach.exp (do_attach_tests, do_call_attach_tests)
(do_command_attach_tests): Use spawn_wait_for_attach.
* gdb.base/solib-overlap.exp: Likewise.
* gdb.multi/multi-attach.exp: Likewise.
* gdb.python/py-prompt.exp: Likewise.
* gdb.python/py-sync-interp.exp: Likewise.
* gdb.server/ext-attach.exp: Likewise.
Fix gdb.fortran/array-element.exp failures. This fixes two FAIL results on this testcase which were caused by a misplaced "continue" command. This testcase used to end inferior's execution too soon, causing the following tests to fail. Now we break right after inferior's loop and perform the rest of the tests there. gdb/testsuite/ChangeLog: * gdb.fortran/array-element.exp: Remove unexpected "continue" command in testcase. Simplify testcase.
2014-09-11 05:03:35 +02:00
2014-09-11 Gabriel Krisman Bertazi <gabriel@krisman.be>
* gdb.fortran/array-element.exp: Remove unexpected "continue"
command in testcase. Simplify testcase.
dynarr-ptr.exp: Add ptype tests. This patch adds a number of "ptype" tests to gdb.dwarf2/dynarr-ptr.exp. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add a few ptype tests.
2014-09-01 18:42:52 +02:00
2014-09-10 Joel Brobecker <brobecker@adacore.com>
* gdb.dwarf2/dynarr-ptr.exp: Add a few ptype tests.
Ada: Print bounds/length of pointer to array with dynamic bounds Trying to print the bounds or the length of a pointer to an array whose bounds are dynamic results in the following error: (gdb) p foo.three_ptr.all'first Location address is not set. (gdb) p foo.three_ptr.all'length Location address is not set. This is because, after having dereferenced our array pointer, we use the type of the resulting array value, instead of the enclosing type. The former is the original type where the bounds are unresolved, whereas we need to get the actual array bounds. Similarly, trying to apply those attributes to the array pointer directly (without explicitly dereferencing it with the '.all' operator) yields the same kind of error: (gdb) p foo.three_ptr'first Location address is not set. (gdb) p foo.three_ptr'length Location address is not set. This is caused by the fact that the dereference was done implicitly in this case, and perform at the type level only, which is not sufficient in order to resolve the array type. This patch fixes both issues, thus allowing us to get the expected output: (gdb) p foo.three_ptr.all'first $1 = 1 (gdb) p foo.three_ptr.all'length $2 = 3 (gdb) p foo.three_ptr'first $3 = 1 (gdb) p foo.three_ptr'length $4 = 3 gdb/ChangeLog: * ada-lang.c (ada_array_bound): If ARR is a TYPE_CODE_PTR, dereference it first. Use value_enclosing_type instead of value_type. (ada_array_length): Likewise. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add 'first, 'last and 'length tests.
2014-08-29 19:56:25 +02:00
2014-09-10 Joel Brobecker <brobecker@adacore.com>
* gdb.dwarf2/dynarr-ptr.exp: Add 'first, 'last and 'length tests.
Ada subscripting of pointer to array with dynamic bounds Consider a pointer to an array which dynamic bounds, described in DWARF as follow: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is now able to correctly print the entire array, but not one element of the array. Eg: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) (gdb) p foo.three_ptr.all(1) Cannot access memory at address 0xfffffffff4123a0c The problem occurs because we are missing a dynamic resolution of the variable's array type when subscripting the array. What the current code does is "fix"-ing the array type using the GNAT encodings, but that operation ignores any of the array's dynamic properties. This patch fixes the issue by using ada_value_ind to dereference the array pointer, which takes care of the array type resolution. It also continues to "fix" arrays described using GNAT encodings, so backwards compatibility is preserved. gdb/ChangeLog: * ada-lang.c (ada_value_ptr_subscript): Remove parameter "type". Adjust function implementation and documentation accordingly. (ada_evaluate_subexp) <OP_FUNCALL>: Only assign "type" if NOSIDE is EVAL_AVOID_SIDE_EFFECTS. Update call to ada_value_ptr_subscript. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.exp: Add subscripting tests.
2014-08-29 19:50:03 +02:00
2014-09-10 Joel Brobecker <brobecker@adacore.com>
* gdb.dwarf2/dynarr-ptr.exp: Add subscripting tests.
print PTR.all where PTR is an Ada thin pointer Consider the following declaration: type Array_Type is array (Natural range <>) of Integer; type Array_Ptr is access all Array_Type; for Array_Ptr'Size use 64; Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3); This creates a pointer to an array where the bounds are stored in a memory region just before the array itself (aka a "thin pointer"). In DWARF, this is described as a the usual pointer type to an array whose subrange has dynamic values for its bounds: <1><25>: Abbrev Number: 4 (DW_TAG_array_type) <26> DW_AT_name : foo__array_type [...] <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type) [...] <40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4 (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus; DW_OP_deref_size: 4) <46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4 (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus; DW_OP_deref_size: 4) GDB is currently printing the value of the array incorrectly: (gdb) p foo.three_ptr.all $1 = (26629472 => 1, 2, value.c:819: internal-error: value_contents_bits_eq: [...] The dereferencing (".all" operator) is done by calling ada_value_ind, which itself calls value_ind. It first produces a new value where the bounds of the array were correctly resolved to their actual value, but then calls readjust_indirect_value_type which replaces the resolved type by the original type. The problem starts when ada_value_print does not take this situation into account, and starts using the type of the resulting value, which has unresolved array bounds, instead of using the value's enclosing type. After fixing this issue, the debugger now correctly prints: (gdb) p foo.three_ptr.all $1 = (1, 2, 3) gdb/ChangeLog: * ada-valprint.c (ada_value_print): Use VAL's enclosing type instead of VAL's type. gdb/testsuite/ChangeLog: * gdb.dwarf2/dynarr-ptr.c: New file. * gdb.dwarf2/dynarr-ptr.exp: New file.
2014-08-29 17:50:13 +02:00
2014-09-10 Joel Brobecker <brobecker@adacore.com>
* gdb.dwarf2/dynarr-ptr.c: New file.
* gdb.dwarf2/dynarr-ptr.exp: New file.
GDB/testsuite: Correct gdb.base/watchpoint-solib.exp timeout tweak Similarly to the previous changes to gdb.reverse/sigall-reverse.exp and gdb.reverse/until-precsave.exp this corrects the timeout tweak in gdb.base/watchpoint-solib.exp. This test case executes a large amount of code with a software watchpoint enabled. This means single-stepping all the way through and takes a lot of time, e.g. for an ARMv7 Panda board and a `-march=armv5te' multilib: PASS: gdb.base/watchpoint-solib.exp: continue to foo again elapsed: 714 for the same board and a `-mthumb -march=armv5te' multilib: PASS: gdb.base/watchpoint-solib.exp: continue to foo again elapsed: 1275 and for QEMU in the system emulation mode and a `-march=armv4t' multilib: PASS: gdb.base/watchpoint-solib.exp: continue to foo again elapsed: 115 (values in seconds) -- all of which having the default timeout of 60s, set based on the requirement of the remaining test cases (other than gdb.reverse ones). Here again the timeout extension to have a meaning should be calculated by scaling rather than using an arbitrary constant, and a larger factor of 30 will do, leaving some margin. Hopefully for everyone or otherwise we'll probably have to come up with a smarter solution. OTOH the other test cases in this script do not require the extension so they can be moved outside its umbrella so as to avoid unnecessary delays if something goes wrong and a genuine timeout triggers. * gdb.base/watchpoint-solib.exp: Increase the timeout by a factor of 30 rather than hardcoding 120 for a slow test case. Take the `gdb,timeout' target setting into account for this calculation. Don't extend the timeout for the test cases that don't need it.
2014-09-09 18:39:17 +02:00
2014-09-09 Maciej W. Rozycki <macro@codesourcery.com>
* gdb.base/watchpoint-solib.exp: Increase the timeout by a factor
of 30 rather than hardcoding 120 for a slow test case. Take the
`gdb,timeout' target setting into account for this calculation.
Don't extend the timeout for the test cases that don't need it.
GDB/testsuite: Add/correct gdb.reverse timeout tweaks There are three cases in two scripts in the gdb.reverse subset that take a particularly long time. Two of them are already attempted to take care of by extending the timeout from the default. The remaining one has no precautions taken. The timeout extension is ineffective though, it is done by adding a constant rather than by scaling and as a result while it may work for target boards that get satisfied with the detault test timeout of 10s, it does not serve its purpose for slower ones. Here are indicative samples of execution times (in seconds) observed for these cases respectively, for an ARMv7 Panda board running Linux and a `-march=armv5te' multilib: PASS: gdb.reverse/sigall-reverse.exp: continue to signal exit elapsed: 385 PASS: gdb.reverse/until-precsave.exp: run to end of main elapsed: 4440 PASS: gdb.reverse/until-precsave.exp: save process recfile elapsed: 965 for the same board and a `-mthumb -march=armv5te' multilib: PASS: gdb.reverse/sigall-reverse.exp: continue to signal exit elapsed: 465 PASS: gdb.reverse/until-precsave.exp: run to end of main elapsed: 4191 PASS: gdb.reverse/until-precsave.exp: save process recfile elapsed: 669 and for QEMU in the system emulation mode and a `-march=armv4t' multilib: PASS: gdb.reverse/sigall-reverse.exp: continue to signal exit elapsed: 45 PASS: gdb.reverse/until-precsave.exp: run to end of main elapsed: 433 PASS: gdb.reverse/until-precsave.exp: save process recfile elapsed: 104 Based on the performance of other tests these two test configurations have their default timeout set to 450s and 60s respectively. The remaining two multilibs (`-mthumb -march=armv4t' and `-mthumb -march=armv7-a') do not produce test results usable enough to have data available for these cases. Based on these results I have tweaked timeouts for these cases as follows. This, together with a suitable board timeout setting, removes timeouts for these cases. Note that for the default timeout of 10s the new setting for the first case in gdb.reverse/until-precsave.exp is compatible with the old one, just a bit higher to keep the convention of longer timeouts to remain multiples of 30s. The second case there does not need such a high setting so I have lowered it a bit to avoid an unnecessary delay where this test case genuinely times out. * gdb.reverse/sigall-reverse.exp: Increase the timeout by a factor of 2 for a slow test case. Take the `gdb,timeout' target setting into account for this calculation. * gdb.reverse/until-precsave.exp: Increase the timeout by a factor of 15 and 3 respectively rather than adding 120 for a pair of slow test cases. Take the `gdb,timeout' target setting into account for this calculation.
2014-09-09 18:03:24 +02:00
2014-09-09 Maciej W. Rozycki <macro@codesourcery.com>
* gdb.reverse/sigall-reverse.exp: Increase the timeout by
a factor of 2 for a slow test case. Take the `gdb,timeout'
target setting into account for this calculation.
* gdb.reverse/until-precsave.exp: Increase the timeout by
a factor of 15 and 3 respectively rather than adding 120
for a pair of slow test cases. Take the `gdb,timeout'
target setting into account for this calculation.
GDB/testsuite: Avoid timeout lowering The recent change to introduce `gdb_reverse_timeout' turned out ineffective for board setups that set the `gdb,timeout' target variable. A lower `gdb,timeout' setting takes precedence and defeats the effect of `gdb_reverse_timeout'. This is because the global timeout is overridden in gdb_test_multiple and then again in gdb_expect. Three timeout variables are taken into account in these two places, in this precedence: 1. The `gdb,timeout' target variable. 2. The caller's local `timeout' variable (upvar timeout) 3. The global `timeout' variable. This precedence is obeyed by gdb_test_multiple strictly. OTOH gdb_expect will select the higher of the two formers and will only take the latter into account if none of the formers is present. However the two timeout selections are conceptually the same and gdb_test_multiple does its only for the purpose of passing it down to gdb_expect. Therefore I decided there is no point to keep carrying on this duplication and removed the sequence from gdb_test_multiple, however retaining the `upvar timeout' variable definition. This way gdb_expect will still access gdb_test_multiple's caller `timeout' variable (if any) via its own `upvar timeout' reference. Now as to the sequence in gdb_expect. In addition to the three variables described above it also takes a timeout argument into account, as the fourth value to choose from. It is currently used if it is higher than the timeout selected from the variables as described above. With the timeout selection code from gdb_test_multiple gone, gone is also the most prominent use of this timeout argument, it's now used in a couple of places only, mostly within this test framework library code itself for preparatory commands or suchlike. With this being the case this timeout selection code can be simplified as follows: 1. Among the three timeout variables, the highest is always chosen. This is so that a test case doesn't inadvertently lower a high value timeout needed by slow target boards. This is what all test cases use. 2. Any timeout argument takes precedence. This is for special cases such as within the framework library code, e.g. it doesn't make sense to send `set height 0' with a timeout of 7200 seconds. This is a local command that does not interact with the target and setting a high timeout here only risks a test suite run taking ages if it goes astray for some reason. 3. The fallback timeout of 60s remains. * lib/gdb.exp (gdb_test_multiple): Remove code to select the timeout, don't pass one down to gdb_expect. (gdb_expect): Rework timeout selection.
2014-09-09 17:39:16 +02:00
2014-09-09 Maciej W. Rozycki <macro@codesourcery.com>
* lib/gdb.exp (gdb_test_multiple): Remove code to select the
timeout, don't pass one down to gdb_expect.
(gdb_expect): Rework timeout selection.
gdbserver-support: Handle gdbserver start failures As it happens we have a board that fails a gdb.base/gcore-relro.exp test case reproducibly and moreover the case appears to trigger a kernel bug making the it less than usable. Specifically the board remains responsive to some extent, however processes do not appear to be able to successfully complete termination anymore and perhaps more importantly further gdbserver processes can be started, but they never reach the stage of listening on the RSP socket. This change handles timeouts in gdbserver start properly, by throwing a TCL error exception when gdbserver does not report listening on the RSP socket in time. This is then caught at the outer level and reported, and 2 rather than 1 is returned so that the caller may tell the failure to start gdbserver and other issues apart and act accordingly (or do nothing). I thought letting the exception unwind further on might be a good idea for any test harnesses out there to break outright where a gdbserver start error is silently ignored right now, however I figured out the calls to gdbserver-support.exp are buried down too deep in the GDB test suite for such a change to be made easily. I think returning a distinct return value is good enough (the API says "non-zero", so 2 is as good as 1) and we can always make the error harder in a later step if required. With config/gdbserver.exp being used this change remains transparent to the target board, the return value is passed up by gdb_reload and the error exception unwinds through gdbserver_gdb_load and is caught and handled by mi_gdb_target_load. A call to perror is still made, reporting the timeout, and in the case of mi_gdb_target_load the procedure returns a value denoting unsuccessful completion. An unsuccessful completion of gdb_reload is already handled elsewhere. An alternative gdbserver board configuration can interpret the return value in its gdb_reload implementation and catch the error in gdbserver_gdb_load in an attempt to recover a target board that has gone astray, for example by rebooting the board somehow. This has proved effective with our failing board, that now completes the remaining test cases with no further hiccups. * lib/gdbserver-support.exp (gdbserver_start): Throw an error exception on timeout. (gdbserver_run): Catch any `gdbserver_spawn' error exceptions. (gdbserver_start_extended): Catch any `gdbserver_start' error exceptions. (gdbserver_start_multi, mi_gdbserver_start_multi): Likewise. * lib/mi-support.exp (mi_gdb_target_load): Catch any `gdbserver_gdb_load' error exceptions.
2014-09-09 17:17:38 +02:00
2014-09-09 Maciej W. Rozycki <macro@codesourcery.com>
* lib/gdbserver-support.exp (gdbserver_start): Throw an error
exception on timeout.
(gdbserver_run): Catch any `gdbserver_spawn' error exceptions.
(gdbserver_start_extended): Catch any `gdbserver_start' error
exceptions.
(gdbserver_start_multi, mi_gdbserver_start_multi): Likewise.
* lib/mi-support.exp (mi_gdb_target_load): Catch any
`gdbserver_gdb_load' error exceptions.
GDB/testsuite: Extend the time gdbserver is waited for Gdbserver support code uses the global timeout value to determine when to stop waiting for a gdbserver process being started to respond before continuing anyway. This timeout is usually as low as 10s and may not be enough in this context, for example on the first run where the filesystem cache is cold, even if it is elsewhere. E.g. I observe this reliably with gdbserver started the first time in QEMU running in the system emulation mode: (gdb) file .../gdb.base/advance Reading symbols from .../gdb.base/advance...done. (gdb) delete breakpoints (gdb) info breakpoints No breakpoints or watchpoints. (gdb) break main Breakpoint 1 at 0x87f8: file .../gdb.base/advance.c, line 41. (gdb) set remotetimeout 15 (gdb) kill The program is not being run. (gdb) [...] .../bin/gdbserver --once :6014 advance target remote localhost:6014 Remote debugging using localhost:6014 Remote communication error. Target disconnected.: Connection reset by peer. (gdb) continue The program is not being run. (gdb) Process advance created; pid = 999 Listening on port 6014 FAIL: gdb.base/advance.exp: Can't run to main -- notice how the test harness proceeded with the `target remote ...' command even though gdbserver hasn't completed its startup yet. A while later when it's finally ready it's too late already. I checked the timing here and it takes gdbserver roughly 25 seconds to start in this scenario. Subsequent gdbserver starts in the same test run take less time and usually complete within 10 seconds although occasionally `target remote ...' precedes the corresponding `Listening on port...' message again. Therefore I have fixed this problem by setting an explicit timeout to 120s on the expect call in question. If this turns out too arbitrary sometime, then perhaps a separate `gdbserver_timeout' setting might be due. * lib/gdbserver-support.exp (gdbserver_start): Set timeout to 120 on waiting for the TCP socket to open.
2014-09-09 17:06:15 +02:00
2014-09-09 Maciej W. Rozycki <macro@codesourcery.com>
* lib/gdbserver-support.exp (gdbserver_start): Set timeout to
120 on waiting for the TCP socket to open.
Fix regression in default.exp caused by _caller_is, etc. gdb/testsuite/ChangeLog: * gdb.base/default.exp (show_conv_list): Add _caller_is, _caller_matches, _any_caller_is, _any_caller_matches.
2014-09-09 08:01:01 +02:00
2014-09-09 Doug Evans <xdje42@gmail.com>
* gdb.base/default.exp (show_conv_list): Add _caller_is,
_caller_matches, _any_caller_is, _any_caller_matches.
gdb.guile/scm-error.exp: Handle guile 2.2 backtrace output. gdb/testsuite/ChangeLog: * gdb.guile/scm-error.exp: Handle guile 2.2 backtrace output.
2014-09-09 07:19:32 +02:00
2014-09-09 Doug Evans <xdje42@gmail.com>
* gdb.guile/scm-error.exp: Handle guile 2.2 backtrace output.
Set print symbol off in mi-var-display.exp Hi, I see the following fail on arm-none-eabi target, -var-evaluate-expression -f nat foo^M ^done,value="0x3 <_ftext+2>"^M (gdb) ^M FAIL: gdb.mi/mi-var-display.exp: eval variable -f nat foo the "<_ftext+2>" isn't expected in the test, so "set print symbol off" can prevent printing it. It is obvious and I'll commit it in three days if no comments. gdb/testsuite: 2014-09-09 Yao Qi <yao@codesourcery.com> * gdb.mi/mi-var-display.exp: Set print symbol off.
2014-08-30 11:46:21 +02:00
2014-09-09 Yao Qi <yao@codesourcery.com>
* gdb.mi/mi-var-display.exp: Set print symbol off.
Fix PR gdb/17035: "show user" doesn't list user-defined commands that have empty bodies. User-defined commands that have empty bodies weren't being shown because the print function returned too soon. Now, it prints the command's name before checking if it has any body at all. This also fixes the same problem on "show user <myemptycommand>", which wasn't being printed due to a similar reason. gdb/Changelog: * cli/cli-cmds.c (show_user): Use cli_user_command_p to decide whether we display the command on "show user". * cli/cli-script.c (show_user_1): Only verify cmdlines after printing command name. * cli/cli-decode.h (cli_user_command_p): Declare new function. * cli/cli-decode.c (cli_user_command_p): Create helper function to verify whether cmd_list_element is a user-defined command. gdb/testsuite/Changelog: * gdb.base/commands.exp: Add tests to verify user-defined commands with empty bodies. * gdb.python/py-cmd.exp: Test that we don't show user-defined python commands in `show user command`. * gdb.python/scm-cmd.exp: Test that we don't show user-defined scheme commands in `show user command`.
2014-09-08 01:12:19 +02:00
2014-09-07 Gabriel Krisman Bertazi <gabriel@krisman.be>
PR gdb/17035
* gdb.base/commands.exp: Add tests to verify user-defined
commands with empty bodies.
* gdb.python/py-cmd.exp: Test that we don't show user-defined
python commands in `show user command`.
* gdb.python/scm-cmd.exp: Test that we don't show user-defined
scheme commands in `show user command`.
Fix crash on Python frame filters with unreadable arg https://bugzilla.redhat.com/show_bug.cgi?id=1126177 ERROR: AddressSanitizer: SEGV on unknown address 0x000000000050 (pc 0x000000992bef sp 0x7ffff9039530 bp 0x7ffff9039540 T0) #0 0x992bee in value_type .../gdb/value.c:925 #1 0x87c951 in py_print_single_arg python/py-framefilter.c:445 #2 0x87cfae in enumerate_args python/py-framefilter.c:596 #3 0x87e0b0 in py_print_args python/py-framefilter.c:968 It crashes because frame_arg::val is documented it may contain NULL (frame_arg::error is then non-NULL) but the code does not handle it. Another bug is that py_print_single_arg() calls goto out of its TRY_CATCH which messes up GDB cleanup chain crashing GDB later. It is probably 7.7 regression (I have not verified it) due to the introduction of Python frame filters. gdb/ChangeLog PR python/17355 * python/py-framefilter.c (py_print_single_arg): Handle NULL FA->VAL. Fix goto out of TRY_CATCH. gdb/testsuite/ChangeLog PR python/17355 * gdb.python/amd64-py-framefilter-invalidarg.S: New file. * gdb.python/py-framefilter-invalidarg-gdb.py.in: New file. * gdb.python/py-framefilter-invalidarg.exp: New file. * gdb.python/py-framefilter-invalidarg.py: New file.
2014-09-07 14:09:59 +02:00
2014-09-07 Jan Kratochvil <jan.kratochvil@redhat.com>
PR python/17355
* gdb.python/amd64-py-framefilter-invalidarg.S: New file.
* gdb.python/py-framefilter-invalidarg-gdb.py.in: New file.
* gdb.python/py-framefilter-invalidarg.exp: New file.
* gdb.python/py-framefilter-invalidarg.py: New file.
PR 15276: Add $_caller_is, $_caller_matches, $_any_caller_is, $_any_caller_matches gdb/ChangeLog: PR 15276 * NEWS: Mention $_caller_is, $_caller_matches, $_any_caller_is, $_any_caller_matches. * data-directory/Makefile.in (PYTHON_FILE_LIST): Add caller_is.py. * python/lib/gdb/function/caller_is.py: New file. gdb/testsuite/ChangeLog: PR 15276 * gdb.python/py-caller-is.c: New file. * gdb.python/py-caller-is.exp: New file. gdb/doc/ChangeLog: PR 15276 * gdb.texinfo (Convenience Funs): Document $_caller_is, $_caller_matches, $_any_caller_is, $_any_caller_matches.
2014-09-06 18:15:44 +02:00
2014-09-06 Doug Evans <xdje42@gmail.com>
PR 15276
* gdb.python/py-caller-is.c: New file.
* gdb.python/py-caller-is.exp: New file.
Fix for PR gdb/17235: possible bug extracting systemtap probe operand This patch is a fix to PR gdb/17235. The bug is about an unused variable that got declared and set during one of the parsing phases of an SDT probe's argument. I took the opportunity to rewrite some of the code to improve the parsing. The bug was actually a thinko, because what I wanted to do in the code was to discard the number on the string being parsed. During this portion, the code identifies that it is dealing with an expression that begins with a sign ('+', '-' or '~'). This means that the expression could be: - a numeric literal (e.g., '+5') - a register displacement (e.g., '-4(%rsp)') - a subexpression (e.g., '-(2*3)') So, after saving the sign and moving forward 1 char, now the code needs to know if there is a digit followed by a register displacement prefix operand (e.g., '(' on x86_64). If yes, then it is a register operation. If not, then it will be handled recursively, and the code will later apply the requested operation on the result (either a '+', a '-' or a '~'). With the bug, the code was correctly discarding the digit (though using strtol unnecessarily), but it wasn't properly dealing with subexpressions when the register indirection prefix was '(', like on x86_64. This patch also fixes this bug, and includes a testcase. It passes on x86_64 Fedora 20.
2014-09-05 21:21:44 +02:00
2014-09-05 Sergio Durigan Junior <sergiodj@redhat.com>
PR gdb/17235
* gdb.arch/amd64-stap-wrong-subexp.exp: New file.
* gdb.arch/amd64-stap-wrong-subexp.S: Likewise.
Fix PR fortran/17237: bug in f-valprint.c This commit fixes the PR mentioned in $subject. It is about a set but unused variable that refers to the output format of integer values printed in Fortran. This was probably a thinko (like most set-but-unused-vars), but it could cause an internal error depending on the scenario. I am sending a testcase which triggers this error as well. gdb/ChangeLog: 2014-09-04 Sergio Durigan Junior <sergiodj@redhat.com> PR fortran/17237 * f-valprint.c (f_val_print): Specify the correct print option to use when printing integer values. gdb/testsuite/ChangeLog: 2014-09-04 Sergio Durigan Junior <sergiodj@redhat.com> PR fortran/17237 * gdb.fortran/print-formatted.exp: New file. * gdb.fortran/print-formatted.f90: Likewise.
2014-09-04 16:28:31 +02:00
2014-09-04 Sergio Durigan Junior <sergiodj@redhat.com>
PR fortran/17237
* gdb.fortran/print-formatted.exp: New file.
* gdb.fortran/print-formatted.f90: Likewise.
Add support for reading frame registers to Python API. The ability to read registers is needed to use Frame Filter API to display the frames created by JIT compilers. gdb/ChangeLog: 2014-08-29 Sasha Smundak <asmundak@google.com> * python/py-frame.c (frapy_read_register): New function. gdb/doc/ChangeLog: 2014-08-26 Sasha Smundak <asmundak@google.com> * python.texi (Frames in Python): Add read_register description. gdb/testsuite/ChangeLog: 2014-08-26 Sasha Smundak <asmundak@google.com> * gdb.python/py-frame.exp: Test Frame.read_register.
2014-09-04 01:34:47 +02:00
2014-09-03 Sasha Smundak <asmundak@google.com>
* gdb.python/py-frame.exp: Test Frame.read_register.
PR python/16699: GDB Python command completion with overriden complete vs. completer class This PR came from a Red Hat bug that was filed recently. I checked and it still exists on HEAD, so here's a proposed fix. Although this is marked as a Python backend bug, this is really about the completion mechanism used by GDB. Since this code reminds me of my first attempt to make a good noodle, it took me quite some time to fix it in a non-intrusive way. The problem is triggered when one registers a completion method inside a class in a Python script, rather than registering the command using a completer class directly. For example, consider the following script: class MyFirstCommand(gdb.Command): def __init__(self): gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME) def invoke(self,argument,from_tty): raise gdb.GdbError('not implemented') class MySecondCommand(gdb.Command): def __init__(self): gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER) def invoke(self,argument,from_tty): raise gdb.GdbError('not implemented') def complete(self,text,word): return gdb.COMPLETE_FILENAME MyFirstCommand () MySecondCommand () When one loads this into GDB and tries to complete filenames for both myfirstcommand and mysecondcommand, she gets: (gdb) myfirstcommand /hom<TAB> (gdb) myfirstcommand /home/ ^ ... (gdb) mysecondcommand /hom<TAB> (gdb) mysecondcommand /home ^ (The "^" marks the final position of the cursor after the TAB). So we see that myfirstcommand honors the COMPLETE_FILENAME class (as specified in the command creation), but mysecondcommand does not. After some investigation, I found that the problem lies with the set of word break characters that is used for each case. The set should be the same for both commands, but it is not. During the process of deciding which type of completion should be used, the code in gdb/completer.c:complete_line_internal analyses the command that requested the completion and tries to determine the type of completion wanted by checking which completion function will be called (e.g., filename_completer for filenames, location_completer for locations, etc.). This all works fine for myfirstcommand, because immediately after the command registration the Python backend already sets its completion function to filename_completer (which then causes the complete_line_internal function to choose the right set of word break chars). However, for mysecondcommand, this decision is postponed to when the completer function is evaluated, and the Python backend uses an internal completer (called cmdpy_completer). complete_line_internal doesn't know about this internal completer, and can't choose the right set of word break chars in time, which then leads to a bad decision when completing the "/hom" word. So, after a few attempts, I decided to create another callback in "struct cmd_list_element" that will be responsible for handling the case when there is an unknown completer function for complete_line_internal to work with. So far, only the Python backend uses this callback, and only when the user provides a completer method instead of registering the command directly with a completer class. I think this is the best option because it not very intrusive (all the other commands will still work normally), but especially because the whole completion code is so messy that it would be hard to fix this without having to redesign things. I have regtested this on Fedora 18 x86_64, without regressions. I also included a testcase. gdb/ChangeLog: 2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com> PR python/16699 * cli/cli-decode.c (set_cmd_completer_handle_brkchars): New function. (add_cmd): Set "completer_handle_brkchars" to NULL. * cli/cli-decode.h (struct cmd_list_element) <completer_handle_brkchars>: New field. * command.h (completer_ftype_void): New typedef. (set_cmd_completer_handle_brkchars): New prototype. * completer.c (set_gdb_completion_word_break_characters): New function. (complete_line_internal): Call "completer_handle_brkchars" callback from command. * completer.h: Include "command.h". (set_gdb_completion_word_break_characters): New prototype. * python/py-cmd.c (cmdpy_completer_helper): New function. (cmdpy_completer_handle_brkchars): New function. (cmdpy_completer): Adjust to use cmdpy_completer_helper. (cmdpy_init): Set completer_handle_brkchars to cmdpy_completer_handle_brkchars. gdb/testsuite/ChangeLog: 2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com> PR python/16699 * gdb.python/py-completion.exp: New file. * gdb.python/py-completion.py: Likewise.
2014-09-03 22:30:28 +02:00
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
Rewrite {amd64,i386}-pseudo.c to better specify register liveness. clang was using eax to construct %0 here: asm ("mov %%eax, 0(%0)\n\t" "mov %%ebx, 4(%0)\n\t" "mov %%ecx, 8(%0)\n\t" "mov %%edx, 12(%0)\n\t" "mov %%esi, 16(%0)\n\t" "mov %%edi, 20(%0)\n\t" : /* no output operands */ : "r" (data) : "eax", "ebx", "ecx", "edx", "esi", "edi"); which caused amd64-word.exp (and others similarly) to fail. It's a perfectly legit thing for clang to do given the available data. The patch fixes this by marking the registers as live from the time of the preceding breakpoint. gdb/testsuite/ChangeLog: * gdb.arch/amd64-pseudo.c (main): Rewrite to better specify when eax,etc. are live with values set by gdb and thus the compiler can't use them. * gdb.arch/i386-pseudo.c (main): Ditto.
2014-08-28 20:38:22 +02:00
2014-08-28 Doug Evans <dje@google.com>
* gdb.arch/amd64-pseudo.c (main): Rewrite to better specify when
eax,etc. are live with values set by gdb and thus the compiler can't
use them.
* gdb.arch/i386-pseudo.c (main): Ditto.
lib/gdb.exp (gdb_compile_shlib): Add support for clang. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_compile_shlib): Add support for clang.
2014-08-27 18:40:21 +02:00
2014-08-27 Doug Evans <dje@google.com>
* lib/gdb.exp (gdb_compile_shlib): Add support for clang.
Fix clang compilation errors in gdb.mi/basics.c. gdb/testsuite/ChangeLog: * gdb.mi/basics.c (callee3, callee2, callee1): Specify result type. (main): Ditto.
2014-08-25 21:40:54 +02:00
2014-08-25 Doug Evans <dje@google.com>
* gdb.mi/basics.c (callee3, callee2, callee1): Specify result type.
(main): Ditto.
gdb.threads/thread-execl.exp: #include <stdio.h>. gdb/testsuite/ChangeLog: * gdb.threads/thread-execl.exp: #include <stdio.h>.
2014-08-25 21:23:50 +02:00
2014-08-25 Doug Evans <dje@google.com>
* gdb.threads/thread-execl.exp: #include <stdio.h>.
set print symbol off in py-value.exp and scm-value.exp I see the following fails on arm-none-eabi target, print sn^M $14 = 0x0 <_ftext>^M (gdb) FAIL: gdb.python/py-value.exp: print sn print sn^M $14 = 0x0 <_ftext>^M (gdb) FAIL: gdb.guile/scm-value.exp: print sn as <_ftext> is unexpected. This patch is to set print symbol off to avoid printing this. gdb/testsuite: 2014-08-24 Yao Qi <yao@codesourcery.com> * gdb.guile/scm-value.exp (test_lazy_strings): Set print symbol off. * gdb.python/py-value.exp (test_lazy_strings): Likewise.
2014-08-07 10:10:51 +02:00
2014-08-24 Yao Qi <yao@codesourcery.com>
* gdb.guile/scm-value.exp (test_lazy_strings): Set print
symbol off.
* gdb.python/py-value.exp (test_lazy_strings): Likewise.
Fix pr 17276. See the description here: https://sourceware.org/ml/gdb-patches/2014-08/msg00283.html This patch keeps track of whether the current line has seen a non-zero discriminator, and if so coalesces consecutive entries for the same line (by ignoring all entries after the first). gdb/ChangeLog: PR 17276 * dwarf2read.c (dwarf_record_line_p): New function. (dwarf_decode_lines_1): Ignore subsequent line number entries for the same line if any entry had a non-zero discriminator. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-single-line-discriminators.S: New file. * gdb.dwarf2/dw2-single-line-discriminators.c: New file. * gdb.dwarf2/dw2-single-line-discriminators.exp: New file.
2014-08-23 02:25:59 +02:00
2014-08-22 Doug Evans <dje@google.com>
PR 17276
* gdb.dwarf2/dw2-single-line-discriminators.S: New file.
* gdb.dwarf2/dw2-single-line-discriminators.c: New file.
* gdb.dwarf2/dw2-single-line-discriminators.exp: New file.
Copy .py files to remote host Some gdb.python/*.exp tests fail because the .py files aren't copied to the (remote) host. This patch is to copy needed .py files to host. Most of gdb.python/*.exp tests do this. As it is still controversial to delete *.py files on host, we don't do that in this patch. gdb/testsuite: 2014-08-22 Yao Qi <yao@codesourcery.com> * gdb.python/py-finish-breakpoint.exp: Copy .py file to host. * gdb.python/py-finish-breakpoint2.exp: Likewise. * gdb.python/python.exp: Likewise. Use .py file on the host instead of the build.
2014-08-14 08:16:56 +02:00
2014-08-22 Yao Qi <yao@codesourcery.com>
* gdb.python/py-finish-breakpoint.exp: Copy .py file to host.
* gdb.python/py-finish-breakpoint2.exp: Likewise.
* gdb.python/python.exp: Likewise. Use .py file on the host
instead of the build.
Fix 'gcore' with exited threads Program received signal SIGABRT, Aborted. [...] (gdb) gcore foobar Couldn't get registers: No such process. (gdb) info threads [...] (gdb) gcore foobar Saved corefile foobar (gdb) gcore tries to access the exited thread: [Thread 0x7ffff7fce700 (LWP 6895) exited] ptrace(PTRACE_GETREGS, 6895, 0, 0x7fff18167dd0) = -1 ESRCH (No such process) Without the TRY_CATCH protection testsuite FAILs for: gcore .../gdb/testsuite/gdb.threads/gcore-thread0.test Cannot find new threads: debugger service failed (gdb) FAIL: gdb.threads/gcore-thread.exp: save a zeroed-threads corefile + core .../gdb/testsuite/gdb.threads/gcore-thread0.test ".../gdb/testsuite/gdb.threads/gcore-thread0.test" is not a core dump: File format not recognized (gdb) FAIL: gdb.threads/gcore-thread.exp: core0file: re-load generated corefile (bad file format) Maybe the TRY_CATCH could be more inside update_thread_list(). Similar update_thread_list() call is IMO missing in procfs_make_note_section() but I do not have where to verify that change. gdb/ChangeLog 2014-08-21 Jan Kratochvil <jan.kratochvil@redhat.com> * linux-tdep.c (linux_corefile_thread_callback): Ignore THREAD_EXITED. (linux_make_corefile_notes): call update_thread_list, protected against exceptions. gdb/testsuite/ChangeLog 2014-08-21 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.threads/gcore-stale-thread.c: New file. * gdb.threads/gcore-stale-thread.exp: New file.
2014-08-21 20:36:20 +02:00
2014-08-21 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.threads/gcore-stale-thread.c: New file.
* gdb.threads/gcore-stale-thread.exp: New file.
Remove useless gcore command detection Checking whether the gcore command is included in the GDB build as proxy for checking whether core dumping is supported by the target is useless, as gcore.o has been in COMMON_OBS since git 9b4eba8e: 2009-10-26 Michael Snyder <msnyder@vmware.com> Hui Zhu <teawater@gmail.com> * Makefile.in (SFILES): Add gcore.c. (COMMON_OBS): Add gcore.o. * config/alpha/alpha-linux.mh (NATDEPFILES): Delete gcore.o. * config/alpha/fbsd.mh (NATDEPFILES): Ditto. ... IOW, the command is always included in the build. Instead, nowadays, tests bail out if actually trying to generate a core fails with an indication the target doesn't support it. See gdb_gcore_cmd and callers. Tested on x86_64 Fedora 20. gdb/testsuite/ChangeLog: * gdb.base/gcore-buffer-overflow.exp: Remove "help gcore" test. * gdb.base/gcore-relro-pie.exp: Likewise. * gdb.base/gcore-relro.exp: Likewise. * gdb.base/gcore.exp: Likewise. * gdb.base/print-symbol-loading.exp: Likewise. * gdb.threads/gcore-thread.exp: Likewise. * lib/gdb.exp (gdb_gcore_cmd): Don't expect "Undefined command".
2014-08-21 12:36:59 +02:00
2014-08-21 Pedro Alves <palves@redhat.com>
* gdb.base/gcore-buffer-overflow.exp: Remove "help gcore" test.
* gdb.base/gcore-relro-pie.exp: Likewise.
* gdb.base/gcore-relro.exp: Likewise.
* gdb.base/gcore.exp: Likewise.
* gdb.base/print-symbol-loading.exp: Likewise.
* gdb.threads/gcore-thread.exp: Likewise.
* lib/gdb.exp (gdb_gcore_cmd): Don't expect "Undefined command".
Integrate PR 12649's race detector directly in the testsuite machinery This integrates Jan Kratochvil's nice race reproducer from PR testsuite/12649 into the testsuite infrustructure directly. With this, one only has to do either 'make check-read1' or 'make check READ1="1"' to preload the read1.so library into expect. Currently only enabled for glibc/GNU systems, and if build==host==target. gdb/testsuite/ChangeLog: * Makefile.in (EXTRA_RULES, CC): New variables, get from configure. (EXPECT): Handle READ1 being set. (all): Depend on EXTRA_RULES. (check-read1, expect-read1, read1.so, read1): New rules. * README (Testsuite Parameters): Document the READ1 make variable. (Race detection): New section. * configure: Regenerate. * configure.ac: If build==host==target, and running under a GNU/glibc system, add read1 to the extra Makefile rules. (EXTRA_RULES): AC_SUBST it. * lib/read1.c: New file. gdb/ChangeLog: * Makefile.in (check-read1): New rule.
2014-08-20 19:55:54 +02:00
2014-08-20 Pedro Alves <palves@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
* Makefile.in (EXTRA_RULES, CC): New variables, get from
configure.
(EXPECT): Handle READ1 being set.
(all): Depend on EXTRA_RULES.
(check-read1, expect-read1, read1.so, read1): New rules.
* README (Testsuite Parameters): Document the READ1 make variable.
(Race detection): New section.
* configure: Regenerate.
* configure.ac: If build==host==target, and running under a
GNU/glibc system, add read1 to the extra Makefile rules.
(EXTRA_RULES): AC_SUBST it.
* lib/read1.c: New file.
Fix handling of typedefs to types having a data_location attribute. Consider an array described in the debugging information as being a typedef of an array type for which there is a DW_AT_data_location attribute. Trying to print the value of that array currently yields incorrect element values. For instance: (gdb) print foo.three_tdef $1 = (6293760, 0, 6293772) The problem occurs because we check for the data_location attribute only on the typedef type, whereas we should be checking for the typedef's target type. As a result, GDB erroneously thinks that there is no data_location, and therefore starts reading the array's content from the address of the descriptor instead of the data_location address. gdb/ChangeLog: * value.c (value_from_contents_and_address): Strip resolved_type's typedef layers before checking its TYPE_DATA_LOCATION. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp: Add additional tests exercising the handling of variables declared as a typedef to an array which a DW_AT_data_location attribute.
2014-08-20 14:50:38 +02:00
2014-08-20 Joel Brobecker <brobecker@adacore.com>
* gdb.dwarf2/data-loc.exp: Add additional tests exercising
the handling of variables declared as a typedef to an array
which a DW_AT_data_location attribute.
Handle partially optimized out values similarly to unavailable values This fixes PR symtab/14604, PR symtab/14605, and Jan's test at https://sourceware.org/ml/gdb-patches/2014-07/msg00158.html, in a tree with bddbbed reverted: 2014-07-22 Pedro Alves <palves@redhat.com> * value.c (allocate_optimized_out_value): Don't mark value as non-lazy. The PRs are about variables described by the DWARF as being split over multiple registers using DWARF piece information, but some of those registers being marked as optimised out (not saved) by a later frame. GDB currently incorrectly mishandles these partially-optimized-out values. Even though we can usually tell from the debug info whether a local or global is optimized out, handling the case of a local living in a register that was not saved in a frame requires fetching the variable. GDB also needs to fetch a value to tell whether parts of it are "<unavailable>". Given this, it's not worth it to try to avoid fetching lazy optimized-out values based on debug info alone. So this patch makes GDB track which chunks of a value's contents are optimized out like it tracks <unavailable> contents. That is, it makes value->optimized_out be a bit range vector instead of a boolean, and removes the struct lval_funcs check_validity and check_any_valid hooks. Unlike Andrew's series which this is based on (at https://sourceware.org/ml/gdb-patches/2013-08/msg00300.html, note some pieces have gone in since), this doesn't merge optimized out and unavailable contents validity/availability behind a single interface, nor does it merge the bit range vectors themselves (at least yet). While it may be desirable to have a single entry point that returns existence of contents irrespective of what may make them invalid/unavailable, several places want to treat optimized out / unavailable / etc. differently, so each spot that potentially could use it will need to be careful considered on case-by-case basis, and best done as a separate change. This fixes Jan's test, because value_available_contents_eq wasn't considering optimized out value contents. It does now, and because of that it's been renamed to value_contents_eq. A new intro comment is added to value.h describing "<optimized out>", "<not saved>" and "<unavailable>" values. gdb/ PR symtab/14604 PR symtab/14605 * ada-lang.c (coerce_unspec_val_to_type): Use value_contents_copy_raw. * ada-valprint.c (val_print_packed_array_elements): Adjust. * c-valprint.c (c_val_print): Use value_bits_any_optimized_out. * cp-valprint.c (cp_print_value_fields): Let the common printing code handle optimized out values. (cp_print_value_fields_rtti): Use value_bits_any_optimized_out. * d-valprint.c (dynamic_array_type): Use value_bits_any_optimized_out. * dwarf2loc.c (entry_data_value_funcs): Remove check_validity and check_any_valid fields. (check_pieced_value_bits): Delete and inline ... (check_pieced_synthetic_pointer): ... here. (check_pieced_value_validity): Delete. (check_pieced_value_invalid): Delete. (pieced_value_funcs): Remove check_validity and check_any_valid fields. (read_pieced_value): Use mark_value_bits_optimized_out. (write_pieced_value): Switch to use mark_value_bytes_optimized_out. (dwarf2_evaluate_loc_desc_full): Copy the value contents instead of assuming the whole value is optimized out. * findvar.c (read_frame_register_value): Remove special handling of optimized out registers. (value_from_register): Use mark_value_bytes_optimized_out. * frame-unwind.c (frame_unwind_got_optimized): Use mark_value_bytes_optimized_out. * jv-valprint.c (java_value_print): Adjust. (java_print_value_fields): Let the common printing code handle optimized out values. * mips-tdep.c (mips_print_register): Remove special handling of optimized out registers. * opencl-lang.c (lval_func_check_validity): Delete. (lval_func_check_any_valid): Delete. (opencl_value_funcs): Remove check_validity and check_any_valid fields. * p-valprint.c (pascal_object_print_value_fields): Let the common printing code handle optimized out values. * stack.c (read_frame_arg): Remove special handling of optimized out values. Fetch both VAL and ENTRYVAL before comparing contents. Adjust to value_available_contents_eq rename. * valprint.c (valprint_check_validity) (val_print_scalar_formatted): Use value_bits_any_optimized_out. (val_print_array_elements): Adjust. * value.c (struct value) <optimized_out>: Now a VEC(range_s). (value_bits_any_optimized_out): New function. (value_entirely_covered_by_range_vector): New function, factored out from value_entirely_unavailable. (value_entirely_unavailable): Reimplement. (value_entirely_optimized_out): New function. (insert_into_bit_range_vector): New function, factored out from mark_value_bits_unavailable. (mark_value_bits_unavailable): Reimplement. (struct ranges_and_idx): New struct. (find_first_range_overlap_and_match): New function, factored out from value_available_contents_bits_eq. (value_available_contents_bits_eq): Rename to ... (value_contents_bits_eq): ... this. Check both unavailable contents and optimized out contents. (value_available_contents_eq): Rename to ... (value_contents_eq): ... this. (allocate_value_lazy): Remove reference to the old optimized_out boolean. (allocate_optimized_out_value): Use mark_value_bytes_optimized_out. (require_not_optimized_out): Adjust to check whether the optimized_out vec is empty. (ranges_copy_adjusted): New function, factored out from value_contents_copy_raw. (value_contents_copy_raw): Also copy the optimized out ranges. Assert the destination ranges aren't optimized out. (value_contents_copy): Update comment, remove call to require_not_optimized_out. (value_contents_equal): Adjust to check whether the optimized_out vec is empty. (set_value_optimized_out, value_optimized_out_const): Delete. (mark_value_bytes_optimized_out, mark_value_bits_optimized_out): New functions. (value_entirely_optimized_out, value_bits_valid): Delete. (value_copy): Take a VEC copy of the 'optimized_out' field. (value_primitive_field): Remove special handling of optimized out. (value_fetch_lazy): Assert that lazy values have no unavailable regions. Use value_bits_any_optimized_out. Remove some special handling for optimized out values. * value.h: Add intro comment about <optimized out> and <unavailable>. (struct lval_funcs): Remove check_validity and check_any_valid fields. (set_value_optimized_out, value_optimized_out_const): Remove. (mark_value_bytes_optimized_out, mark_value_bits_optimized_out): New declarations. (value_bits_any_optimized_out): New declaration. (value_bits_valid): Delete declaration. (value_available_contents_eq): Rename to ... (value_contents_eq): ... this, and extend comments. gdb/testsuite/ PR symtab/14604 PR symtab/14605 * gdb.dwarf2/dw2-op-out-param.exp: Remove kfail branches and use gdb_test.
2014-08-20 01:07:40 +02:00
2014-08-19 Andrew Burgess <aburgess@broadcom.com>
Pedro Alves <palves@redhat.com>
PR symtab/14604
PR symtab/14605
* gdb.dwarf2/dw2-op-out-param.exp: Remove kfail branches and use
gdb_test.
Remove stale comment This comment is no longer true for watchpoints since commit 31e77af2 (PR breakpoints/7143 - Watchpoint does not trigger when first set). gdb/testsuite/ * gdb.base/watchpoint-hw-hit-once.c (main): Update comment.
2014-08-19 19:18:31 +02:00
2014-08-19 Pedro Alves <palves@redhat.com>
* gdb.base/watchpoint-hw-hit-once.c (main): Update comment.
Set breakpoint on the right line In gdb.base/watchpoint-hw-hit-once.exp, test scans source and set breakpoint on the line having "break-at-exit", gdb_breakpoint [gdb_get_line_number "break-at-exit"] However, in watchpoint-hw-hit-once.c, there are two lines having this key word: dummy = 1; /* Stub to catch break-at-exit after WATCHEE has been hit. */ dummy = 2; /* break-at-exit */ so the test sets breakpoint on the first one, while I think it is expected to set breakpoint on the second one, as far as I can tell from the comments in watchpoint-hw-hit-once.c: /* Stub lines are present as no breakpoints/watchpoint gets hit if current PC already stays on the line PC while entering "step"/"continue". */ This patch is to change the source matching pattern so that test can correctly set breakpoint on the right line. This patch fixes a fail we found on arm-none-eabi target. (gdb) PASS: gdb.base/watchpoint-hw-hit-once.exp: continue continue^M Continuing.^M ^M *** EXIT code 0^M [Inferior 1 (Remote target) exited normally]^M (gdb) FAIL: gdb.base/watchpoint-hw-hit-once.exp: continue to break-at-exit (the program exited) Run it again on x86_64-linux, no result changes. gdb/testsuite: 2014-08-19 Yao Qi <yao@codesourcery.com> * gdb.base/watchpoint-hw-hit-once.exp: Set breakpoint on the right line.
2014-08-12 03:14:08 +02:00
2014-08-19 Yao Qi <yao@codesourcery.com>
* gdb.base/watchpoint-hw-hit-once.exp: Set breakpoint on the
right line.
boards/fission.exp: Explicitly pass -ggnu-pubnames for clang. * boards/fission.exp: Explicitly pass -ggnu-pubnames for clang.
2014-08-18 21:07:49 +02:00
2014-08-18 David Blaikie <dblaikie@gmail.com>
* boards/fission.exp: Explicitly pass -ggnu-pubnames for clang.
gdb.dwarf2/data-loc.exp: Remove second DW_AT_upper bound in array range. The testcase generates an assembly file where a second DW_AT_upper_bound attribute gets generated in the array range. This was definitely unintentional, and I only noticed this after pushing the testcase, when dumping one more time the DWARF data using readelf. This patch fixes it. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.exp: Remove second DW_AT_upper bound attribute in array range.
2014-08-18 19:41:57 +02:00
2014-08-18 Joel Brobecker <brobecker@adacore.com>
* gdb.dwarf2/data-loc.exp: Remove second DW_AT_upper bound
attribute in array range.
DW_AT_data_location and DW_OP_push_object_address testcase. This testcase allows us to test the proper processing of both DW_AT_data_location and DW_OP_push_object_address using a hand-crafted testcase duplicating how we expect the Ada compiler to represent unbounded arrays. gdb/testsuite/ChangeLog: * gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
2014-08-14 01:45:59 +02:00
2014-08-18 Joel Brobecker <brobecker@adacore.com>
* gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
Add new argument NOSIDE to find_overload_match. This is a fix for PR c++/17132. If this new argument is set to EVAL_AVOID_SIDE_EFFECTS, then the object's memory will not be read while picking the best overload match. gdb/ * eval.c: Update all calls to find_overload_match. * valarith.c: Likewise. (value_user_defined_cpp_op, value_user_defined_op): New argument NOSIDE. Update all callers. * valops.c (find_overload_match): New argument NOSIDE. * value.h (find_overload_match): Update signature. gdb/testsuite * gdb.cp/pr17132.cc: New file. * gdb.cp/pr17132.exp: New file.
2014-07-09 19:25:48 +02:00
2014-08-15 Siva Chandra Reddy <sivachandra@google.com>
PR c++/17132
* gdb.cp/pr17132.cc: New file.
* gdb.cp/pr17132.exp: New file.
Fix xmethod Python so that it works with Python3. gdb/ * python/lib/gdb/command/xmethods.py (set_xm_status1): Use the 'items' methods instead of 'iteritems' method on dictionaries. gdb/testsuite/ * gdb.python/py-xmethods.py (A_getarrayind) (E_method_char_worker.__call__, E_method_int_worker.__call__): Use 'print' with function call syntax. (E_method_matcher.match): Fix tab vs space indentation mixup.
2014-08-05 03:07:43 +02:00
2014-08-15 Siva Chandra Reddy <sivachandra@google.com>
* gdb.python/py-xmethods.py (A_getarrayind)
(E_method_char_worker.__call__, E_method_int_worker.__call__):
Use 'print' with function call syntax.
(E_method_matcher.match): Fix tab vs space indentation mixup.
Skip tfile.exp if unable to generate trace file I added proc generate_tracefile in this patch https://sourceware.org/ml/gdb-patches/2014-03/msg00591.html but tfile.exp isn't skipped as changelog entry said: * gdb.trace/tfile.exp: Skip the test if generate_tracefile return 0. it is a mistake I made at the last minute. Patch below fixed it. gdb/testsuite: 2014-08-15 Yao Qi <yao@codesourcery.com> * gdb.trace/tfile.exp: Return -1 if generate_tracefile returns false.
2014-08-14 09:24:58 +02:00
2014-08-15 Yao Qi <yao@codesourcery.com>
* gdb.trace/tfile.exp: Return -1 if generate_tracefile returns
false.
Set print symbol off in some tests GDB in default prints the symbol associated on an address, and tests assume that there is no symbol on address zero. However, on bare metal target, address may be mapped to zero and there may be a symbol. Then, some tests fail as below: print const_cast<void *> (0)^M $8 = (void *) 0x0 <_ftext>^M (gdb) FAIL: gdb.cp/casts.exp: const_cast of 0 p acp->c1^M $9 = (A *) 0x0 <_ftext>^M (gdb) FAIL: gdb.cp/class2.exp: p acp->c1 This patch is to set print symbol off in these tests, like what I did previously https://sourceware.org/ml/gdb-patches/2014-07/msg00257.html gdb/testsuite: 2014-08-15 Yao Qi <yao@codesourcery.com> * gdb.cp/casts.exp: Set print symbol off. * gdb.cp/class2.exp: Likewise. * gdb.cp/overload.exp: Likewise. * gdb.cp/templates.exp: Likewise.
2014-08-14 04:51:10 +02:00
2014-08-15 Yao Qi <yao@codesourcery.com>
* gdb.cp/casts.exp: Set print symbol off.
* gdb.cp/class2.exp: Likewise.
* gdb.cp/overload.exp: Likewise.
* gdb.cp/templates.exp: Likewise.
Delete "Loaded symbols for ..." message, it is redundant. * solib.c (solib_read_symbols): Delete "Loaded symbols for ..." message, it is redundant with "Reading symbols from ..." message. testsuite/ * gdb.base/print-symbol-loading.exp (test_load_core): Update. (test_load_shlib): Update.
2014-08-12 02:21:07 +02:00
2014-08-11 Doug Evans <dje@google.com>
* gdb.base/print-symbol-loading.exp (test_load_core): Update.
(test_load_shlib): Update.
Remove duplicated code on checking address 0x0 is accessiable I find some gdb.python tests fail on arm-none-eabi target, because the tests assume that memory on address 0x is inaccessible. Some tests (in gdb.base) are aware of this, so do a "x 0" check first. However, the code is copy-n-paste. This patch is to move the "x 0" check to a procedure in lib/gdb.exp, and get needed tests call it. The original code matches pattern "0x0:\[ \t\]*Error accessing memory address 0x0\r\n$gdb_prompt $", but I remove it from the new proc is_address_zero_readable, because GDB doesn't emit such message any more. gdb/testsuite: 2014-08-09 Yao Qi <yao@codesourcery.com> * gdb.base/display.exp: Invoke is_address_zero_readable. * gdb.guile/scm-value.exp (test_value_in_inferior): Likewise. * gdb.python/py-value.exp (test_value_in_inferior): Likewise. * gdb.base/hbreak-unmapped.exp: Return if is_address_zero_readable returns true. * gdb.base/signest.exp: Likewise. * gdb.base/signull.exp: Likewise. * gdb.base/sigbpt.exp: Likewise. * gdb.guile/scm-disasm.exp: Do the test if is_address_zero_readable returns false. * gdb.guile/scm-pretty-print.exp (run_lang_tests): Likewise. * gdb.python/py-arch.exp: Likewise. * gdb.python/py-prettyprint.exp (run_lang_tests): Likewise. * lib/gdb.exp (is_address_zero_readable): New proc.
2014-08-07 10:09:38 +02:00
2014-08-09 Yao Qi <yao@codesourcery.com>
* gdb.base/display.exp: Invoke is_address_zero_readable.
* gdb.guile/scm-value.exp (test_value_in_inferior): Likewise.
* gdb.python/py-value.exp (test_value_in_inferior): Likewise.
* gdb.base/hbreak-unmapped.exp: Return if
is_address_zero_readable returns true.
* gdb.base/signest.exp: Likewise.
* gdb.base/signull.exp: Likewise.
* gdb.base/sigbpt.exp: Likewise.
* gdb.guile/scm-disasm.exp: Do the test if
is_address_zero_readable returns false.
* gdb.guile/scm-pretty-print.exp (run_lang_tests): Likewise.
* gdb.python/py-arch.exp: Likewise.
* gdb.python/py-prettyprint.exp (run_lang_tests): Likewise.
* lib/gdb.exp (is_address_zero_readable): New proc.
Make test messages in gdb.mi/mi-var-display.exp unique When I fix a bug in gdb.mi/mi-var-display.exp, I find its test messages aren't unique, which makes some confusions for me. $ cat testsuite/gdb.sum | grep "PASS" | sort | uniq -c | sort -n ... 2 PASS: gdb.mi/mi-var-display.exp: set format variable bar 2 PASS: gdb.mi/mi-var-display.exp: set format variable foo 2 PASS: gdb.mi/mi-var-display.exp: set format variable weird.func_ptr 2 PASS: gdb.mi/mi-var-display.exp: set format variable weird.func_ptr_ptr 2 PASS: gdb.mi/mi-var-display.exp: show format variable foo 3 PASS: gdb.mi/mi-var-display.exp: eval variable foo This patch is to make test messages in mi-var-display.exp unique. gdb/testsuite: 2014-08-09 Yao Qi <yao@codesourcery.com> PR testsuite/13443 * gdb.mi/mi-var-display.exp: Make test messages unique.
2014-08-07 09:01:22 +02:00
2014-08-09 Yao Qi <yao@codesourcery.com>
PR testsuite/13443
* gdb.mi/mi-var-display.exp: Make test messages unique.
make "set debug target" take effect immediately Right now, "set debug target" acts a bit strangely. Most target APIs only notice that it has changed when the target stack is changed in some way. This is because many methods implement the setting using the special debug target. However, a few spots do change their behavior immediately -- any place explicitly checking "targetdebug". Some of this peculiar behavior is documented. However, I think that it just isn't very useful for it to work this way. So, this patch changes "set debug target" to take effect immediately in all cases. This is done by simply calling update_current_target when the setting is changed. This required one small change in the test suite. Here a test was expecting the current behavior. Built and regtested on x86-64 Fedora 20. 2014-08-04 Tom Tromey <tromey@redhat.com> * target.c (set_targetdebug): New function. (initialize_targets): Pass set_targetdebug when creating "set debug target". 2014-08-04 Tom Tromey <tromey@redhat.com> * gdb.texinfo (Debugging Output): Update for change to "set debug target". 2014-08-04 Tom Tromey <tromey@redhat.com> * gdb.base/sss-bp-on-user-bp-2.exp: Expect output from "set debug target 0".
2014-07-28 20:53:35 +02:00
2014-08-04 Tom Tromey <tromey@redhat.com>
* gdb.base/sss-bp-on-user-bp-2.exp: Expect output from "set debug
target 0".
fix test suite regression This fixes a test suite regession that Yao noticed. This test checks for some specific "target debug" output that has changed since the test was written. 2014-08-04 Tom Tromey <tromey@redhat.com> * gdb.base/sss-bp-on-user-bp-2.exp: Match "to_resume", not "target_resume".
2014-07-29 21:31:00 +02:00
2014-08-04 Tom Tromey <tromey@redhat.com>
* gdb.base/sss-bp-on-user-bp-2.exp: Match "to_resume", not
"target_resume".
Handle variable-sized fields in the interior of structure type In Ada, variable-sized field can be located at any position of a structure. Consider for instance the following declarations: Dyn_Size : Integer := 1; type Table is array (Positive range <>) of Integer; type Inner is record T1 : Table (1 .. Dyn_Size) := (others => 1); T2 : Table (1 .. Dyn_Size) := (others => 2); end record; type Inner_Array is array (1 .. 2) of Inner; type Outer is record I0 : Integer := 0; A1 : Inner_Array; Marker : Integer := 16#01020304#; end record; Rt : Outer; What this does is declare a variable "Rt" of type Outer, which contains 3 fields where the second (A1) is of type Inner_Array. type Inner_Array is an array with 2 elements of type Inner. Because type Inner contains two arrays whose upper bound depend on a variable, the size of the array, and therefore the size of type Inner is dynamic, thus making field A1 a dynamically-size field. When trying to print the value of Rt, we hit the following limitation: (gdb) print rt Attempt to resolve a variably-sized type which appears in the interior of a structure type The limitation was somewhat making sense in C, but needs to be lifted for Ada. This patch mostly lifts that limitation. As a result of this patch, the type length computation had to be reworked a little bit. gdb/ChangeLog: * gdbtypes.c (resolve_dynamic_struct): Do not generate an error if detecting a variable-sized field that is not the last field. Fix struct type length computation. gdb/testsuite/ChangeLog: * gdb.base/vla-datatypes.c (vla_factory): Add new variable inner_vla_struct_object_size. * gdb.base/vla-datatypes.exp: Adjust last test, and mark it as xfail.
2014-07-08 17:15:35 +02:00
2014-08-01 Joel Brobecker <brobecker@adacore.com>
* gdb.base/vla-datatypes.c (vla_factory): Add new variable
inner_vla_struct_object_size.
* gdb.base/vla-datatypes.exp: Adjust last test, and mark it
as xfail.
gdb.threads/signal-command-handle-nopass.exp: Add comment Explain why we do "info threads". gdb/testsuite/ 2014-07-30 Pedro Alves <palves@redhat.com> * gdb.threads/signal-command-handle-nopass.exp (test): Add comment.
2014-07-30 13:19:30 +02:00
2014-07-30 Pedro Alves <palves@redhat.com>
* gdb.threads/signal-command-handle-nopass.exp (test): Add
comment.
Fix PR 17206 As reported in PR 17206, an internal error is triggered when command until is executed. In infcmd.c:until_next_command, step_range_end is set to 'pc', if (!func) { struct bound_minimal_symbol msymbol = lookup_minimal_symbol_by_pc (pc); if (msymbol.minsym == NULL) error (_("Execution is not within a known function.")); tp->control.step_range_start = BMSYMBOL_VALUE_ADDRESS (msymbol); tp->control.step_range_end = pc; } and later in infrun.c:resume, the assert below is triggered in PR 17206. if (tp->control.may_range_step) { /* If we're resuming a thread with the PC out of the step range, then we're doing some nested/finer run control operation, like stepping the thread out of the dynamic linker or the displaced stepping scratch pad. We shouldn't have allowed a range step then. */ gdb_assert (pc_in_thread_step_range (pc, tp)); } In until_next_command, we set step range to [XXX, pc), so pc isn't within the range. pc_in_thread_step_range returns false and the assert is triggered. AFAICS, the range we want in until_next_command is [XXX, pc] instead of [XXX, pc), because we want to program step until greater than pc. This patch is to set step_range_end to 'pc + 1'. Running until-nodebug.exp with unpatched GDB will get the following fail, FAIL: gdb.base/until-nodebug.exp: until 2 (GDB internal error) and the fail goes away when the fix is applied. gdb: 2014-07-29 Yao Qi <yao@codesourcery.com> PR gdb/17206 * infcmd.c (until_next_command): Set step_range_end to PC + 1. gdb/testsuite: 2014-07-29 Yao Qi <yao@codesourcery.com> PR gdb/17206 * gdb.base/until-nodebug.exp: New.
2014-07-28 07:44:57 +02:00
2014-07-29 Yao Qi <yao@codesourcery.com>
PR gdb/17206
* gdb.base/until-nodebug.exp: New.
PR guile/17203 * guile/scm-param.c (pascm_parameter_defined_p): New function. (gdbscm_register_parameter_x): Call it. Raise error for pre-existing parameters. testsuite/ * gdb.guile/scm-parameter.exp: Add tests for trying to create previously existing parameter, and previously ambiguously spelled parameter.
2014-07-29 04:20:30 +02:00
2014-07-28 Doug Evans <xdje42@gmail.com>
PR guile/17203
* gdb.guile/scm-parameter.exp: Add tests for trying to create
previously existing parameter, and previously ambiguously spelled
parameter.
gdb/testsuite/gdb.base/varargs.exp: Remove ARM KFAILs These tests used to fail on ARM but now pass, so remove the KFAIL. gdb/testsuite/ChangeLog: 2014-07-28 Will Newton <will.newton@linaro.org> * gdb.base/varargs.exp: Remove KFAILs for ARM.
2014-07-22 18:16:48 +02:00
2014-07-28 Will Newton <will.newton@linaro.org>
* gdb.base/varargs.exp: Remove KFAILs for ARM.
PR guile/17146 preparatory work. * data-directory/Makefile.in (GUILE_FILES): Add support.scm. * guile/lib/gdb/support.scm: New file. * guile/guile.c (gdbscm_init_module_name): Change to "gdb". * guile/lib/gdb.scm: Load gdb/init.scm as an include file. All uses updated. * guile/lib/gdb/init.scm (SCM_ARG1, SCM_ARG2): Moved to support.scm. All uses updated. (%assert-type): Ditto, and renamed to assert-type. (%exception-print-style): Delete. testsuite/ * gdb.guile/types-module.exp: Add tests for wrong type arguments.
2014-07-27 02:01:09 +02:00
2014-07-26 Ludovic Courtès <ludo@gnu.org>
Doug Evans <xdje42@gmail.com>
PR guile/17146
* gdb.guile/types-module.exp: Add tests for wrong type arguments.
Always pass signals to the right thread Currently, GDB can pass a signal to the wrong thread in several different but related scenarios. E.g., if thread 1 stops for signal SIGFOO, the user switches to thread 2, and then issues "continue", SIGFOO is actually delivered to thread 2, not thread 1. This obviously messes up programs that use pthread_kill to send signals to specific threads. This has been a known issue for a long while. Back in 2008 when I made stop_signal be per-thread (2020b7ab), I kept the behavior -- see code in 'proceed' being removed -- wanting to come back to it later. The time has finally come now. The patch fixes this -- on resumption, intercepted signals are always delivered to the thread that had intercepted them. Another example: if thread 1 stops for a breakpoint, the user switches to thread 2, and then issues "signal SIGFOO", SIGFOO is actually delivered to thread 1, not thread 2, because 'proceed' first switches to thread 1 to step over its breakpoint... If the user deletes the breakpoint before issuing "signal FOO", then the signal is delivered to thread 2 (the current thread). "signal SIGFOO" can be used for two things: inject a signal in the program while the program/thread had stopped for none, bypassing "handle nopass"; or changing/suppressing a signal the program had stopped for. These scenarios are really two faces of the same coin, and GDB can't really guess what the user is trying to do. GDB might have intercepted signals in more than one thread even (see the new signal-command-multiple-signals-pending.exp test). At least in the inject case, it's obviously clear to me that the user means to deliver the signal to the currently selected thread, so best is to make the command's behavior consistent and easy to explain. Then, if the user is trying to suppress/change a signal the program had stopped for instead of injecting a new signal, but, the user had changed threads meanwhile, then she will be surprised that with: (gdb) continue Thread 1 stopped for signal SIGFOO. (gdb) thread 2 (gdb) signal SIGBAR ... GDB actually delivers SIGFOO to thread 1, and SIGBAR to thread 2 (with scheduler-locking off, which is the default, because then "signal" or any other resumption command resumes all threads). So the patch makes GDB detect that, and ask for confirmation: (gdb) thread 1 [Switching to thread 1 (Thread 10979)] (gdb) signal SIGUSR2 Note: Thread 3 previously stopped with signal SIGUSR2, User defined signal 2. Thread 2 previously stopped with signal SIGUSR1, User defined signal 1. Continuing thread 1 (the current thread) with specified signal will still deliver the signals noted above to their respective threads. Continue anyway? (y or n) All these scenarios are covered by the new tests. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-07-25 Pedro Alves <palves@redhat.com> * NEWS: Mention signal passing and "signal" command changes. * gdbthread.h (struct thread_suspend_state) <stop_signal>: Extend comment. * breakpoint.c (until_break_command): Adjust clear_proceed_status call. * infcall.c (run_inferior_call): Adjust clear_proceed_status call. * infcmd.c (proceed_thread_callback, continue_1, step_once) (jump_command): Adjust clear_proceed_status call. (signal_command): Warn if other thread that are resumed have signals that will be delivered. Adjust clear_proceed_status call. (until_next_command, finish_command) (proceed_after_attach_callback, attach_command_post_wait) (attach_command): Adjust clear_proceed_status call. * infrun.c (proceed_after_vfork_done): Likewise. (proceed_after_attach_callback): Adjust comment. (clear_proceed_status_thread): Clear stop_signal if not in pass state. (clear_proceed_status_callback): Delete. (clear_proceed_status): New 'step' parameter. Only clear the proceed status of threads the command being prepared is about to resume. (proceed): If passed in an explicit signal, override stop_signal with it. Don't pass the last stop signal to the thread we're resuming. (init_wait_for_inferior): Adjust clear_proceed_status call. (switch_back_to_stepped_thread): Clear the signal if it should not be passed. * infrun.h (clear_proceed_status): New 'step' parameter. (user_visible_resume_ptid): Add comment. * linux-nat.c (linux_nat_resume_callback): Don't check whether the signal is in pass state. * remote.c (append_pending_thread_resumptions): Likewise. * mi/mi-main.c (proceed_thread): Adjust clear_proceed_status call. gdb/doc/ 2014-07-25 Pedro Alves <palves@redhat.com> Eli Zaretskii <eliz@gnu.org> * gdb.texinfo (Signaling) <signal command>: Explain what happens with multi-threaded programs. gdb/testsuite/ 2014-07-25 Pedro Alves <palves@redhat.com> * gdb.threads/signal-command-handle-nopass.c: New file. * gdb.threads/signal-command-handle-nopass.exp: New file. * gdb.threads/signal-command-multiple-signals-pending.c: New file. * gdb.threads/signal-command-multiple-signals-pending.exp: New file. * gdb.threads/signal-delivered-right-thread.c: New file. * gdb.threads/signal-delivered-right-thread.exp: New file.
2014-07-25 17:57:31 +02:00
2014-07-25 Pedro Alves <palves@redhat.com>
* gdb.threads/signal-command-handle-nopass.c: New file.
* gdb.threads/signal-command-handle-nopass.exp: New file.
* gdb.threads/signal-command-multiple-signals-pending.c: New file.
* gdb.threads/signal-command-multiple-signals-pending.exp: New file.
* gdb.threads/signal-delivered-right-thread.c: New file.
* gdb.threads/signal-delivered-right-thread.exp: New file.
Fix paginate-*.exp races Jan pointed out in <https://sourceware.org/ml/gdb-patches/2014-07/msg00553.html> that these testcases have racy results: gdb.base/double-prompt-target-event-error.exp gdb.base/paginate-after-ctrl-c-running.exp gdb.base/paginate-bg-execution.exp gdb.base/paginate-execution-startup.exp gdb.base/paginate-inferior-exit.exp This is easily reproducible with "read1" from: [reproducer for races of expect incomplete reads] http://sourceware.org/bugzilla/show_bug.cgi?id=12649 The '-notransfer -re "<return>" { exp_continue }' trick in the current tests doesn't actually work. The issue that led to the -notransfer trick was that "---Type <return> to continue, or q <return> to quit---" has two "<return>"s. If one wants gdb_test_multiple to not hit the built-in "<return>" match that results in FAIL, one has to expect the pagination prompt in chunks, first up to the first "<return>", then again, up to the second. Something around these lines: gdb_test_multiple "" $test { -re "<return>" { exp_continue } -re "to quit ---" { pass $test } } The intent was for -notransfer+exp_continue to make expect fetch more input, and rerun the matches against the now potentially fuller buffer, and then eventually the -re that includes the full pagination prompt regex would match instead (because it's listed higher up, it would match first). But, once that "<return>" -notransfer -re matches, it keeps re-matching forever. It seems like with exp_continue, expect immediately retries matching, instead of first reading in more data into the buffer, if available. Fix this like I should have done in the first place. There's actually no good reason for gdb_test_multiple to only match "<return>". We can make gdb_test_multiple expect the whole pagination prompt text instead, which is store in the 'pagination_prompt' global (similar to 'gdb_prompt'). Then a gdb_test_multiple caller that doesn't want the default match to trigger, because it wants to see one pagination prompt, does simply: gdb_test_multiple "" $test { -re "$pagination_prompt$" { pass $test } } which is just like when we don't want the default $gdb_prompt match within gdb_test_multiple to trigger, like: gdb_test_multiple "" $test { -re "$gdb_prompt $" { pass $test } } Tested on x86_64 Fedora 20. In addition, I've let the racy tests run all in parallel in a loop for 30 minutes, and they never failed. gdb/testsuite/ 2014-07-25 Pedro Alves <palves@redhat.com> * gdb.base/double-prompt-target-event-error.exp (cancel_pagination_in_target_event): Remove '-notransfer <return>' match. (cancel_pagination_in_target_event): Rework double prompt detection. * gdb.base/paginate-after-ctrl-c-running.exp (test_ctrlc_while_target_running_paginates): Remove '-notransfer <return>' match. * gdb.base/paginate-bg-execution.exp (test_bg_execution_pagination_return) (test_bg_execution_pagination_cancel): Remove '-notransfer <return>' matches. * gdb.base/paginate-execution-startup.exp (test_fg_execution_pagination_return) (test_fg_execution_pagination_cancel): Remove '-notransfer <return>' matches. * gdb.base/paginate-inferior-exit.exp (test_paginate_inferior_exited): Remove '-notransfer <return>' match. * lib/gdb-utils.exp (string_to_regexp): Move here from lib/gdb.exp. * lib/gdb.exp (pagination_prompt): Run text through string_to_regexp. (gdb_test_multiple): Match $pagination_prompt instead of "<return>". (string_to_regexp): Move to lib/gdb-utils.exp.
2014-07-25 11:07:38 +02:00
2014-07-25 Pedro Alves <palves@redhat.com>
* gdb.base/double-prompt-target-event-error.exp
(cancel_pagination_in_target_event): Remove '-notransfer <return>'
match.
(cancel_pagination_in_target_event): Rework double prompt
detection.
* gdb.base/paginate-after-ctrl-c-running.exp
(test_ctrlc_while_target_running_paginates): Remove '-notransfer
<return>' match.
* gdb.base/paginate-bg-execution.exp
(test_bg_execution_pagination_return)
(test_bg_execution_pagination_cancel): Remove '-notransfer
<return>' matches.
* gdb.base/paginate-execution-startup.exp
(test_fg_execution_pagination_return)
(test_fg_execution_pagination_cancel): Remove '-notransfer
<return>' matches.
* gdb.base/paginate-inferior-exit.exp
(test_paginate_inferior_exited): Remove '-notransfer <return>'
match.
* lib/gdb-utils.exp (string_to_regexp): Move here from lib/gdb.exp.
* lib/gdb.exp (pagination_prompt): Run text through
string_to_regexp.
(gdb_test_multiple): Match $pagination_prompt instead of
"<return>".
(string_to_regexp): Move to lib/gdb-utils.exp.
Fix read_frame_arg for optimized-out entry values. gdb/ 2014-07-22 Jan Kratochvil <jan.kratochvil@redhat.com> * stack.c (read_frame_arg): Verify value_optimized_out before calling value_available_contents_eq. gdb/testsuite/ 2014-07-22 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.arch/amd64-entry-value-paramref.S: New file. * gdb.arch/amd64-entry-value-paramref.cc: New file. * gdb.arch/amd64-entry-value-paramref.exp: New file. * gdb.arch/amd64-optimout-repeat.S: New file. * gdb.arch/amd64-optimout-repeat.c: New file. * gdb.arch/amd64-optimout-repeat.exp: New file. Message-ID: <20140720150727.GA18488@host2.jankratochvil.net> Message-ID: <20140711153757.GA452@host2.jankratochvil.net>
2014-07-22 22:09:35 +02:00
2014-07-22 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/amd64-entry-value-paramref.S: New file.
* gdb.arch/amd64-entry-value-paramref.cc: New file.
* gdb.arch/amd64-entry-value-paramref.exp: New file.
* gdb.arch/amd64-optimout-repeat.S: New file.
* gdb.arch/amd64-optimout-repeat.c: New file.
* gdb.arch/amd64-optimout-repeat.exp: New file.
PR 17170 - testcase for GDB global --statistics regression. gdb/testsuite/ 2014-07-17 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/17170 * gdb.base/statistics.exp: New file. Message-ID: <20140712174217.GA1478@host2.jankratochvil.net>
2014-07-17 13:56:24 +02:00
2014-07-17 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/17170
* gdb.base/statistics.exp: New file.
Fix 17170. * maint.c (count_symtabs_and_blocks): Handle NULL current_program_space. (report_command_stats): Check global enabled flag in addition to recorded enabled flag. (make_command_stats_cleanup): Handle msg_type == 0, startup. testsuite/ * gdb.base/maint.exp: Update testing of per-command stats.
2014-07-17 11:38:32 +02:00
2014-07-17 Doug Evans <dje@google.com>
Add reference to PR 17170 to previous entry.
2014-07-17 11:42:55 +02:00
PR gdb/17170
Fix 17170. * maint.c (count_symtabs_and_blocks): Handle NULL current_program_space. (report_command_stats): Check global enabled flag in addition to recorded enabled flag. (make_command_stats_cleanup): Handle msg_type == 0, startup. testsuite/ * gdb.base/maint.exp: Update testing of per-command stats.
2014-07-17 11:38:32 +02:00
* gdb.base/maint.exp: Update testing of per-command stats.
gdb.trace/tfile.c: Remove Thumb bit in one more more, general cleanup I noticed that the existing code casts a function's address to 'long', but that doesn't work correctly on some ABIs, like Win64, where long is 32-bit and while pointers are 64-bit: func_addr = (long) &write_basic_trace_file; Fixing that showed there's actually another place in the file that writes a function address to file, and therefore should clear the Thumb bit. This commit adds a macro+function pair to centralize the Thumb bit handling, and uses it in both places. The rest is just enough changes to make the file build without warnings with "-Wall -Wextra" with x86_64-w64-mingw32-gcc and i686-w64-mingw32-gcc cross compilers, and with -m32/-m64 on x86_64 GNU/Linux. Currently with x86_64-w64-mingw32-gcc we get: $ x86_64-w64-mingw32-gcc tfile.c -Wall -DTFILE_DIR=\"\" tfile.c: In function 'start_trace_file': tfile.c:51:23: error: 'S_IRGRP' undeclared (first use in this function) S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH); ^ tfile.c:51:23: note: each undeclared identifier is reported only once for each function it appears in tfile.c:51:31: error: 'S_IROTH' undeclared (first use in this function) S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH); ^ tfile.c: In function 'add_memory_block': tfile.c:79:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] ll_x = (unsigned long) addr; ^ tfile.c: In function 'write_basic_trace_file': tfile.c:113:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] func_addr = (long) &write_basic_trace_file; ^ tfile.c:137:3: warning: passing argument 1 of 'add_memory_block' from incompatible pointer type [enabled by default] add_memory_block (&testglob, sizeof (testglob)); ^ tfile.c:72:1: note: expected 'char *' but argument is of type 'int *' add_memory_block (char *addr, int size) ^ tfile.c:139:3: warning: passing argument 1 of 'add_memory_block' from incompatible pointer type [enabled by default] add_memory_block (&testglob2, 1); ^ tfile.c:72:1: note: expected 'char *' but argument is of type 'int *' add_memory_block (char *addr, int size) ^ tfile.c: In function 'write_error_trace_file': tfile.c:185:3: warning: implicit declaration of function 'alloca' [-Wimplicit-function-declaration] char *hex = alloca (len * 2 + 1); ^ tfile.c:185:15: warning: incompatible implicit declaration of built-in function 'alloca' [enabled by default] char *hex = alloca (len * 2 + 1); ^ tfile.c:211:6: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] (long) &write_basic_trace_file); ^ Tested on x86_64 Fedora 20, -m64 and -m32. Tested by Yao on arm targets. gdb/testsuite/ 2014-07-16 Pedro Alves <palves@redhat.com> * gdb.trace/tfile.c: Include unistd.h and stdint.h. (start_trace_file): Guard S_IRGRP and S_IROTH uses behind #ifdef. (tfile_write_64, tfile_write_16, tfile_write_8, tfile_write_addr) (tfile_write_buf): New functions. (add_memory_block): Rewrite using the above. (adjust_function_address): New function. (FUNCTION_ADDRESS): New macro. (write_basic_trace_file): Remove short_x local, and use tfile_write_16. Change type of func_addr local to unsigned long long. Use FUNCTION_ADDRESS instead of handling the Thumb bit here. Cast argument of add_memory_block to char pointer. (write_error_trace_file): Avoid alloca. Use FUNCTION_ADDRESS. (main): Remove parameters. * gdb.trace/tfile.exp: Remove nowarnings.
2014-07-16 20:25:41 +02:00
2014-07-16 Pedro Alves <palves@redhat.com>
* gdb.trace/tfile.c: Include unistd.h and stdint.h.
(start_trace_file): Guard S_IRGRP and S_IROTH uses behind #ifdef.
(tfile_write_64, tfile_write_16, tfile_write_8, tfile_write_addr)
(tfile_write_buf): New functions.
(add_memory_block): Rewrite using the above.
(adjust_function_address): New function.
(FUNCTION_ADDRESS): New macro.
(write_basic_trace_file): Remove short_x local, and use
tfile_write_16. Change type of func_addr local to unsigned long
long. Use FUNCTION_ADDRESS instead of handling the Thumb bit
here. Cast argument of add_memory_block to char pointer.
(write_error_trace_file): Avoid alloca. Use FUNCTION_ADDRESS.
(main): Remove parameters.
* gdb.trace/tfile.exp: Remove nowarnings.
Add test for string evaluation with "debug expression" on As Joel pointed out in... https://sourceware.org/ml/gdb-patches/2014-07/msg00391.html ...it would be nice to add a test for that. Tested on Linux x86_64 (Ubuntu 14.10). gdb/testsuite/ChangeLog 2014-07-15 Simon Marchi <simon.marchi@ericsson.com> * gdb.base/debug-expr.exp: Test string evaluation with "debug expression" on.
2014-07-15 19:04:31 +02:00
2014-07-15 Simon Marchi <simon.marchi@ericsson.com>
* gdb.base/debug-expr.exp: Test string evaluation with
"debug expression" on.
gdb.base/reread.exp: Really restart GDB The other day I noticed that default_gdb_start reuses the GDB process if it has been spawned already: proc default_gdb_start { } { ... if [info exists gdb_spawn_id] { return 0 } I was a bit surprised, and so I hacked in an error to check whether anything is relying on it: + if [info exists gdb_spawn_id] { + error "GDB already spawned" + } And lo, that tripped on a funny buglet (see below). The comment in reread.exp says "Restart GDB entirely", but in reality, due to the above, that's not what is happening, as a gdb_exit call is missing. The test is proceeding with the previous GDB process... I don't really want to go hunt for whether there's an odd setup out there that assumes this in its board file or something, so for now, I'm taking the simple route of just making the test do what it says it does. I think this much makes it an obvious fix. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (gdb) PASS: gdb.base/reread.exp: run to foo() second time ERROR: tcl error sourcing ../src/gdb/testsuite/gdb.base/reread.exp. ERROR: GDB already spawned while executing "error "GDB already spawned"" invoked from within "if [info exists gdb_spawn_id] { error "GDB already spawned" }" (procedure "default_gdb_start" line 22) invoked from within "default_gdb_start" (procedure "gdb_start" line 2) invoked from within "gdb_start" invoked from within "if [is_remote target] { unsupported "second pass: GDB should check for changes before running" } else { # Put the older executable back in pl..." (file "../src/gdb/testsuite/gdb.base/reread.exp" line 114) invoked from within "source ../src/gdb/testsuite/gdb.base/reread.exp" ("uplevel" body line 1) invoked from within "uplevel #0 source ../src/gdb/testsuite/gdb.base/reread.exp" invoked from within "catch "uplevel #0 source $test_file_name"" testcase ../src/gdb/testsuite/gdb.base/reread.exp completed in 1 seconds ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gdb/testsuite/ 2014-07-15 Pedro Alves <palves@redhat.com> * gdb.base/reread.exp: Use clean_restart.
2014-07-15 18:30:34 +02:00
2014-07-15 Pedro Alves <palves@redhat.com>
* gdb.base/reread.exp: Use clean_restart.
Add support for the __flash qualifier on AVR The __flash qualifier is part of the named address spaces for AVR [1]. It allows putting read-only data in the flash memory, normally reserved for code. When used together with a pointer, the DW_AT_address_class attribute is set to 1 and allows GDB to detect that when it will be dereferenced, the data will be loaded from the flash memory (with the LPM instruction). We can now properly debug the following code: ~~~ const __flash char data_in_flash = 0xab; int main (void) { const __flash char *pointer_to_flash = &data_in_flash; } ~~~ ~~~ (gdb) print pointer_to_flash $1 = 0x1e8 <data_in_flash> "\253" (gdb) print/x *pointer_to_flash $2 = 0xab (gdb) x/x pointer_to_flash 0x1e8 <data_in_flash>: 0xXXXXXXab ~~~ Whereas previously, GDB would revert to the default address space which is RAM and mapped in higher memory: ~~~ (gdb) print pointer_to_flash $1 = 0x8001e8 "" ~~~ [1] https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html 2014-07-15 Pierre Langlois <pierre.langlois@embecosm.com> gdb/ * avr-tdep.c (AVR_TYPE_ADDRESS_CLASS_FLASH): New macro. (AVR_TYPE_INSTANCE_FLAG_ADDRESS_CLASS_FLASH): Likewise. (avr_address_to_pointer): Check for AVR_TYPE_ADDRESS_CLASS_FLASH. (avr_pointer_to_address): Likewise. (avr_address_class_type_flags): New function. (avr_address_class_type_flags_to_name): Likewise. (avr_address_class_name_to_type_flags): Likewise. (avr_gdbarch_init): Set address_class_type_flags, address_class_type_flags_to_name and address_class_name_to_type_flags. gdb/testsuite/ * gdb.arch/avr-flash-qualifer.c: New. * gdb.arch/avr-flash-qualifer.exp: New.
2014-07-15 18:03:09 +02:00
2014-07-15 Pierre Langlois <pierre.langlois@embecosm.com>
* gdb.arch/avr-flash-qualifer.c: New.
* gdb.arch/avr-flash-qualifer.exp: New.
Add missing ChangeLog entry for 15cd413a Put GDB's terminal settings into effect when paginating gdb/ 2014-07-14 Pedro Alves <palves@redhat.com> * utils.c (prompt_for_continue): Call target_terminal_ours. gdb/testsuite/ 2014-07-14 Pedro Alves <palves@redhat.com> * gdb.base/paginate-after-ctrl-c-running.c: New file. * gdb.base/paginate-after-ctrl-c-running.exp: New file.
2014-07-14 21:39:53 +02:00
2014-07-14 Pedro Alves <palves@redhat.com>
* gdb.base/paginate-after-ctrl-c-running.c: New file.
* gdb.base/paginate-after-ctrl-c-running.exp: New file.
Fix double prompt If an error is thrown while handling a target event (within fetch_inferior_event), and, the interpreter is not async (but the target is), then GDB prints the prompt twice. One way to see that in action is throw a QUIT while in a pagination prompt issued from within fetch_inferior_event (or one of its callees). E.g. from the test: ---Type <return> to continue, or q <return> to quit--- ^CQuit (gdb) (gdb) p 1 ^^^^^^^^^^^ $1 = 1 (gdb) The issue is that inferior_event_handler swallows errors and notifies the observers (the interpreters) about the command error, even if the interpreter is forced sync while we're handling a nested event loop (for execute_command). The observers print a prompt, and then when we get back to the top event loop, we print another (in start_event_loop). I see no reason the error should be swallowed here. Just cancel the execution related bits and let the error propagate to the top level (start_event_loop), which re-enables stdin and notifies observers. gdb/ 2014-07-14 Pedro Alves <palves@redhat.com> * inf-loop.c (inferior_event_handler): Use TRY_CATCH instead of catch_errors. Don't re-enable stdin or notify observers where, and rethrow error. (fetch_inferior_event_wrapper): Delete. gdb/testsuite/ 2014-07-14 Pedro Alves <palves@redhat.com> * gdb.base/double-prompt-target-event-error.c: New file. * gdb.base/double-prompt-target-event-error.exp: New file.
2014-07-14 20:55:32 +02:00
2014-07-14 Pedro Alves <palves@redhat.com>
* gdb.base/double-prompt-target-event-error.c: New file.
* gdb.base/double-prompt-target-event-error.exp: New file.
Remove the target from the event loop while in secondary prompts If a pagination prompt triggers while the target is running, and the target exits before the user responded to the pagination query, this happens: Starting program: foo ---Type <return> to continue, or q <return> to quit---No unwaited-for children left. Couldn't get registers: No such process. Couldn't get registers: No such process. Couldn't get registers: No such process. (gdb) Couldn't get registers: No such process. (gdb) To reiterate, the user hasn't replied to the pagination prompt above. A pagination query nests an event loop (in gdb_readline_wrapper). In async mode, in addition to stdin and signal handlers, we'll have the target also installed in the event loop still. So if the target reports an event, that wakes up the nested event loop, which calls into fetch_inferior_event etc. to handle the event which generates further output, all while we should be waiting for pagination confirmation... (TBC, any target event that generates output ends up spuriously waking up the pagination, though exits seem to be the worse kind.) I've played with a couple different approaches to fixing this, while at the same time trying to avoid being invasive. Both revolve around not listening to target events while in a pagination prompt (doing anything else I think would be a much bigger change). The approach taken just removes the target from the event loop while within gdb_readline_wrapper. The other approach used gdb_select directly, with only input_fd installed, but that had the issue that it didn't handle the async signal handlers, and turned out to be a bit more code than the first version. gdb/ 2014-07-14 Pedro Alves <palves@redhat.com> PR gdb/17072 * top.c: Include "inf-loop.h". (struct gdb_readline_wrapper_cleanup) <target_is_async_orig>: New field. (gdb_readline_wrapper_cleanup): Make the target async again, if it was async before. (gdb_readline_wrapper): Store whether the target is async, and make it sync. gdb/testsuite/ 2014-07-14 Pedro Alves <palves@redhat.com> PR gdb/17072 * gdb.base/paginate-inferior-exit.c: New file. * gdb.base/paginate-inferior-exit.exp: New file.
2014-07-14 20:55:32 +02:00
2014-07-14 Pedro Alves <palves@redhat.com>
PR gdb/17072
* gdb.base/paginate-inferior-exit.c: New file.
* gdb.base/paginate-inferior-exit.exp: New file.
Background execution + pagination aborts readline/gdb If pagination occurs as result of output sent as response to a target event while the target is executing in the background, subsequent input aborts readline/gdb: $ gdb program ... (gdb) continue& Continuing. (gdb) ---Type <return> to continue, or q <return> to quit--- *return* ---Type <return> to continue, or q <return> to quit--- Breakpoint 2, after_sleep () at paginate-bg-execution.c:21 ---Type <return> to continue, or q <return> to quit--- 21 return; /* after sleep */ p 1 readline: readline_callback_read_char() called with no handler! *abort/SIGABRT* $ gdb_readline_wrapper_line removes the handler after a line is processed. Usually, we'll end up re-displaying the prompt, and that reinstalls the handler. But if the output is coming out of handling a stop event, we don't re-display the prompt, and nothing restores the handler. So the next input wakes up the event loop and calls into readline, which aborts. We should do better with the prompt handling while the target is running (I think we should coordinate with readline, and hide/redisplay it around output), but that's a more invasive change better done post 7.8, so this patch is conservative and just reinstalls the handler as soon as we're out of the readline line callback. gdb/ 2014-07-14 Pedro Alves <palves@redhat.com> PR gdb/17072 * top.c (gdb_readline_wrapper_line): Tweak comment. (gdb_readline_wrapper_cleanup): If readline is enabled, reinstall the input handler callback. gdb/testsuite/ 2014-07-14 Pedro Alves <palves@redhat.com> PR gdb/17072 * gdb.base/paginate-bg-execution.c: New file. * gdb.base/paginate-bg-execution.exp: New file.
2014-07-14 20:55:32 +02:00
2014-07-14 Pedro Alves <palves@redhat.com>
PR gdb/17072
* gdb.base/paginate-bg-execution.c: New file.
* gdb.base/paginate-bg-execution.exp: New file.
Canceling pagination caused by execution command from command line aborts readline/gdb This fixes: $ ./gdb program -ex "set height 2" -ex "start" ... Reading symbols from /home/pedro/gdb/tests/threads...done. ---Type <return> to continue, or q <return> to quit---^CQuit << ctrl-c triggers a Quit *type something* readline: readline_callback_read_char() called with no handler! Aborted $ Usually, if an error propagates all the way to the top level, we'll re-enable stdin, in case the command that was running was a synchronous command. That's done in the event loop's actual loop (event-loop.c:start_event_loop). However, if a foreground execution command is run before the event loop starts and throws, nothing is presently reenabling stdin, which leaves sync_execution set. When we do start the event loop, because sync_execution is still (mistakenly) set, display_gdb_prompt removes the readline input callback, even though stdin is registered in the event loop. Any input from here on results in readline aborting. Such commands are run through catch_command_errors, catch_command_errors_const, so add the tweak there. gdb/ 2014-07-14 Pedro Alves <palves@redhat.com> PR gdb/17072 * main.c: Include event-top.h. (handle_command_errors): New function. (catch_command_errors, catch_command_errors_const): Use it. gdb/testsuite/ 2014-07-14 Pedro Alves <palves@redhat.com> PR gdb/17072 * gdb.base/paginate-execution-startup.c: New file. * gdb.base/paginate-execution-startup.exp: New file. * lib/gdb.exp (pagination_prompt): New global. (default_gdb_spawn): New procedure, factored out from default_gdb_spawn. (default_gdb_start): Adjust to call default_gdb_spawn. (gdb_spawn): New procedure.
2014-07-14 20:55:31 +02:00
2014-07-14 Pedro Alves <palves@redhat.com>
PR gdb/17072
* gdb.base/paginate-execution-startup.c: New file.
* gdb.base/paginate-execution-startup.exp: New file.
* lib/gdb.exp (pagination_prompt): New global.
(default_gdb_spawn): New procedure, factored out from
default_gdb_spawn.
(default_gdb_start): Adjust to call default_gdb_spawn.
(gdb_spawn): New procedure.
testsuite: Introduce gdb_assert Often we'll do something like: if {$ok} { fail "whatever" } else { pass "whatever" } This adds a helper procedure for that, and converts one random place to use it, as an example. 2014-07-14 Pedro Alves <palves@redhat.com> * lib/gdb.exp (gdb_assert): New procedure. * gdb.trace/backtrace.exp (gdb_backtrace_tdp_4): Use it.
2014-07-14 20:55:31 +02:00
2014-07-14 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_assert): New procedure.
* gdb.trace/backtrace.exp (gdb_backtrace_tdp_4): Use it.
Put the inferior's terminal settings in effect while running (fg) infcalls The "call" and "print" commands presently always run synchronously, in the foreground, but GDB currently forgets to put the inferior's terminal settings into effect while running them, on async-capable targets, resulting in: (gdb) print func () hello world Program received signal SIGTTOU, Stopped (tty output). 0x000000373bceb8d0 in __libc_tcdrain (fd=1) at ../sysdeps/unix/sysv/linux/tcdrain.c:29 29 return INLINE_SYSCALL (ioctl, 3, fd, TCSBRK, 1); The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on". Evaluation of the expression containing the function (func) will be abandoned. When the function is done executing, GDB will silently stop. (gdb) That's because target_terminal_inferior skips actually doing anything if running in the background, and, nothing is setting sync_execution while running infcalls: void target_terminal_inferior (void) { /* A background resume (``run&'') should leave GDB in control of the terminal. Use target_can_async_p, not target_is_async_p, since at this point the target is not async yet. However, if sync_execution is not set, we know it will become async prior to resume. */ if (target_can_async_p () && !sync_execution) return; This would best be all cleaned up by making GDB not even call target_terminal_inferior and try to pass the terminal to the inferior if running in the background, but that's a more invasive fix that is better done post-7.8. This was originally caught by a patch later in this series that makes catch_command_errors use exception_print instead of print_any_exception. Note that print_flush calls serial_drain_output while print_any_exception doesnt't have that bit. And, gdb.gdb/python-selftest.exp does: gdb_test "call catch_command_errors(execute_command, \"python print 5\", 0, RETURN_MASK_ALL)" \ "Python not initialized.* = 0" which without this fix results in SIGTTOU... gdb/ 2014-07-14 Pedro Alves <palves@redhat.com> * infcall.c (run_inferior_call): Set 'sync_execution' while running the inferior call. gdb/testsuite/ 2014-07-14 Pedro Alves <palves@redhat.com> * gdb.base/execution-termios.c: New file. * gdb.base/execution-termios.exp: New file.
2014-07-14 20:55:30 +02:00
2014-07-14 Pedro Alves <palves@redhat.com>
* gdb.base/execution-termios.c: New file.
* gdb.base/execution-termios.exp: New file.
fix PR 17106 This fixes PR 17106, a regression in printing. The bug is that resolve_dynamic_type follows struct members and references, but doesn't consider the possibility of infinite recursion. This patch fixes the problem by limiting reference following to the topmost layer of calls -- that is, reference-typed struct members are never considered as being VLAs. Built and regtested on x86-64 Fedora 20. New test case included. 2014-07-14 Tom Tromey <tromey@redhat.com> PR exp/17106: * gdbtypes.c (is_dynamic_type_internal): New function, from is_dynamic_type. (is_dynamic_type): Rewrite. (resolve_dynamic_union): Use resolve_dynamic_type_internal. (resolve_dynamic_struct): Likewise. (resolve_dynamic_type_internal): New function, from resolve_dynamic_type. (resolve_dynamic_type): Rewrite. 2014-07-14 Tom Tromey <tromey@redhat.com> * gdb.cp/vla-cxx.cc: New file. * gdb.cp/vla-cxx.exp: New file.
2014-07-02 23:53:31 +02:00
2014-07-14 Tom Tromey <tromey@redhat.com>
* gdb.cp/vla-cxx.cc: New file.
* gdb.cp/vla-cxx.exp: New file.
fix record "run" regression This fixes the record "run" regression pointed out by Marc Khouzam: https://sourceware.org/ml/gdb/2014-06/msg00096.html The bug is that target_require_runnable must agree with the handling of the "run" target, but currently it is out of sync. This patch fixes the problem by changing target_require_runnable to also ignore the record_stratum. Built and regtested on x86-64 Fedora 20. New test case included. 2014-07-14 Tom Tromey <tromey@redhat.com> * target.c (target_require_runnable): Also check record_stratum. Update comment. 2014-07-14 Tom Tromey <tromey@redhat.com> * gdb.reverse/rerun-prec.c: New file. * gdb.reverse/rerun-prec.exp: New file.
2014-07-01 19:43:00 +02:00
2014-07-14 Tom Tromey <tromey@redhat.com>
* gdb.reverse/rerun-prec.c: New file.
* gdb.reverse/rerun-prec.exp: New file.
gdb/testsuite: Add a way to send multiple init commands Right now we provide a board info entry, `gdb_init_command', that allows one to send a single command to GDB before the program to be debugged is started. This is useful e.g. for slow remote targets to change the default "remotetimeout" setting. Occasionally I found a need to send multiple commands instead, however this cannot be achieved with `gdb_init_command'. This change therefore extends the mechanism by adding a TCL list of GDB commands to send, via a board info entry called `gdb_init_commands'. There is no limit as to the number of commands put there. The old `gdb_init_command' mechanism remains supported for compatibility with existing people's environments. * lib/gdb-utils.exp: New file. * lib/gdb.exp (gdb_run_cmd): Call gdb_init_commands, replacing inline `gdb_init_command' processing. (gdb_start_cmd): Likewise. * lib/mi-support.exp (mi_run_cmd): Likewise. * README: Document `gdb_init_command' and `gdb_init_commands'.
2014-07-12 02:22:25 +02:00
2014-07-12 Maciej W. Rozycki <macro@mips.com>
Maciej W. Rozycki <macro@codesourcery.com>
* lib/gdb-utils.exp: New file.
* lib/gdb.exp (gdb_run_cmd): Call gdb_init_commands, replacing
inline `gdb_init_command' processing.
(gdb_start_cmd): Likewise.
* lib/mi-support.exp (mi_run_cmd): Likewise.
* README: Document `gdb_init_command' and `gdb_init_commands'.
Fix false argv0-symlink.exp FAIL running under a very long directory name Starting program: /home/jkratoch/redhat/gdb-test-fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff/gdb/testsuite/gdb.base/argv0-symlink-filelink ^M [...] (gdb) print argv[0]^M $1 = 0x7fffffffda39 "/home/jkratoch/redhat/gdb-test-", 'f' <repeats 169 times>...^M (gdb) FAIL: gdb.base/argv0-symlink.exp: kept file symbolic link name after "set print repeats 10000": print argv[0]^M $1 = 0x7fffffffda39 "/home/jkratoch/redhat/gdb-test-fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"...^M (gdb) FAIL: gdb.base/argv0-symlink.exp: kept file symbolic link name after "set print elements 10000": print argv[0]^M $1 = 0x7fffffffda39 "/home/jkratoch/redhat/gdb-test-fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff/gdb/testsuite/gdb.base/argv0-symlink-filelink"^M (gdb) PASS: gdb.base/argv0-symlink.exp: kept file symbolic link name gdb/testsuite/ 2014-07-11 Jan Kratochvil <jan.kratochvil@redhat.com> Fix false FAIL running under a very long directory name. * gdb.base/argv0-symlink.exp: Add "set print repeats 10000" and "set print elements 10000". Twice.
2014-07-11 17:26:42 +02:00
2014-07-11 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix false FAIL running under a very long directory name.
* gdb.base/argv0-symlink.exp: Add "set print repeats 10000"
and "set print elements 10000". Twice.
Don't print symbol on address 0x0 We see the following fails on arm-none-eabi target, print (void*)v_signed_char^M $190 = (void *) 0x0 <_ftext>^M (gdb) FAIL: gdb.base/exprs.exp: print (void*)v_signed_char (print (void*)v_signed_char) GDB behaves correctly but the test assumes there is no symbol on address 0x0. This patch is set print symbol off, so that tests below can match the address only. gdb/testsuite: 2014-07-11 Yao Qi <yao@codesourcery.com> * gdb.base/exprs.exp: "set print symbol off".
2014-07-11 12:46:33 +02:00
2014-07-11 Yao Qi <yao@codesourcery.com>
* gdb.base/exprs.exp: "set print symbol off".
GDBserver crashes when killing a multi-thread process Here's an example, with the new test: gdbserver :9999 gdb.threads/kill gdb gdb.threads/kill (gdb) b 52 Breakpoint 1 at 0x4007f4: file kill.c, line 52. Continuing. Breakpoint 1, main () at kill.c:52 52 return 0; /* set break here */ (gdb) k Kill the program being debugged? (y or n) y gdbserver :9999 gdb.threads/kill Process gdb.base/watch_thread_num created; pid = 9719 Listening on port 1234 Remote debugging from host 127.0.0.1 Killing all inferiors Segmentation fault (core dumped) Backtrace: (gdb) bt #0 0x00000000004068a0 in find_inferior (list=0x66b060 <all_threads>, func=0x427637 <kill_one_lwp_callback>, arg=0x7fffffffd3fc) at src/gdb/gdbserver/inferiors.c:199 #1 0x00000000004277b6 in linux_kill (pid=15708) at src/gdb/gdbserver/linux-low.c:966 #2 0x000000000041354d in kill_inferior (pid=15708) at src/gdb/gdbserver/target.c:163 #3 0x00000000004107e9 in kill_inferior_callback (entry=0x6704f0) at src/gdb/gdbserver/server.c:2934 #4 0x0000000000406522 in for_each_inferior (list=0x66b050 <all_processes>, action=0x4107a6 <kill_inferior_callback>) at src/gdb/gdbserver/inferiors.c:57 #5 0x0000000000412377 in process_serial_event () at src/gdb/gdbserver/server.c:3767 #6 0x000000000041267c in handle_serial_event (err=0, client_data=0x0) at src/gdb/gdbserver/server.c:3880 #7 0x00000000004189ff in handle_file_event (event_file_desc=4) at src/gdb/gdbserver/event-loop.c:434 #8 0x00000000004181c6 in process_event () at src/gdb/gdbserver/event-loop.c:189 #9 0x0000000000418f45 in start_event_loop () at src/gdb/gdbserver/event-loop.c:552 #10 0x0000000000411272 in main (argc=3, argv=0x7fffffffd8d8) at src/gdb/gdbserver/server.c:3283 The problem is that linux_wait_for_event deletes lwps that have exited (even those not passed in as lwps of interest), while the lwp/thread list is being walked on with find_inferior. find_inferior can handle the current iterated inferior being deleted, but not others. When killing lwps, we don't really care about any of the pending status handling of linux_wait_for_event. We can just waitpid the lwps directly, which is also what GDB does (see linux-nat.c:kill_wait_callback). This way the lwps are not deleted while we're walking the list. They'll be deleted by linux_mourn afterwards. This crash triggers several times when running the testsuite against GDBserver with the native-gdbserver board (target remote), but as GDB can't distinguish between GDBserver crashing and "kill" being sucessful, as in both cases the connection is closed (the 'k' packet doesn't require a reply), and the inferior is gone, that results in no FAIL. The patch adds a generic test that catches the issue with extended-remote mode (and works fine with native testing too). Here's how it fails with the native-extended-gdbserver board without the fix: (gdb) info threads Id Target Id Frame 6 Thread 15367.15374 0x000000373bcbc98d in nanosleep () at ../sysdeps/unix/syscall-template.S:81 5 Thread 15367.15373 0x000000373bcbc98d in nanosleep () at ../sysdeps/unix/syscall-template.S:81 4 Thread 15367.15372 0x000000373bcbc98d in nanosleep () at ../sysdeps/unix/syscall-template.S:81 3 Thread 15367.15371 0x000000373bcbc98d in nanosleep () at ../sysdeps/unix/syscall-template.S:81 2 Thread 15367.15370 0x000000373bcbc98d in nanosleep () at ../sysdeps/unix/syscall-template.S:81 * 1 Thread 15367.15367 main () at .../gdb.threads/kill.c:52 (gdb) kill Kill the program being debugged? (y or n) y Remote connection closed ^^^^^^^^^^^^^^^^^^^^^^^^ (gdb) FAIL: gdb.threads/kill.exp: kill Extended remote should remain connected after the kill. gdb/gdbserver/ 2014-07-11 Pedro Alves <palves@redhat.com> * linux-low.c (kill_wait_lwp): New function, based on kill_one_lwp_callback, but use my_waitpid directly. (kill_one_lwp_callback, linux_kill): Use it. gdb/testsuite/ 2014-07-11 Pedro Alves <palves@redhat.com> * gdb.threads/kill.c: New file. * gdb.threads/kill.exp: New file.
2014-07-11 12:07:13 +02:00
2014-07-11 Pedro Alves <palves@redhat.com>
* gdb.threads/kill.c: New file.
* gdb.threads/kill.exp: New file.
Tweak gdb.trace/tfile.c for thumb mode We see the fail below happens on thumb related multi-libs (-mthumb -march={armv4t,armv7-a}), target tfile tfile-basic.tf ^M warning: Uploaded tracepoint 1 has no source location, using raw address^M warning: Breakpoint address adjusted from 0x00008959 to 0x00008958.^M Tracepoint 3 at 0x8958: file /scratch/yqi/arm-none-linux-gnueabi/src/gdb-trunk/gdb/testsuite/gdb.trace/tfile.c, line 91.^M Created tracepoint 3 for target's tracepoint 1 at 0x8959.^M warning: Breakpoint address adjusted from 0x00008959 to 0x00008958.^M warning: Breakpoint address adjusted from 0x00008959 to 0x00008958.^M warning: Breakpoint address adjusted from 0x00008959 to 0x00008958.^M (gdb) FAIL: gdb.trace/tfile.exp: complete-command 'target tfile' The address of write_basic_trace_file is two-bytes aligned, (gdb) p write_basic_trace_file $1 = {void (void)} 0x8958 <write_basic_trace_file> but the ld sets the LSB of every reference to the function address (indicating the address is in thumb mode), so "&write_basic_trace_file" in the program becomes 0x8959, which is saved in the trace file. That is why the warnnings are emitted. This patch is to clear the LSB of the function address written to trace file in thumb and thumb2 mode. This patch fixes the fail above. gdb/testsuite: 2014-07-10 Yao Qi <yao@codesourcery.com> * gdb.trace/tfile.c (write_basic_trace_file) [__thumb__||__thumb2__]: Clear the Thumb bit of the function address written to trace file.
2014-06-30 05:47:51 +02:00
2014-07-10 Yao Qi <yao@codesourcery.com>
* gdb.trace/tfile.c (write_basic_trace_file)
[__thumb__||__thumb2__]: Clear the Thumb bit of the function
address written to trace file.
Fix "attach" command vs user input race On async targets, a synchronous attach is done like this: #1 - target_attach is called (PTRACE_ATTACH is issued) #2 - a continuation is installed #3 - we go back to the event loop #4 - target reports stop (SIGSTOP), event loop wakes up, and attach continuation is called #5 - among other things, the continuation calls target_terminal_inferior, which removes stdin from the event loop Note that in #3, GDB is still processing user input. If the user is fast enough, e.g., with something like: echo -e "attach PID\nset xxx=1" | gdb ... then the "set" command is processed before the attach completes. We get worse behavior even, if input is a tty and therefore readline/editing is enabled, with e.g.,: (gdb) attach PID\nset xxx=1 we then crash readline/gdb, with: Attaching to program: attach-wait-input, process 14537 readline: readline_callback_read_char() called with no handler! Aborted $ Fix this by calling target_terminal_inferior before #3 above. The test covers both scenarios by running with editing/readline forced to both on and off. gdb/ 2014-07-09 Pedro Alves <palves@redhat.com> * infcmd.c (attach_command_post_wait): Don't call target_terminal_inferior here. (attach_command): Call it here instead. gdb/testsuite/ 2014-07-09 Pedro Alves <palves@redhat.com> * gdb.base/attach-wait-input.exp: New file. * gdb.base/attach-wait-input.c: New file.
2014-07-09 16:59:02 +02:00
2014-07-09 Pedro Alves <palves@redhat.com>
* gdb.base/attach-wait-input.exp: New file.
* gdb.base/attach-wait-input.c: New file.
Improve MI -var-info-path-expression for nested struct/union case. https://sourceware.org/ml/gdb-patches/2014-05/msg00383.html The MI command -var-info-path-expression currently does not handle non-anonymous structs / unions nested within other structs / unions, it will skip parts of the expression. Consider this example: ## START EXAMPLE ## $ cat ex.c #include <string.h> int main () { struct s1 { int a; }; struct ss { struct s1 x; }; struct ss an_ss; memset (&an_ss, 0, sizeof (an_ss)); return 0; } $ gcc -g -o ex.x ex.c $ gdb ex.x (gdb) break 18 Breakpoint 1 at 0x80483ba: file ex.c, line 18. (gdb) run Starting program: /home/user/ex.x Breakpoint 1, main () at ex.c:18 18 return 0; (gdb) interpreter-exec mi "-var-create an_ss * an_ss" (gdb) interpreter-exec mi "-var-list-children an_ss" ^done,numchild="1",children=[child={name="an_ss.x",exp="x",numchild="1",type="struct s1",thread-id="1"}],has_more="0" (gdb) interpreter-exec mi "-var-list-children an_ss.x" ^done,numchild="1",children=[child={name="an_ss.x.a",exp="a",numchild="0",type="int",thread-id="1"}],has_more="0" (gdb) interpreter-exec mi "-var-list-children an_ss.x.a" ^done,numchild="0",has_more="0" (gdb) interpreter-exec mi "-var-info-path-expression an_ss.x.a" ^done,path_expr="(an_ss).a" (gdb) print (an_ss).a There is no member named a. ## END EXAMPLE ## Notice that the path expression returned is wrong, and as a result the print command fails. This patch adds a new method to the varobj_ops structure called is_path_expr_parent, to allow language specific control over finding the parent varobj, the current logic becomes the C/C++ version and is extended to handle the nested cases. No other language currently uses this code, so all other languages just get a default method. With this patch, the above example now finishes like this: ## START EXAMPLE ## $ gdb ex.x (gdb) break 18 Breakpoint 1 at 0x80483ba: file ex.c, line 18. (gdb) run Starting program: /home/user/ex.x Breakpoint 1, main () at ex.c:18 18 return 0; (gdb) interpreter-exec mi "-var-list-children an_ss" ^done,numchild="1",children=[child={name="an_ss.x",exp="x",numchild="1",type="struct s1",thread-id="1"}],has_more="0" (gdb) interpreter-exec mi "-var-list-children an_ss.x" ^done,numchild="1",children=[child={name="an_ss.x.a",exp="a",numchild="0",type="int",thread-id="1"}],has_more="0" (gdb) interpreter-exec mi "-var-list-children an_ss.x.a" ^done,numchild="0",has_more="0" (gdb) interpreter-exec mi "-var-info-path-expression an_ss.x.a" ^done,path_expr="((an_ss).x).a" (gdb) print ((an_ss).x).a $1 = 0 ## END EXAMPLE ## Notice that the path expression is now correct, and the print is a success. gdb/ChangeLog: * ada-varobj.c (ada_varobj_ops): Fill in is_path_expr_parent field. * c-varobj.c (c_is_path_expr_parent): New function, moved core from varobj.c, with additional checks. (c_varobj_ops): Fill in is_path_expr_parent field. (cplus_varobj_ops): Fill in is_path_expr_parent field. * jv-varobj.c (java_varobj_ops): Fill in is_path_expr_parent field. * varobj.c (is_path_expr_parent): Call is_path_expr_parent varobj ops method. (varobj_default_is_path_expr_parent): New function. * varobj.h (lang_varobj_ops): Add is_path_expr_parent field. (varobj_default_is_path_expr_parent): Declare new function. gdb/testsuite/ChangeLog: * gdb.mi/var-cmd.c (do_nested_struct_union_tests): New function setting up test structures. (main): Call new test function. * gdb.mi/mi2-var-child.exp: Create additional breakpoint in new test function, continue into test function and walk test structures.
2014-07-07 20:22:36 +02:00
2014-07-09 Andrew Burgess <andrew.burgess@embecosm.com>
* gdb.mi/var-cmd.c (do_nested_struct_union_tests): New function
setting up test structures.
(main): Call new test function.
* gdb.mi/mi2-var-child.exp: Create additional breakpoint in new
test function, continue into test function and walk test
structures.
Fix gdb.trace/entry-values.exp for thumb mode We see some fails in gdb.trace/entry-values.exp in thumb mode (-mthumb -march={armv4t,armv7-a}). In thumb mode, the lsb of references to 'foo' and 'bar' in the assembly (produced by dwarf assember) is set, so the generated debug information is incorrect. This patch copies the approach used by [PATCH 4/4] Fix dw2-ifort-parameter.exp on PPC64 https://sourceware.org/ml/gdb-patches/2014-03/msg00202.html to introduce new labels 'foo_start' and 'bar_start' which are about the correct function address (without lsb set). This patch fixes these fails we've seen. gdb/testsuite: 2014-07-08 Yao Qi <yao@codesourcery.com> * gdb.trace/entry-values.c: Define labels 'foo_start' and 'bar_start' at the beginning of functions 'foo' and 'bar' respectively. * gdb.trace/entry-values.exp: Use 'foo_start' and 'bar_start' instead of 'foo' and 'bar'.
2014-07-01 13:30:54 +02:00
2014-07-02 Yao Qi <yao@codesourcery.com>
* gdb.trace/entry-values.c: Define labels 'foo_start' and
'bar_start' at the beginning of functions 'foo' and 'bar'
respectively.
* gdb.trace/entry-values.exp: Use 'foo_start' and 'bar_start'
instead of 'foo' and 'bar'.
reverse-finish: turn internal error into normal error The reverse-finish command results in an internal error if it cannot determine the current function. (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) reverse-finish Run back to call of #0 0x0000000000000000 in ?? () gdb/infcmd.c:1576: internal-error: Finish: couldn't find function. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) y This is not an internal error case since the command may be used in scenarios where there is no function at the current PC, e.g. after calling through a bad function pointer. Turn this into a normal error. gdb/ * infcmd.c (finish_backward): Turn internal error into normal error. testsuite/ * gdb.btrace/segv.c: New. * gdb.btrace/segv.exp: New.
2014-06-30 11:47:30 +02:00
2014-07-08 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/segv.exp: New.
* gdb.btrace/segv.c: New.
This testcase currently does not handle powerpc branches. It kinda does in a way, because the arm/aarch64 branch instruction is the same as powerpc's, but the target triplet pattern is not there. In summary, the testcase fails to locate the branch offset and causes a failure and the early termination of the test. The following patch adds a separate conditional block for powerpc (to keep things organized), allowing the testcase to continue. 2014-07-02 Luis Machado <lgustavo@codesourcery.com> * gdb.trace/entry-values.exp: Handle powerpc-specific branch instruction.
2014-07-02 12:59:02 +02:00
2014-07-02 Luis Machado <lgustavo@codesourcery.com>
* gdb.trace/entry-values.exp: Handle powerpc-specific branch
instruction.
Handle volatile array types in dwarf2read.c. read_tag_const_type propagates the cv-qualifier to the array element type, but read_tag_volatile_type didn't. Make sure that both cv-qualifiers that apply to array types are handled the same. gdb/ChangeLog * dwarf2read.c (add_array_cv_type): New function. (read_tag_const_type): Call add_array_cv_type for TYPE_CODE_ARRAY. (read_tag_volatile_type): Likewise. gdb/testsuite/ChangeLog * gdb.base/constvars.c (violent, violet, vips, virgen, vulgar, vulture, vilify, villar): New volatile array constants. (vindictive, vegetation): New const volatile array constants. * gdb.base/volatile.exp: Test volatile and const volatile array types.
2014-06-30 23:21:52 +02:00
2014-06-30 Mark Wielaard <mjw@redhat.com>
* gdb.base/constvars.c (violent, violet, vips, virgen, vulgar,
vulture, vilify, villar): New volatile array constants.
(vindictive, vegetation): New const volatile array constants.
* gdb.base/volatile.exp: Test volatile and const volatile array
types.
watchpoint-reuse-slot.exp: Correctly skip unsupported commands. The test case "watchpoint-reuse-slot.exp" yields a lot of failures on s390/s390x: all instances of awatch, rwatch, and hbreak are performed even though they aren't supported on these targets. This is because the test case ignores non-support error messages when probing for support of these commands, like: (gdb) rwatch buf.byte[0] Target does not support this type of hardware watchpoint. The patch adds handling for this case in the appropriate gdb_test_multiple invocations. gdb/testsuite/ * gdb.base/watchpoint-reuse-slot.exp: Handle the case that the target lacks support for awatch, rwatch, or hbreak.
2014-06-26 17:21:08 +02:00
2014-06-30 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.base/watchpoint-reuse-slot.exp: Handle the case that the
target lacks support for awatch, rwatch, or hbreak.
Associate dummy_frame with ptid This patch is to add ptid into dummy_frame and extend frame_id to dummy_frame_id (which has a ptid field). With this change, GDB uses dummy_frame_id (thread ptid and frame_id) to find the dummy frames. Currently, dummy frames are looked up by frame_id, which isn't accurate in non-stop or multi-process mode. The test case gdb.multi/dummy-frame-restore.exp shows the problem and this patch can fix it. Test dummy-frame-restore.exp makes two inferiors stop at different functions, say, inferior 1 stops at f1 while inferior 2 stops at f2. Set a breakpoint to a function, do the inferior call in two inferiors, and GDB has two dummy frames of the same frame_id. When the inferior call is finished, GDB will look up a dummy frame from its stack/list and restore the inferior's regcache. Two inferiors are finished in different orders, the inferiors' states are restored differently, which is wrong. Running dummy-frame-restore.exp under un-patched GDB, we'll get two fails: FAIL: gdb.multi/dummy-frame-restore.exp: inf 2 first: after infcall: bt in inferior 2 FAIL: gdb.multi/dummy-frame-restore.exp: inf 2 first: after infcall: bt in inferior 1 With this patch applied, GDB will choose the correct dummy_frame to restore for a given inferior, because ptid is considered when looking up dummy frames. Two fails above are fixed. Regression tested on x86_64-linux, both native and gdbserver. gdb: 2014-06-27 Yao Qi <yao@codesourcery.com> * breakpoint.c (check_longjmp_breakpoint_for_call_dummy): Change parameter type to 'struct thread_info *'. Caller updated. * breakpoint.h (check_longjmp_breakpoint_for_call_dummy): Update declaration. * dummy-frame.c (struct dummy_frame_id): New. (dummy_frame_id_eq): New function. (struct dummy_frame) <id>: Change its type to 'struct dummy_frame_id'. (dummy_frame_push): Add parameter ptid and save it in dummy_frame_id. (pop_dummy_frame_bpt): Use ptid of dummy_frame instead of inferior_ptid. (pop_dummy_frame): Assert that the ptid of dummy_frame equals to inferior_ptid. (lookup_dummy_frame): Change parameter type to 'struct dummy_frame_id *'. Callers updated. Call dummy_frame_id_eq instead of frame_id_eq. (dummy_frame_pop): Add parameter ptid. Callers updated. Update comments. Compose dummy_frame_id and pass it to lookup_dummy_frame. (dummy_frame_discard): Add parameter ptid. (dummy_frame_sniffer): Compose dummy_frame_id and call dummy_frame_id_eq instead of frame_id_eq. (fprint_dummy_frames): Print ptid. * dummy-frame.h: Remove comments. (dummy_frame_push): Add ptid in declaration. (dummy_frame_pop, dummy_frame_discard): Likewise. gdb/testsuite: 2014-06-27 Yao Qi <yao@codesourcery.com> * gdb.multi/dummy-frame-restore.exp: New. * gdb.multi/dummy-frame-restore.c: New. gdb/doc: 2014-06-27 Yao Qi <yao@codesourcery.com> * gdb.texinfo (Maintenance Commands): Update the output of 'maint print dummy-frames' command.
2014-06-25 05:52:52 +02:00
2014-06-27 Yao Qi <yao@codesourcery.com>
* gdb.multi/dummy-frame-restore.exp: New.
* gdb.multi/dummy-frame-restore.c: New.
btrace: pretend we're not replaying when generating a core file When generating a core file using the "generate-core-file" command while replaying with the btrace record target, we won't be able to access all registers and all memory. This leads to the following assertion: gdb/regcache.c:1034: internal-error: regcache_raw_supply: Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) FAIL: gdb.btrace/gcore.exp: generate-core-file core (GDB internal error) Resyncing due to internal error. Pretend that we are not replaying while generating a core file. This will forward fetch and store registers as well as xfer memory calls to the target beneath. gdb/ * record-btrace.c (record_btrace_generating_corefile) (record_btrace_prepare_to_generate_core) (record_btrace_done_generating_core): New. (record_btrace_xfer_partial, record_btrace_fetch_registers) (record_btrace_store_registers, record_btrace_prepare_to_store): Forward request when generating a core file. (record_btrace_open): Set record_btrace_generating_corefile to zero. (init_record_btrace_ops): Set to_prepare_to_generate_core and to_done_generating_core. testsuite/ * gdb.btrace/gcore.exp: New.
2014-05-20 15:53:44 +02:00
2014-06-25 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/gcore.exp: New.
x86 Linux watchpoints: Couldn't write debug register: Invalid argument. This patch fixes this on x86 Linux: (gdb) watch *buf@2 Hardware watchpoint 8: *buf@2 (gdb) si 0x00000000004005a7 34 for (i = 0; i < 100000; i++); /* stepi line */ (gdb) del Delete all breakpoints? (y or n) y (gdb) watch *(buf+1)@1 Hardware watchpoint 9: *(buf+1)@1 (gdb) si 0x00000000004005a7 in main () at ../../../src/gdb/testsuite/gdb.base/watchpoint-reuse-slot.c:34 34 for (i = 0; i < 100000; i++); /* stepi line */ Couldn't write debug register: Invalid argument. (gdb) In the example above the debug registers are being switched from this state: CONTROL (DR7): 0000000000050101 STATUS (DR6): 0000000000000000 DR0: addr=0x0000000000601040, ref.count=1 DR1: addr=0x0000000000000000, ref.count=0 DR2: addr=0x0000000000000000, ref.count=0 DR3: addr=0x0000000000000000, ref.count=0 to this: CONTROL (DR7): 0000000000010101 STATUS (DR6): 0000000000000000 DR0: addr=0x0000000000601041, ref.count=1 DR1: addr=0x0000000000000000, ref.count=0 DR2: addr=0x0000000000000000, ref.count=0 DR3: addr=0x0000000000000000, ref.count=0 That is, before, DR7 was setup for watching a 2 byte region starting at what's in DR0 (0x601040). And after, DR7 is setup for watching a 1 byte region starting at what's in DR0 (0x601041). We always write DR0..DR3 before DR7, because if we enable a slot's bits in DR7, you need to have already written the corresponding DR0..DR3 registers -- the kernel rejects the DR7 write with EINVAL otherwise. The error shown above is the opposite scenario. When we try to write 0x601041 to DR0, DR7's bits still indicate intent of watching a 2-byte region. That DR0/DR7 combination is invalid, because 0x601041 is unaligned. To watch two bytes, we'd have to use two slots. So the kernel errors out with EINVAL. Fix this by always first clearing DR7, then writing DR0..DR3, and then setting DR7's bits. A little optimization -- if we're disabling the last watchpoint, then we can clear DR7 just once. The changes to nat/i386-dregs.c make that easier to detect, and as bonus, they make it a little easier to make sense of DR7 in the debug logs, as we no longer need to remember we're seeing stale bits. Tested on x86_64 Fedora 20, native and GDBserver. This adds an exhaustive test that switches between many different combinations of watchpoint types and addresses and widths. gdb/ 2014-06-23 Pedro Alves <palves@redhat.com> * amd64-linux-nat.c (amd64_linux_prepare_to_resume): Clear DR_CONTROL before setting DR0..DR3. * i386-linux-nat.c (i386_linux_prepare_to_resume): Likewise. * nat/i386-dregs.c (i386_remove_aligned_watchpoint): Clear all bits of DR_CONTROL related to the debug register slot being disabled. If all slots are vacant, clear local slowdown as well, and assert DR_CONTROL is 0. gdb/gdbserver/ 2014-06-23 Pedro Alves <palves@redhat.com> * linux-x86-low.c (x86_linux_prepare_to_resume): Clear DR_CONTROL before setting DR0..DR3. gdb/testsuite/ 2014-06-23 Pedro Alves <palves@redhat.com> * gdb.base/watchpoint-reuse-slot.c: New file. * gdb.base/watchpoint-reuse-slot.exp: New file.
2014-06-23 17:44:04 +02:00
2014-06-23 Pedro Alves <palves@redhat.com>
* gdb.base/watchpoint-reuse-slot.c: New file.
* gdb.base/watchpoint-reuse-slot.exp: New file.
Align behavior of xmethod commands with that of pretty-printer commands. Currently, the xmethod commands lookup xmethod matchers in the current progspace even if the locus regular expression matches the progspace's filename. Pretty printer commands do not match the current progspace's filename. gdb/ * python/lib/gdb/command/xmethods.py (get_method_matchers_in_loci): Lookup xmethod matchers in the current progspace only if the string "progspace" matches LOCUS_RE. gdb/testsuite * gdb.python/py-xmethods.exp: Use "progspace" instead of the progspace's filename in 'info', 'enable' and 'disable' command tests.
2014-06-18 12:46:37 +02:00
2014-06-23 Siva Chandra Reddy <sivachandra@google.com>
* gdb.python/py-xmethods.exp: Use "progspace" instead of the
progspace's filename in 'info', 'enable' and 'disable' command
tests.
testsuite: Use istarget and is_lp64_target for 3 testcases. On x86_64 with -m32 or on i686 it will: Running ./gdb.arch/amd64-stap-special-operands.exp ... gdb compile failed, amd64-stap-triplet.c: Assembler messages: amd64-stap-triplet.c:35: Error: bad register name `%rbp' amd64-stap-triplet.c:38: Error: bad register name `%rsp' amd64-stap-triplet.c:40: Error: bad register name `%rbp)' amd64-stap-triplet.c:41: Error: bad register name `%rsi' amd64-stap-triplet.c:42: Error: bad register name `%rbp)' /tmp/ccjOdmpl.s:63: Error: bad register name `%rbp' 2014-06-23 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.arch/amd64-stap-special-operands.exp: Use is_lp64_target. * gdb.arch/amd64-stap-optional-prefix.exp: Likewise. * gdb.dwarf2/dw2-error.exp: Use istarget and is_lp64_target. Message-ID: <20140622211401.GA3716@host2.jankratochvil.net>
2014-06-23 08:24:36 +02:00
2014-06-23 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/amd64-stap-special-operands.exp: Use is_lp64_target.
* gdb.arch/amd64-stap-optional-prefix.exp: Likewise.
* gdb.dwarf2/dw2-error.exp: Use istarget and is_lp64_target.
Move shared native target specific code to gdb/nat https://sourceware.org/gdb/wiki/Common describes the following directory structure: gdb/nat/ Native target backend files. Code that interfaces with the host debug API. E.g., ptrace code, Windows debug API code, procfs code should go here. gdb/target/ Host-independent, target vector specific code (target_ops). gdb/common/ All other shared code. This commit moves all native target backend files currently in gdb/common to gdb/nat. gdb/ 2014-06-20 Gary Benson <gbenson@redhat.com> * common/gdb_thread_db.h: Moved to nat. All includes updated. * common/glibc_thread_db.h: Likewise. * common/i386-cpuid.h: Likewise. * common/i386-gcc-cpuid.h: Likewise. * common/linux-btrace.h: Likewise. * common/linux-osdata.h: Likewise. * common/linux-procfs.h: Likewise. * common/linux-ptrace.h: Likewise. * common/mips-linux-watch.h: Likewise. * common/linux-btrace.c: Moved to nat. * common/linux-osdata.c: Likewise. * common/linux-procfs.c: Likewise. * common/linux-ptrace.c: Likewise. * common/mips-linux-watch.c: Likewise. * nat/gdb_thread_db.h: Moved from common. * nat/glibc_thread_db.h: Likewise. * nat/i386-cpuid.h: Likewise. * nat/i386-gcc-cpuid.h: Likewise. * nat/linux-btrace.c: Likewise. * nat/linux-btrace.h: Likewise. * nat/linux-osdata.c: Likewise. * nat/linux-osdata.h: Likewise. * nat/linux-procfs.c: Likewise. * nat/linux-procfs.h: Likewise. * nat/linux-ptrace.c: Likewise. * nat/linux-ptrace.h: Likewise. * nat/mips-linux-watch.c: Likewise. * nat/mips-linux-watch.h: Likewise. * Makefile.in (HFILES_NO_SRCDIR): Reflect new locations. (object file files): Reordered. * gdb/copyright.py (EXCLUDE_LIST): Reflect new location of glibc_thread_db.h. gdb/gdbserver/ 2014-06-20 Gary Benson <gbenson@redhat.com> * Makefile.in (SFILES): Update locations for files moved from common to nat. (object file files): Reordered. gdb/testsuite/ 2014-06-20 Gary Benson <gbenson@redhat.com> * gdb.arch/i386-avx.exp: Fix include file location. * gdb.arch/i386-sse.exp: Likewise.
2014-06-19 15:46:38 +02:00
2014-06-20 Gary Benson <gbenson@redhat.com>
* gdb.arch/i386-avx.exp: Fix include file location.
* gdb.arch/i386-sse.exp: Likewise.
Initial pass at D language expression parser support. gdb/ 2014-06-05 Iain Buclaw <ibuclaw@gdcproject.org> * Makefile.in (SFILES): Add d-exp.y. (YYFILES): Add d-exp.c. (YYOBJ): Add d-exp.o. (local-maintainer-clean): Delete d-exp.c. * d-exp.y: New file. * d-lang.h (d_parse): New declaration. (d_error): New declaration. * d-lang.c (d_op_print_tab): Add entry for BINOP_CONCAT and BINOP_EXP. Set BINOP_EQUAL and BINOP_NOTEQUAL to same precedence as other PREC_ORDER operators. (d_language_defn): Use d_parse, d_error instead of c_parse, c_error. gdb/testsuite/ 2014-06-05 Iain Buclaw <ibuclaw@gdcproject.org> * gdb.dlang/expression.exp: New file.
2014-06-19 20:29:26 +02:00
2014-06-19 Iain Buclaw <ibuclaw@gdcproject.org>
* gdb.dlang/expression.exp: New file.
Fix next over threaded execl with "set scheduler-locking step". Running gdb.threads/thread-execl.exp with scheduler-locking set to "step" reveals a problem: (gdb) next^M [Thread 0x7ffff7fda700 (LWP 27168) exited]^M [New LWP 27168]^M [Thread 0x7ffff74ee700 (LWP 27174) exited]^M process 27168 is executing new program: /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.threads/thread-execl^M [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib64/libthread_db.so.1".^M infrun.c:5225: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed.^M A problem internal to GDB has been detected,^M further debugging may prove unreliable.^M Quit this debugging session? (y or n) FAIL: gdb.threads/thread-execl.exp: schedlock step: get to main in new image (GDB internal error) The assertion is correct. The issue is that GDB is mistakenly trying to switch back to an exited thread, that was previously stepping when it exited. This is exactly the sort of thing the test wants to make sure doesn't happen: # Now set a breakpoint at `main', and step over the execl call. The # breakpoint at main should be reached. GDB should not try to revert # back to the old thread from the old image and resume stepping it We don't see this bug with schedlock off only because a different sequence of events makes GDB manage to delete the thread instead of marking it exited. This particular internal error can be fixed by making the loop over all threads in switch_back_to_stepped_thread skip exited threads. But, looking over other ALL_THREADS users, all either can or should be skipping exited threads too. So for simplicity, this patch replaces ALL_THREADS with a new macro that skips exited threads itself, and updates everything to use it. Tested on x86_64 Fedora 20. gdb/ 2014-06-19 Pedro Alves <palves@redhat.com> * gdbthread.h (ALL_THREADS): Delete. (ALL_NON_EXITED_THREADS): New macro. * btrace.c (btrace_free_objfile): Use ALL_NON_EXITED_THREADS instead of ALL_THREADS. * infrun.c (find_thread_needs_step_over) (switch_back_to_stepped_thread): Use ALL_NON_EXITED_THREADS instead of ALL_THREADS. * record-btrace.c (record_btrace_open) (record_btrace_stop_recording, record_btrace_close) (record_btrace_is_replaying, record_btrace_resume) (record_btrace_find_thread_to_move, record_btrace_wait): Likewise. * remote.c (append_pending_thread_resumptions): Likewise. * thread.c (thread_apply_all_command): Likewise. gdb/testsuite/ 2014-06-19 Pedro Alves <palves@redhat.com> * gdb.threads/thread-execl.exp (do_test): New procedure, factored out from ... (top level): ... here. Iterate running tests under different scheduler-locking settings.
2014-06-19 12:59:03 +02:00
2014-06-19 Pedro Alves <palves@redhat.com>
* gdb.threads/thread-execl.exp (do_test): New procedure, factored
out from ...
(top level): ... here. Iterate running tests under different
scheduler-locking settings.
The testcase was generating DW_AT_high_pc and DW_AT_low_pc entries with type DW_FORM_string, which is wrong. GDB was using that information to load data as strings, and then proceeded to use the string pointers as addresses. Even then, the test was passing just fine, because we were lucky enough to have the low_pc string pointer smaller than the high_pc string pointer. Two issues are fixed. The first one is the DW_FORM_string type. The second one is adjusting the addresses so that they are non-zero, since GDB doesn't like seeing 0 in these fields due to a check contained in dwarf2_get_pc_bounds: if (low == 0 && !dwarf2_per_objfile->has_section_at_zero) return 0; With both fixes, the testcase passes deterministically. 2014-06-19 Luis Machado <lgustavo@codesourcery.com> * gdb.cp/nsalias.exp: Set type of low_pc and high_pc entries to DW_FORM_addr and use non-zero addresses.
2014-06-19 08:07:48 +02:00
2014-06-18 Luis Machado <lgustavo@codesourcery.com>
* gdb.cp/nsalias.exp: Set type of low_pc and high_pc entries
to DW_FORM_addr and use non-zero addresses.
Make xmethods tests not to depend on inferior IO. gdb/testsuite/ PR gdb/17017 * gdb.python/py-xmethods.cc: Add global function call counters and increment them in their respective functions. Remove "cout" statements. * gdb.python/py-xmethods.exp: Make tests check the global function call counters instead of depending on inferior IO.
2014-06-05 16:03:56 +02:00
2014-06-18 Siva Chandra Reddy <sivachandra@google.com>
PR gdb/17017
* gdb.python/py-xmethods.cc: Add global function call counters and
increment them in their respective functions. Remove "cout"
statements.
* gdb.python/py-xmethods.exp: Make tests check the global function
call counters instead of depending on inferior IO.
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. Along with the fix above, the coverage of the follow-fork test gdb.base/foll-fork.exp was expanded to: 1) cover all the combinations of values for follow-fork-mode and detach-on-fork 2) make sure that both user breakpoints and single-step breakpoints are propagated correctly to the child 3) check that the inferior list has the expected contents after following the fork. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * gdb.base/foll-fork.exp (default_fork_parent_follow): Deleted procedure. (explicit_fork_parent_follow): Deleted procedure. (explicit_fork_child_follow): Deleted procedure. (test_follow_fork): New procedure. (do_fork_tests): Replace calls to deleted procedures with calls to test_follow_fork and reset GDB for subsequent procedure calls.
2014-06-18 11:25:47 +02:00
2014-06-18 Don Breazeal <donb@codesourcery.com>
* gdb.base/foll-fork.exp (default_fork_parent_follow):
Deleted procedure.
(explicit_fork_parent_follow): Deleted procedure.
(explicit_fork_child_follow): Deleted procedure.
(test_follow_fork): New procedure.
(do_fork_tests): Replace calls to deleted procedures with
calls to test_follow_fork and reset GDB for subsequent
procedure calls.
Different outputs affected by hosts We find the following fails in gdb test on mingw host. FAIL: gdb.base/wchar.exp: print repeat FAIL: gdb.base/wchar.exp: print repeat_p FAIL: gdb.base/wchar.exp: print repeat (print null on) FAIL: gdb.base/wchar.exp: print repeat (print elements 3) FAIL: gdb.base/wchar.exp: print repeat_p (print elements 3) print repeat^M $7 = L"A", '¢' <repeats 21 times>, "B", '\000' <repeats 104 times>^M (gdb) FAIL: gdb.base/wchar.exp: print repeat the \242 is expected in the test but cent sign is displayed. In valprint.c:print_wchar, wchar_printable is called to determine whether a wchar is printable. wchar_printable calls iswprint but the iswprint's return value depends on LC_CTYPE setting of locale [1, 2]. The output may vary with different locale settings and OS. IMO, '¢' (cent sign) is a correct output on Windows. [1] http://pubs.opengroup.org/onlinepubs/009604499/functions/iswprint.html [2] http://msdn.microsoft.com/en-us/library/ewx8s4kw.aspx This patch is set $cent to cent sign if the GDB is running on a Windows host. gdb/testsuite: 2014-06-17 Yao Qi <yao@codesourcery.com> * gdb.base/wchar.exp: Set $cent to \u00A2 if "host-charset" is CP1252.
2014-05-27 13:56:21 +02:00
2014-06-17 Yao Qi <yao@codesourcery.com>
* gdb.base/wchar.exp: Set $cent to \u00A2 if "host-charset" is
CP1252.
In a couple functions (type_update_when_use_rtti_test and skip_type_update_when_not_use_rtti_test) the testcase assumes an uninitialized object has a specific type. In particular, 'ptr' and 's'. In reality the compiler is free to do what it wants with that uninitialized variable, even initialize it beforehand with the future assignment's value. This is exactly what happens on some targets. ptr should have type 'Base *', but it really has type 'Derived *' because it is already initialized (earlier) by the compiler. The same thing happens to 's'. The following patch addresses this by explicitly initializing those variables so the compiler doesn't optimize their assignments and GDB can print their correct values. 2014-06-17 Luis Machado <lgustavo@codesourcery.com> * gdb.mi/mi-var-rtti.cc (type_update_when_use_rtti_test): Initialize ptr and S explicitly. (skip_type_update_when_not_use_rtti_test): Likewise.
2014-06-17 11:42:23 +02:00
2014-06-17 Luis Machado <lgustavo@codesourcery.com>
* gdb.mi/mi-var-rtti.cc (type_update_when_use_rtti_test):
Initialize ptr and S explicitly.
(skip_type_update_when_not_use_rtti_test): Likewise.
Fix for PR mi/15863 If an MI client creates a varobj and attempts to update the root /before/ the inferior is started, gdb will throw an internal error: (gdb) -var-create * - batch_flag ^done,name="var1",numchild="0",value="0",type="int",has_more="0" (gdb) -var-update var1 ^done,changelist=[] (gdb) -var-update * ~"../../src/gdb/thread.c:628: internal-error: is_thread_state: Assertion `tp' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? " ~"(y or n) " The function that handles the varobj update in the failing case, mi_cmd_var_udpate_iter, checks if the thread/inferior is stopped before attempting to update the varobj. It calls is_stopped (inferior_ptid) which calls is_thread_state: tp = find_thread_ptid (ptid); gdb_assert (tp); When there is no inferior, ptid is null_ptid, and find_thread_ptid (null_ptid) returns NULL and the assertion is triggered. This patch changes mi_cmd_var_update_iter to behave the same way "-var-update var1" does: by calling the thread "stopped" if there is no inferior (and thereby calling varobj_update_one). ChangeLog 2014-06-16 Keith Seitz <keiths@redhat.com> PR mi/15863 * mi/mi-cmd-var.c (mi_cmd_var_update_iter): Do not attempt to update the varobj if inferior_ptid is null_ptid. testsuite/ChangeLog 2014-06-16 Keith Seitz <keiths@redhat.com> PR mi/15863 * gdb.mi/mi-var-cmd.exp: Add test for -var-update before the inferior is started.
2014-06-11 22:26:50 +02:00
2014-06-16 Keith Seitz <keiths@redhat.com>
PR mi/15863
* gdb.mi/mi-var-cmd.exp: Add test for -var-update before
the inferior is started.
"$ gdb PROGRAM" vs "(gdb) file PROGRAM" difference; warn on failure to remove breakpoint. Turns out there's a difference between loading the program with "gdb PROGRAM", vs loading it with "(gdb) file PROGRAM". The latter results in the objfile ending up with OBJF_USERLOADED set, while not with the former. (That difference seems bogus, but still that's not the point of this patch. We can revisit that afterwards.) The new code that suppresses breakpoint removal errors for add-symbol-file objects ends up being too greedy: /* In some cases, we might not be able to remove a breakpoint in a shared library that has already been removed, but we have not yet processed the shlib unload event. Similarly for an unloaded add-symbol-file object - the user might not yet have had the chance to remove-symbol-file it. shlib_disabled will be set if the library/object has already been removed, but the breakpoint hasn't been uninserted yet, e.g., after "nosharedlibrary" or "remove-symbol-file" with breakpoints always-inserted mode. */ if (val && (bl->loc_type == bp_loc_software_breakpoint && (bl->shlib_disabled || solib_name_from_address (bl->pspace, bl->address) || userloaded_objfile_contains_address_p (bl->pspace, bl->address)))) val = 0; as it turns out that OBJF_USERLOADED can be set for objfiles loaded by some other means not add-symbol-file. In this case, symbol-file (or "file", which is really just "exec-file"+"symbol-file"). Recall that add-symbol-file is documented as: (gdb) help add-symbol-file Load symbols from FILE, assuming FILE has been dynamically loaded. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ And it's the "dynamically loaded" aspect that the breakpoint.c code cares about. So make add-symbol-file set OBJF_SHARED on its objfiles too, and tweak the breakpoint.c code to look for OBJF_SHARED instead of OBJF_USERLOADED. This restores back the missing breakpoint removal warning when we let sss-bp-on-user-bp-2.exp run on native GNU/Linux (https://sourceware.org/ml/gdb-patches/2014-06/msg00335.html): (gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: define stepi_del_break stepi_del_break warning: Error removing breakpoint 3 (gdb) FAIL: gdb.base/sss-bp-on-user-bp-2.exp: stepi_del_break I say "restores" because this was GDB's behavior in 7.7 and earlier. And, likewise, "file" with no arguments only started turning breakpoints set in the main executable to "<pending>" with the remote-symbol-file patch (63644780). The old behavior is now restored, and we break-unload-file.exp test now exercizes both "gdb; file PROGRAM" and "gdb PROGRAM". gdb/ 2014-06-16 Pedro Alves <palves@redhat.com> * breakpoint.c (insert_bp_location, remove_breakpoint_1): Adjust. (disable_breakpoints_in_freed_objfile): Skip objfiles that don't have OBJF_SHARED set. * objfiles.c (userloaded_objfile_contains_address_p): Rename to... (shared_objfile_contains_address_p): ... this. Check OBJF_SHARED instead of OBJF_USERLOADED. * objfiles.h (OBJF_SHARED): Update comment. (userloaded_objfile_contains_address_p): Rename to ... (shared_objfile_contains_address_p): ... this, and update comments. * symfile.c (add_symbol_file_command): Also set OBJF_SHARED in the new objfile. (remove_symbol_file_command): Skip objfiles that don't have OBJF_SHARED set. gdb/testsuite/ 2014-06-16 Pedro Alves <palves@redhat.com> * gdb.base/break-main-file-remove-fail.c: New file. * gdb.base/break-main-file-remove-fail.exp: New file. * gdb.base/break-unload-file.exp: Use build_executable instead of prepare_for_testing. (test_break): New parameter "initial_load". Handle it. (top level): Add initial_load cmdline/file axis.
2014-06-16 16:38:13 +02:00
2014-06-16 Pedro Alves <palves@redhat.com>
* gdb.base/break-main-file-remove-fail.c: New file.
* gdb.base/break-main-file-remove-fail.exp: New file.
* gdb.base/break-unload-file.exp: Use build_executable instead of
prepare_for_testing.
(test_break): New parameter "initial_load". Handle it.
(top level): Add initial_load cmdline/file axis.
don't use directory in test name I noticed that a few tests in completion.exp put the directory name into the name of the resulting test. While the directory name is relative, this still makes for spurious differences depending on whether the test was run in serial or parallel mode. This patch fixes the problem. I'm checking it in. 2014-06-12 Tom Tromey <tromey@redhat.com> * gdb.base/completion.exp: Don't use directory name in test.
2014-06-12 20:04:54 +02:00
2014-06-12 Tom Tromey <tromey@redhat.com>
* gdb.base/completion.exp: Don't use directory name in test.
Separate out ANSI-standard signals This commit reorders various pieces of code to separate ANSI-standard signals from other signals that need checking. Comments are added to document this, and to document the ordering of the signals. gdb/ 2014-06-09 Gary Benson <gbenson@redhat.com> * common/signals.c (gdb_signal_from_host): Reorder to separate the always-available ANSI-standard signals from the signals that require checking. (do_gdb_signal_to_host): Likewise. * proc-events.c (signal_table): Likewise. gdb/testsuite/ 2014-06-09 Gary Benson <gbenson@redhat.com> * gdb.base/sigall.c [Functions to send signals]: Reorder to separate the always-available ANSI-standard signals from the signals that require checking. (main): Likewise. * gdb.reverse/sigall-reverse.c [Functions to send signals]: Likewise. (main): Likewise.
2014-06-09 11:34:33 +02:00
2014-06-09 Gary Benson <gbenson@redhat.com>
* gdb.base/sigall.c [Functions to send signals]: Reorder to
separate the always-available ANSI-standard signals from the
signals that require checking.
(main): Likewise.
* gdb.reverse/sigall-reverse.c [Functions to send signals]:
Likewise.
(main): Likewise.
Revert patchset for c++/16253: it causes a large performance regression. See the bug for further information.
2014-06-07 19:40:39 +02:00
2014-06-07 Keith Seitz <keiths@redhat.com>
Revert:
PR c++/16253
* gdb.cp/var-tag.cc: New file.
* gdb.cp/var-tag.exp: New file.
* gdb.dwarf2/dw2-ada-ffffffff.exp: Set the language to C++.
* gdb.dwarf2/dw2-anon-mptr.exp: Likewise.
* gdb.dwarf2/dw2-double-set-die-type.exp: Likewise.
* gdb.dwarf2/dw2-inheritance.exp: Likewise.
fix email address of previous checkins
2014-06-07 01:08:54 +02:00
2014-06-06 Doug Evans <xdje42@gmail.com>
* gdb.guile/scm-frame-args.c (foo): Tweak to work with gcc 4.6.3.
2014-06-07 00:41:09 +02:00
* gdb.guile/scm-frame-args.c (foo): Tweak to work with gcc 4.6.3.
sss-bp-on-user-bp-2.exp sometimes fails on native GNU/Linux. I noticed that sss-bp-on-user-bp-2.exp is racy on native GNU/Linux. I sometimes still see an int3 in the disassembly: (gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: set debug target 0 disassemble test Dump of assembler code for function test: 0x0000000000400590 <+0>: push %rbp 0x0000000000400591 <+1>: mov %rsp,%rbp 0x0000000000400594 <+4>: nop => 0x0000000000400595 <+5>: int3 0x0000000000400596 <+6>: pop %rbp 0x0000000000400597 <+7>: retq End of assembler dump. (gdb) FAIL: gdb.base/sss-bp-on-user-bp-2.exp: before/after disassembly matches Enabling infrun/target debug logs, we can see the problem. Simplified, that's: (gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: define stepi_del_break stepi_del_break infrun: clear_proceed_status_thread (process 25311) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 25311] at 0x400594 LLR: PTRACE_SINGLESTEP process 25311, 0 (resume event thread) target_resume (25311, step, 0) native:target_xfer_partial (3, (null), 0x0, 0x32dce4c, 0x400595, 1) = 0, 0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (gdb) linux_nat_wait: [process -1], [TARGET_WNOHANG] 0x400595 is the address of the breakpoint, and "= 0" is TARGET_XFER_EOF. That's default_memory_remove_breakpoint trying to remove the breakpoint, but failing. The problem is that we had just resumed the target and the native GNU/Linux target can't read memory off of a running thread. Most of the time, we get "lucky", because we manage to read memory before the kernel actually schedules the target to run. So just give up and skip the test on any target that uses hardware stepping, not just remote targets. gdb/testsuite/ 2014-06-06 Pedro Alves <palves@redhat.com> * gdb.base/sss-bp-on-user-bp-2.exp: Look for target_resume(step) in target debug output instead of looking at RSP packets, disabling the test on any target that uses hardware stepping. Update comments.
2014-06-06 20:59:21 +02:00
2014-06-06 Pedro Alves <palves@redhat.com>
* gdb.base/sss-bp-on-user-bp-2.exp: Look for target_resume(step)
in target debug output instead of looking at RSP packets,
disabling the test on any target that uses hardware stepping.
Update comments.
break-unload-file.exp: Fix typo. s/is not pending/is pending/ gdb/testsuite/ 2014-06-06 Pedro Alves <palves@redhat.com> * gdb.base/break-unload-file.exp: Fix typo.
2014-06-06 16:52:24 +02:00
2014-06-06 Pedro Alves <palves@redhat.com>
* gdb.base/break-unload-file.exp: Fix typo.
Restrict the pattern in gdb.base/jit.exp I see the following fail in some thumb multi-lib in arm-none-linux-gnueabi, info function jit_function^M All functions matching regular expression "jit_function":^M ^M Non-debugging symbols:^M 0x00000790 __real_jit_function_XXXX^M 0x0000079c __jit_function_XXXX_from_arm^M 0x0000079c jit_function_0000^M 0x00000790 __real_jit_function_XXXX^M 0x0000079c __jit_function_XXXX_from_arm^M 0x0000079c jit_function_0001^M (gdb) FAIL: gdb.base/jit.exp: one_jit_test-2: info function jit_function the test expects to see only jit_function_0000 and jit_function_0001 one_jit_test 2 "${hex} jit_function_0000\[\r\n\]+${hex} jit_function_0001" Symbols with the prefix "__real_" or suffix "_from_arm" is generated by gcc/ld for arm/thumb interworking. This patch is to restrict the pattern from "jit_function" to "^jit_function", the output becomes expected. gdb/testsuite: 2014-06-06 Yao Qi <yao@codesourcery.com> * gdb.base/jit.exp (one_jit_test): Restrict the pattern from "jit_function" to "^jit_function".
2014-06-06 13:16:47 +02:00
2014-06-06 Yao Qi <yao@codesourcery.com>
* gdb.base/jit.exp (one_jit_test): Restrict the pattern
from "jit_function" to "^jit_function".
Tweak gdb.base/async.exp I see two fails in async.exp on arm-none-eabi target: nexti&^M (gdb) 0x000001ba 14 x = 5; x = 5;^M completed.^M FAIL: gdb.base/async.exp: nexti& finish&^M Run till exit from #0 0x000001ba in foo () at /scratch/yqi/arm-none-eabi-lite/src/gdb-trunk/gdb/testsuite/gdb.base/async.c:14^M (gdb) 0x000001e6 in main () at /scratch/yqi/arm-none-eabi-lite/src/gdb-trunk/gdb/testsuite/gdb.base/async.c:32^M 32 y = foo ();^M Value returned is $1 = 8^M completed.^M FAIL: gdb.base/async.exp: finish& The corresponding test is "test_background "nexti&" "" ".*y = 3.*"", and it assumes that GDB "nexti" into the next source line. It is wrong on arm. After "nexti", it still stops at the same source line, and it fails. When gdb does "finish", if the PC is in the middle of a source line, the PC address is printed too. See stack.c:print_frame, if (opts.addressprint) if (!sal.symtab || frame_show_address (frame, sal) || print_what == LOC_AND_ADDRESS) { annotate_frame_address (); if (pc_p) ui_out_field_core_addr (uiout, "addr", gdbarch, pc); else ui_out_field_string (uiout, "addr", "<unavailable>"); annotate_frame_address_end (); ui_out_text (uiout, " in "); } frame_show_address checks whether PC is the middle of a source line. Since after "nexti", the inferior stops at the middle of a source line, when we do "finish" the PC address is displayed. In sum, GDB works well, but test case needs update. This patch is to add a statement at the same line to make sure "nexti" doesn't go to the new line, match the next instruction address in the output and match the hex address the output of "finish". gdb/testsuite: 2014-06-06 Yao Qi <yao@codesourcery.com> * gdb.base/async.c (foo): Add one statement. * gdb.base/async.exp: Get the next instruction address and match the output of "nexti" by instruction address. Match the hex address in the output of "finish".
2014-06-06 08:32:42 +02:00
2014-06-06 Yao Qi <yao@codesourcery.com>
* gdb.base/async.c (foo): Add one statement.
* gdb.base/async.exp: Get the next instruction address and
match the output of "nexti" by instruction address. Match
the hex address in the output of "finish".
Remove preprocessor conditionals for ANSI-standard signals The six signals SIGINT, SIGILL, SIGABRT, SIGFPE, SIGSEGV and SIGTERM are ANSI-standard and thus guaranteed to be available. This patch removes all preprocessor conditionals relating to these symbols. gdb/ 2014-06-06 Gary Benson <gbenson@redhat.com> * common/signals.c: Remove preprocessor conditionals for always-defined signals SIGINT, SIGILL, SIGABRT, SIGFPE, SIGSEGV and SIGTERM. * proc-events.c: Likewise. gdb/testsuite/ 2014-06-06 Gary Benson <gbenson@redhat.com> * gdb.base/call-signals.c: Remove preprocessor conditionals for always-defined signals SIGINT, SIGILL, SIGABRT, SIGFPE, SIGSEGV and SIGTERM. * gdb.base/sigall.c: Likewise. * gdb.base/unwindonsignal.c: Likewise. * gdb.reverse/sigall-reverse.c: Likewise.
2014-06-06 11:32:12 +02:00
2014-06-06 Gary Benson <gbenson@redhat.com>
* gdb.base/call-signals.c: Remove preprocessor conditionals
for always-defined signals SIGINT, SIGILL, SIGABRT, SIGFPE,
SIGSEGV and SIGTERM.
* gdb.base/sigall.c: Likewise.
* gdb.base/unwindonsignal.c: Likewise.
* gdb.reverse/sigall-reverse.c: Likewise.
Skip hbreak-unmapped.exp if memory at address 0 is readable hbreak-unmapped.exp assumes that memory at address 0 is unmapped or unreadable, but on bare metal or uclinux targets, memory at address 0 is readable. For example, on arm-none-eabi, the vector table base address is 0x0. hbreak *0^M Hardware assisted breakpoint 3 at 0x0: file /scratch/yqi/arm-none-eabi-lite/obj/cs3-2014.11-999999-arm-none-eabi-i686-pc-linux-gnu/generated/arm-vector.S, line 25.^M (gdb) FAIL: gdb.base/hbreak-unmapped.exp: hbreak *0 info break^M Num Type Disp Enb Address What^M 3 hw breakpoint keep y 0x00000000 /scratch/yqi/arm-none-eabi-lite/obj/cs3-2014.11-999999-arm-none-eabi-i686-pc-linux-gnu/generated/arm-vector.S:25^M (gdb) FAIL: gdb.base/hbreak-unmapped.exp: info break shows hw breakpoint delete $bpnum This patch is to check whether address 0 is readable via command 'x 0'. If it is, skip the test. gdb/testsuite: 2014-06-06 Yao Qi <yao@codesourcery.com> * gdb.base/hbreak-unmapped.exp: Read memory at address 0. If readable, skip the test.
2014-06-06 05:05:05 +02:00
2014-06-06 Yao Qi <yao@codesourcery.com>
* gdb.base/hbreak-unmapped.exp: Read memory at address 0. If
readable, skip the test.
Fix the race in gdb.threads/staticthreads.exp The code in gdb.threads/staticthreads.exp about checking the value of tlsvar in main thread is racy, because when child thread hits breakpoint, the main thread may not go into pthread_join yet, and may not be unwind to main. This patch is to move the line setting breakpoint on after sem_wait, so that the child thread will hit breakpoint after main thread calls sem_post. IOW, when child thread hits breakpoint, the main thread is in either sem_post or pthread_join. "up 10" can unwind main thread to main. gdb/testsuite: 2014-06-06 Yao Qi <yao@codesourcery.com> * gdb.threads/staticthreads.c (thread_function): Move the line setting breakpoint on forward. * gdb.threads/staticthreads.exp: Update comments.
2014-06-05 09:07:47 +02:00
2014-06-06 Yao Qi <yao@codesourcery.com>
* gdb.threads/staticthreads.c (thread_function): Move the line
setting breakpoint on forward.
* gdb.threads/staticthreads.exp: Update comments.
guile: Type-check the argument to 'history-append!'. gdb/ 2014-06-05 Ludovic Courtès <ludo@gnu.org> * guile/scm-value.c (gdbscm_history_append_x): Use 'vlscm_get_value_smob_arg_unsafe' instead of 'vlscm_scm_to_value'. gdb/testsuite/ 2014-06-05 Ludovic Courtès <ludo@gnu.org> * gdb.guile/scm-value.exp (test_value_in_inferior): Add test "history-append! type error".
2014-06-06 00:02:33 +02:00
2014-06-05 Ludovic Courtès <ludo@gnu.org>
* gdb.guile/scm-value.exp (test_value_in_inferior): Add test
"history-append! type error".
PR mi/15806: Fix quoting of async events Original patch: https://sourceware.org/ml/gdb-patches/2014-04/msg00552.html New in v2: * In remote.c:escape_buffer, pass '\\' to fputstrn_unfiltered/printchar to make sure backslashes are escaped in remote debug output. * Updated function documentation for printchar. See updated ChangeLog below. -------------------- The quoting in whatever goes in the event_channel of MI is little bit broken. Link for the lazy: https://sourceware.org/bugzilla/show_bug.cgi?id=15806 Here is an example of a =library-loaded event with an ill-named directory, /tmp/how"are\you (the problem is present with every directory on Windows since it uses backslashes as a path separator). The result will be the following: =library-loaded,id="/tmp/how"are\\you/libexpat.so.1",... The " between 'how' and 'are' should be escaped. Another bad behavior is double escaping in =breakpoint-created, for example: =breakpoint-created,bkpt={...,fullname="/tmp/how\\"are\\\\you/test.c",...} The two backslashes before 'how' should be one and the four before 'you' should be two. The reason for this is that when sending something to an MI console, escaping can take place at two different moments (the actual escaping work is always done in the printchar function): 1. When generating the content, if ui_out_field_* functions are used. Here, fields are automatically quoted with " and properly escaped. At least mi_field_string does it, not sure about mi_field_fmt, I need to investigate further. 2. When gdb_flush is called, to send the data in the buffer of the console to the actual output (stdout). At this point, mi_console_raw_packet takes the whole string in the buffer, quotes it, and escapes all occurences of the quoting character and backslashes. The event_channel does not specify a quoting character, so quotes are not escaped here, only backslashes. The problem with =library-loaded is that it does use fprintf_unfiltered, which doesn't do escaping (so, no #1). When gdb_flush is called, backslashes are escaped (#2). The problem with =breakpoint-created is that it first uses ui_out_field_* functions to generate its output, so backslashes and quotes are escaped there (#1). backslashes are escaped again in #2, leading to an overdose of backslashes. In retrospect, there is no way escaping can be done reliably in mi_console_raw_packet for data that is already formatted, such as event_channel. At this point, there is no way to differentiate quotes that delimit field values from those that should be escaped. In the case of other MI consoles, it is ok since mi_console_raw_packet receives one big string that should be quoted and escaped as a whole. So, first part of the fix: for the MI channels that specify no quoting character, no escaping at all should be done in mi_console_raw_packet (that's the change in printchar, thanks to Yuanhui Zhang for this). For those channels, whoever generates the content is responsible for proper quoting and escaping. This will fix the =breakpoint-created kind of problem. Second part of the fix is to make =library-loaded generate content that is properly escaped. For this, we use ui_out_field_* functions, instead of one big fprintf_unfiltered. =library-unloaded suffered from the same problem so it is modified as well. There might be other events that need fixing too, but that's all I found with a quick scan. Those that use fprintf_unfiltered but whose sole variable data is a %d are not critical, since it won't generate a " or a \. Finally, a test has been fixed, as it was expecting an erroneous output. Otherwise, all other tests that were previously passing still pass (x86-64 linux). gdb/ChangeLog: 2014-06-02 Simon Marchi <simon.marchi@ericsson.com> PR mi/15806 * utils.c (printchar): Don't escape at all if quoter is NUL. Update function documentation to clarify effect of parameter QUOTER. * remote.c (escape_buffer): Pass '\\' as the quoter to fputstrn_unfiltered. * mi/mi-interp.c (mi_solib_loaded): Use ui_out_field_* functions to generate the output. (mi_solib_unloaded): Same. gdb/testsuite/ChangeLog: 2014-06-02 Simon Marchi <simon.marchi@ericsson.com> * gdb.mi/mi-breakpoint-changed.exp (test_insert_delete_modify): Fix erroneous dprintf expected input.
2014-06-02 23:10:36 +02:00
2014-06-05 Simon Marchi <simon.marchi@ericsson.com>
* gdb.mi/mi-breakpoint-changed.exp (test_insert_delete_modify): Fix
erroneous dprintf expected input.
Delete scm-generics.exp. Support for smobs as goops classes is changing in guile 2.2. We may eventually switch to using structs instead of smobs, so remove any claim we support goops or generics for now. * gdb.guile/scm-generics.exp: Delete.
2014-06-05 05:01:40 +02:00
2014-06-04 Doug Evans <xdje42@gmail.com>
* gdb.guile/scm-generics.exp: Delete.
Split create-breakpoint! into make-breakpoint, register-breakpoint!. Rename breakpoint-delete! to delete-breakpoint!. * guile/scm-breakpoint.c (struct gdbscm_breakpoint_object): New members is_scheme_bkpt, spec. (bpscm_make_breakpoint_smob): Initialize new members. (gdbscm_create_breakpoint_x): Split into two ... (gdbscm_make_breakpoint, gdbscm_register_breakpoint_x): New functions. (bpscm_breakpoint_deleted): Reset breakpoint number and stop function. (scheme_function breakpoint_functions): Update. * guile/lib/gdb.scm: Delete create-breakpoint!. Rename breakpoint-delete! to delete-breakpoint!. Add make-breakpoint, register-breakpoint!. testsuite/ * gdb.guile/scm-breakpoint.exp: Update. Add tests for breakpoint registration. doc/ * guile.texi (Breakpoints In Guile): Update.
2014-06-05 04:44:30 +02:00
2014-06-04 Doug Evans <xdje42@gmail.com>
* gdb.guile/scm-breakpoint.exp: Update.
Add tests for breakpoint registration.
handle VLA in a struct or union It is valid in GNU C to have a VLA in a struct or union type, but gdb did not handle this. This patch adds support for these cases in the obvious way. Built and regtested on x86-64 Fedora 20. New tests included. 2014-06-04 Tom Tromey <tromey@redhat.com> * ada-lang.c (ada_template_to_fixed_record_type_1): Use value_from_contents_and_address_unresolved. (ada_template_to_fixed_record_type_1): Likewise. (ada_which_variant_applies): Likewise. * value.h (value_from_contents_and_address_unresolved): Declare. * value.c (value_from_contents_and_address_unresolved): New function. * gdbtypes.c (is_dynamic_type, resolve_dynamic_type) <TYPE_CODE_STRUCT, TYPE_CODE_UNION>: New cases. (resolve_dynamic_struct, resolve_dynamic_union): New functions. 2014-06-04 Tom Tromey <tromey@redhat.com> * gdb.base/vla-datatypes.exp: Add tests for VLA-in-structure and VLA-in-union. * gdb.base/vla-datatypes.c (vla_factory): Add vla_struct, inner_vla_struct, vla_union types. Initialize objects of those types and compute their sizes.
2014-05-08 19:26:44 +02:00
2014-06-04 Tom Tromey <tromey@redhat.com>
* gdb.base/vla-datatypes.exp: Add tests for VLA-in-structure and
VLA-in-union.
* gdb.base/vla-datatypes.c (vla_factory): Add vla_struct,
inner_vla_struct, vla_union types. Initialize objects of those
types and compute their sizes.
Add system test before "set remote system-call-allowed 1" to fileio.exp This patch is update version according to the discussion in https://www.sourceware.org/ml/gdb-patches/2009-11/msg00090.html. If test get the target doesn't support fileio system according to the remote log. It will set this test as "unsupported". Before I made this patch, I want add a check before all of tests in this file. But I found that the target maybe support one call but not others. For example: my target support Fwrite, Fopen and so on. But not Fgettimeofday. And it doesn't support Fsystem NULL but it support Fsystem not NULL. So I think if we want to check target support fileio, we need check them one by one. 2014-06-04 Nathan Sidwell <nathan@codesourcery.com> Hui Zhu <hui@codesourcery.com> * gdb.base/fileio.exp: Add test for shell not available as well as available. * gdb.base/fileio.c (test_system): Check for shell twice.
2014-06-04 08:37:34 +02:00
2014-06-04 Nathan Sidwell <nathan@codesourcery.com>
Hui Zhu <hui@codesourcery.com>
* gdb.base/fileio.exp: Add test for shell not available as well as
available.
* gdb.base/fileio.c (test_system): Check for shell twice.
Fix a regexp pattern in gdb.base/auto-connect-native-target.exp When I test gdb head (for 7.8 release) on arm-none-eabi, I find the following this failure, which are caused by the improper regexp pattern in the test. (gdb) help target native^M Undefined target command: "native". Try "help target".^M (gdb) FAIL: gdb.base/auto-connect-native-target.exp: help target native The space in front of "$gdb_prompt $" looks redundant, and this patch is to remove it from the regexp pattern. gdb/testsuite: 2014-06-04 Yao Qi <yao@codesourcery.com> * gdb.base/auto-connect-native-target.exp: Remove redundant space from the regexp pattern.
2014-06-03 07:20:56 +02:00
2014-06-04 Yao Qi <yao@codesourcery.com>
* gdb.base/auto-connect-native-target.exp: Remove redundant
space from the regexp pattern.
Fix regexp pattern in gdb.base/default.exp I see this failure on arm-none-eabi gdb testing. target native^M Undefined target command: "native". Try "help target".^M (gdb) FAIL: gdb.base/default.exp: target native This patch is to update the regexp pattern to match "native" instead of "child". gdb/testsuite: 2014-06-04 Yao Qi <yao@codesourcery.com> * gdb.base/default.exp: Replace "child" with "native" in regexp pattern.
2014-06-03 07:17:42 +02:00
2014-06-04 Yao Qi <yao@codesourcery.com>
* gdb.base/default.exp: Replace "child" with "native" in
regexp pattern.
Xmethod support in Python. * python/py-xmethods.c: New file. * python/py-objfile.c (objfile_object): New field 'xmethods'. (objfpy_dealloc): XDECREF on the new xmethods field. (objfpy_new, objfile_to_objfile_object): Initialize xmethods field. (objfpy_get_xmethods): New function. (objfile_getset): New entry 'xmethods'. * python/py-progspace.c (pspace_object): New field 'xmethods'. (pspy_dealloc): XDECREF on the new xmethods field. (pspy_new, pspace_to_pspace_object): Initialize xmethods field. (pspy_get_xmethods): New function. (pspace_getset): New entry 'xmethods'. * python/python-internal.h: Add declarations for new functions. * python/python.c (_initialize_python): Invoke gdbpy_initialize_xmethods. * python/lib/gdb/__init__.py (xmethods): New attribute. * python/lib/gdb/xmethod.py: New file. * python/lib/gdb/command/xmethods.py: New file. testuite/ * gdb.python/py-xmethods.cc: New testcase to test xmethods. * gdb.python/py-xmethods.exp: New tests to test xmethods. * gdb.python/py-xmethods.py: Python script supporting the new testcase and tests.
2014-05-20 15:53:04 +02:00
2014-06-03 Siva Chandra Reddy <sivachandra@google.com>
* gdb.python/py-xmethods.cc: New testcase to test xmethods.
* gdb.python/py-xmethods.exp: New tests to test xmethods.
* gdb.python/py-xmethods.py: Python script supporting the
new testcase and tests.
User breakpoint ignored if software-single-step at same location with the following code... 12 Nested; -- break #1 13 return I; -- break #2 14 end; (line 12 is a call to function Nested) ... we have noticed the following errorneous behavior on ppc-aix, where, after having inserted a breakpoint at line 12 and line 13, and continuing from the breakpoint at line 12, the program never stops at line 13, running away until the program terminates: % gdb -q func (gdb) b func.adb:12 Breakpoint 1 at 0x10000a24: file func.adb, line 12. (gdb) b func.adb:13 Breakpoint 2 at 0x10000a28: file func.adb, line 13. (gdb) run Starting program: /[...]/func Breakpoint 1, func () at func.adb:12 12 Nested; -- break #1 (gdb) c Continuing. [Inferior 1 (process 4128872) exited with code 02] When resuming from the first breakpoint, GDB first tries to step out of that first breakpoint. We rely on software single-stepping on this platform, and it just so happens that the address of the first software single-step breakpoint is the same as the user's breakpoint #2 (0x10000a28). So, with infrun and target traces turned on (but uninteresting traces snip'ed off), the "continue" operation looks like this: (gdb) c ### First, we insert the user breakpoints (the second one is an internal ### breakpoint on __pthread_init). The first user breakpoint is not ### inserted as we need to step out of it first. target_insert_breakpoint (0x0000000010000a28, xxx) = 0 target_insert_breakpoint (0x00000000d03f3800, xxx) = 0 ### Then we proceed with the step-out-of-breakpoint... infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 15335610] at 0x10000a24 ### That's when we insert the SSS breakpoints... target_insert_breakpoint (0x0000000010000a28, xxx) = 0 target_insert_breakpoint (0x00000000100009ac, xxx) = 0 ### ... then let the inferior resume... target_resume (15335610, continue, 0) infrun: wait_for_inferior () target_wait (-1, status, options={}) = 15335610, status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: target_wait (-1, status) = infrun: 15335610 [process 15335610], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x100009ac ### At this point, we stopped at the second SSS breakpoint... target_stopped_by_watchpoint () = 0 ### We remove the SSS breakpoints... target_remove_breakpoint (0x0000000010000a28, xxx) = 0 target_remove_breakpoint (0x00000000100009ac, xxx) = 0 target_stopped_by_watchpoint () = 0 ### We find that we're not done, so we resume.... infrun: no stepping, continue ### And thus insert the user breakpoints again, except we're not ### inserting the second breakpoint?!? target_insert_breakpoint (0x0000000010000a24, xxx) = 0 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 15335610] at 0x100009ac target_resume (-1, continue, 0) infrun: prepare_to_wait target_wait (-1, status, options={}) = 15335610, status->kind = exited, status = 2 What happens is that the removal of the software single-step breakpoints effectively removed the breakpoint instruction from inferior memory. But because such breakpoints are inserted directly as raw breakpoints rather than through the normal chain of breakpoints, we fail to notice that one of the user breakpoints points to the same address and that this user breakpoint is therefore effectively un-inserted. When resuming after the single-step, GDB thinks that the user breakpoint is still inserted and therefore does not need to insert it again. This patch teaches the insert and remove routines of both regular and raw breakpoints to be aware of each other. Special care needs to be applied in case the target supports evaluation of breakpoint conditions or commands. gdb/ChangeLog: PR breakpoints/17000 * breakpoint.c (find_non_raw_software_breakpoint_inserted_here): New function, extracted from software_breakpoint_inserted_here_p. (software_breakpoint_inserted_here_p): Replace factored out code by call to find_non_raw_software_breakpoint_inserted_here. (bp_target_info_copy_insertion_state): New function. (bkpt_insert_location): Handle the case of a single-step breakpoint already inserted at the same address. (bkpt_remove_location): Handle the case of a single-step breakpoint still inserted at the same address. (deprecated_insert_raw_breakpoint): Handle the case of non-raw breakpoint already inserted at the same address. (deprecated_remove_raw_breakpoint): Handle the case of a non-raw breakpoint still inserted at the same address. (find_single_step_breakpoint): New function, extracted from single_step_breakpoint_inserted_here_p. (find_single_step_breakpoint): New function, factored out from single_step_breakpoint_inserted_here_p. (single_step_breakpoint_inserted_here_p): Reimplement. gdb/testsuite/ChangeLog: PR breakpoints/17000 * gdb.base/sss-bp-on-user-bp.exp: Remove kfail. * gdb.base/sss-bp-on-user-bp-2.exp: Remove kfail. Tested on ppc-aix with AdaCore's testsuite. Tested on x86_64-linux, (native and gdbserver) with the official testsuite. Also tested on x86_64-linux through Pedro's branch enabling software single-stepping on that platform (native and gdbserver).
2014-06-03 18:42:19 +02:00
2014-06-03 Joel Brobecker <brobecker@adacore.com>
Pedro Alves <palves@redhat.com>
PR breakpoints/17000
* gdb.base/sss-bp-on-user-bp.exp: Remove kfail.
* gdb.base/sss-bp-on-user-bp-2.exp: Remove kfail.
gdb/source.c: Fix matching path substitute rule listing The check for the source (or "from") directory snippet in listing matching path substitution rules currently will not match anything other than a direct match of the "from" field in a substitution rule, resulting in the incorrect behavior below: ... (gdb) set substitute-path /a/path /another/path (gdb) show substitute-path List of all source path substitution rules: `/a/path' -> `/another/path'. (gdb) show substitute-path /a/path/to/a/file.ext Source path substitution rule matching `/a/path/to/a/file.ext': (gdb) show substitute-path /a/path Source path substitution rule matching `/a/path': `/a/path' -> `/another/path'. ... This change effects the following behavior by (sanely) checking with the length of the "from" portion of a rule and ensuring that the next character of the path considered for substitution is a path delimiter (or NULL). With this change, the following behavior is garnered: ... (gdb) set substitute-path /a/path /another/path (gdb) show substitute-path List of all source path substitution rules: `/a/path' -> `/another/path'. (gdb) show substitute-path /a/path/to/a/file.ext Source path substitution rule matching `/a/path/to/a/file.ext': `/a/path' -> `/another/path'. (gdb) show substitute-path /a/pathological/case/that/should/fail.err Source path substitution rule matching `/a/pathological/case/that/should/fail.err': (gdb) Also included is a couple of tests added to subst.exp to verify this behavior in the test suite. gdb/ChangeLog: * source.c (show_substitute_path_command): Fix display of matching substitution rules. gdb/testsuite/ChangeLog: * gdb.ada/subst.exp: Add tests to verify partial path matching output. This was tested on x86_64 Linux.
2014-06-02 22:55:10 +02:00
2014-06-03 Brad Mouring <bmouring@ni.com> (tiny patch)
* gdb.base/subst.exp: Add tests to verify partial path matching
output.
Skip sss-bp-on-user-bp-2.exp on remote hardware step targets. gdb/testsuite/ 2014-06-03 Pedro Alves <palves@redhat.com> * gdb.base/sss-bp-on-user-bp-2.exp: Skip if testing with a remote target that doesn't use software single-stepping.
2014-06-03 15:04:48 +02:00
2014-06-03 Pedro Alves <palves@redhat.com>
* gdb.base/sss-bp-on-user-bp-2.exp: Skip if testing with a remote
target that doesn't use software single-stepping.
PR breakpoints/17000: user breakpoint not inserted if software-single-step at same location - test GDB gets confused when removing a software single-step breakpoint that is at the same address as another breakpoint. Add another kfailed test. gdb/testsuite/ 2014-06-03 Pedro Alves <palves@redhat.com> PR breakpoints/17000 * gdb.base/sss-bp-on-user-bp-2.c: New file. * gdb.base/sss-bp-on-user-bp-2.exp: New file.
2014-06-03 13:46:46 +02:00
2014-06-03 Pedro Alves <palves@redhat.com>
PR breakpoints/17000
* gdb.base/sss-bp-on-user-bp-2.c: New file.
* gdb.base/sss-bp-on-user-bp-2.exp: New file.
Add parameter support for Guile. * Makefile.in (SUBDIR_GUILE_OBS): Add scm-param.o. (SUBDIR_GUILE_SRCS): Add scm-param.c. (scm-param.o): New rule. * guile/guile-internal.h (gdbscm_gc_dup_argv): Declare. (gdbscm_misc_error): Declare. (gdbscm_canonicalize_command_name): Declare. (gdbscm_scm_to_host_string): Declare. (gdbscm_scm_from_host_string): Declare. (gdbscm_initialize_parameters): Declare. * guile/guile.c (initialize_gdb_module): Call gdbscm_initialize_parameters. * guile/lib/gdb.scm: Export parameter symbols. * guile/scm-cmd.c (gdbscm_canonicalize_command_name): Renamed from cmdscm_canonicalize_name and made public. All callers updated. * guile/scm-exception.c (gdbscm_misc_error): New function. * guile/scm-param.c: New file. * guile/scm-string.c (gdbscm_scm_to_string): Add comments. (gdbscm_scm_to_host_string): New function. (gdbscm_scm_from_host_string): New function. * scm-utils.c (gdbscm_gc_dup_argv): New function. testsuite/ * gdb.guile/scm-parameter.exp: New file. doc/ * guile.texi (Guile API): Add entry for Parameters In Guile. (GDB Scheme Data Types): Mention <gdb:parameter> object. (Parameters In Guile): New node.
2014-06-03 10:58:15 +02:00
2014-06-02 Doug Evans <xdje42@gmail.com>
* gdb.guile/scm-parameter.exp: New file.
Add command support for Guile. * Makefile.in (SUBDIR_GUILE_OBS): Add scm-cmd.o. (SUBDIR_GUILE_SRCS): Add scm-cmd.c. (scm-cmd.o): New rule. * guile/guile-internal.h (gdbscm_gc_xstrdup): Declare. (gdbscm_user_error_p): Declare. (gdbscm_parse_command_name): Declare. (gdbscm_valid_command_class_p): Declare. (gdbscm_initialize_commands): Declare. * guile/guile.c (initialize_gdb_module): Call gdbscm_initialize_commands. * guile/lib/gdb.scm: Export command symbols. * guile/lib/gdb/init.scm (%exception-keys): Add gdb:user-error. (throw-user-error): New function. * guile/scm-cmd.c: New file. * guile/scm-exception.c (user_error_symbol): New static global. (gdbscm_user_error_p): New function. (gdbscm_initialize_exceptions): Set user_error_symbol. * scm-utils.c (gdbscm_gc_xstrdup): New function. testsuite/ * gdb.guile/scm-cmd.c: New file. * gdb.guile/scm-cmd.exp: New file. doc/ * guile.texi (Guile API): Add entry for Commands In Guile. (Basic Guile) <parse-and-eval>: Add reference. (Basic Guile) <string->argv>: Move definition to Commands In Guile. (GDB Scheme Data Types): Mention <gdb:command> object. (Commands In Guile): New node.
2014-06-03 09:29:49 +02:00
2014-06-02 Doug Evans <xdje42@gmail.com>
* gdb.guile/scm-cmd.c: New file.
* gdb.guile/scm-cmd.exp: New file.
Add progspace support for Guile. * Makefile.in (SUBDIR_GUILE_OBS): Add scm-progspace.o. (SUBDIR_GUILE_SRCS): Add scm-progspace.c. (scm-progspace.o): New rule. * guile/guile-internal.h (pspace_smob): New typedef. (psscm_pspace_smob_pretty_printers): Declare. (psscm_pspace_smob_from_pspace): Declare. (psscm_scm_from_pspace): Declare. * guile/guile.c (initialize_gdb_module): Call gdbscm_initialize_pspaces. * guile/lib/gdb.scm: Export progspace symbols. * guile/lib/gdb/printing.scm (prepend-pretty-printer!): Add progspace support. (append-pretty-printer!): Ditto. * guile/scm-pretty-print.c (ppscm_find_pretty_printer_from_progspace): Implement. * guile/scm-progspace.c: New file. doc/ * guile.texi (Guile API): Add entry for Progspaces In Guile. (GDB Scheme Data Types): Mention <gdb:progspace> object. (Progspaces In Guile): New node. testsuite/ * gdb.guile/scm-pretty-print.exp: Add tests for objfile and progspace pretty-printer lookup. * gdb.guile/scm-pretty-print.scm (pp_s-printer): New function. (make-pp_s-printer): Call it. (make-pretty-printer-from-dict): New function. (lookup-pretty-printer-maker-from-dict): New function. (*pretty-printer*): Simplify. (make-objfile-pp_s-printer): New function. (install-objfile-pretty-printers!): New function. (make-progspace-pp_s-printer): New function. (install-progspace-pretty-printers!): New function. * gdb.guile/scm-progspace.c: New file. * gdb.guile/scm-progspace.exp: New file.
2014-06-03 08:46:27 +02:00
2014-06-02 Doug Evans <xdje42@gmail.com>
* gdb.guile/scm-pretty-print.exp: Add tests for objfile and progspace
pretty-printer lookup.
* gdb.guile/scm-pretty-print.scm (pp_s-printer): New function.
(make-pp_s-printer): Call it.
(make-pretty-printer-from-dict): New function.
(lookup-pretty-printer-maker-from-dict): New function.
(*pretty-printer*): Simplify.
(make-objfile-pp_s-printer): New function.
(install-objfile-pretty-printers!): New function.
(make-progspace-pp_s-printer): New function.
(install-progspace-pretty-printers!): New function.
* gdb.guile/scm-progspace.c: New file.
* gdb.guile/scm-progspace.exp: New file.
Installing a breakpoint on top of a dprintf makes GDB lose control. While the full fix for PR 15180 isn't in, it's best if we at least make sure that GDB doesn't lose control when a breakpoint is set at the same address as a dprintf. gdb/ 2014-06-02 Pedro Alves <palves@redhat.com> * breakpoint.c (build_target_command_list): Don't build a command list if we have any duplicate location that isn't a dprintf. gdb/testsuite/ 2014-06-02 Pedro Alves <palves@redhat.com> * gdb.base/dprintf-bp-same-addr.c: New file. * gdb.base/dprintf-bp-same-addr.exp: New file.
2014-06-02 23:27:33 +02:00
2014-06-02 Pedro Alves <palves@redhat.com>
* gdb.base/dprintf-bp-same-addr.c: New file.
* gdb.base/dprintf-bp-same-addr.exp: New file.
gdb/testsuite/ 2014-06-02 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com> * gdb.arch/powerpc-power.exp: Add power8 instructions to the testcase. * gdb.arch/powerpc-power.s: Likewise.
2014-06-02 18:57:27 +02:00
2014-06-02 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
* gdb.arch/powerpc-power.exp: Add power8 instructions to the testcase.
* gdb.arch/powerpc-power.s: Likewise.
Unnecessary restore of timeout global at end of gdb.base/completion.exp This patch removes some code in gdb.base/compilation.exp which is aimed at restoring the original timeout global value after having changed it for this testcase. Restoring the timeout global is not necessary as this is taken care of by gdb_init, which is called at the start of each testing. gdb/testsuite/ChangeLog: * gdb.base/completion.exp: Remove code aimed at restoring TIMEOUT.
2014-05-27 23:03:11 +02:00
2014-06-02 Joel Brobecker <brobecker@adacore.com>
* gdb.base/completion.exp: Remove code aimed at restoring TIMEOUT.
Skip test 'watch -location nullptr->p->x' if null pointer can be dereferenced gdb.base/watchpoint.exp has a test below which expects to see "Cannot access memory at address 0x0" when a null pointer is dereferenced. gdb_test "watch -location nullptr->p->x" \ "Cannot access memory at address 0x0" This assumption is not true when the target is no-mmu, so we get watch -location nullptr->p->x Hardware watchpoint 28: -location nullptr->p->x (gdb) FAIL: gdb.base/watchpoint.exp: watch -location nullptr->p->x This patch is to check whether null pointer can be dereferenced first and then do the test. gdb/testsuite: 2014-06-01 Yao Qi <yao@codesourcery.com> * gdb.base/watchpoint.exp (test_watch_location): Check null pointer can be dereferenced. If not, do the test, otherwise skip it.
2014-05-28 06:38:52 +02:00
2014-06-01 Yao Qi <yao@codesourcery.com>
* gdb.base/watchpoint.exp (test_watch_location): Check null
pointer can be dereferenced. If not, do the test, otherwise
skip it.
Add a TRY_CATCH to get_prev_frame_always to better manage errors during unwind. https://sourceware.org/ml/gdb-patches/2014-05/msg00737.html Currently a MEMORY_ERROR raised during unwinding a frame will cause the unwind to stop with an error message, for example: (gdb) bt #0 breakpt () at amd64-invalid-stack-middle.c:27 #1 0x00000000004008f0 in func5 () at amd64-invalid-stack-middle.c:32 #2 0x0000000000400900 in func4 () at amd64-invalid-stack-middle.c:38 #3 0x0000000000400910 in func3 () at amd64-invalid-stack-middle.c:44 #4 0x0000000000400928 in func2 () at amd64-invalid-stack-middle.c:50 Cannot access memory at address 0x2aaaaaab0000 However, frame #4 is marked as being the end of the stack unwind, so a subsequent request for the backtrace looses the error message, such as: (gdb) bt #0 breakpt () at amd64-invalid-stack-middle.c:27 #1 0x00000000004008f0 in func5 () at amd64-invalid-stack-middle.c:32 #2 0x0000000000400900 in func4 () at amd64-invalid-stack-middle.c:38 #3 0x0000000000400910 in func3 () at amd64-invalid-stack-middle.c:44 #4 0x0000000000400928 in func2 () at amd64-invalid-stack-middle.c:50 When fetching the backtrace, or requesting the stack depth using the MI interface the situation is even worse, the first time a request is made we encounter the memory error and so the MI returns an error instead of the correct result, for example: (gdb) -stack-info-depth ^error,msg="Cannot access memory at address 0x2aaaaaab0000" Or, (gdb) -stack-list-frames ^error,msg="Cannot access memory at address 0x2aaaaaab0000" However, once one of these commands has been used gdb has, internally, walked the stack and figured that out that frame #4 is the bottom of the stack, so the second time an MI command is tried you'll get the "expected" result: (gdb) -stack-info-depth ^done,depth="5" Or, (gdb) -stack-list-frames ^done,stack=[frame={level="0", .. snip lots .. }] After this patch the MEMORY_ERROR encountered during the frame unwind is attached to frame #4 as the stop reason, and is displayed in the CLI each time the backtrace is requested. In the MI, catching the error means that the "expected" result is returned the first time the MI command is issued. So, from the CLI the results of the backtrace will be: (gdb) bt #0 breakpt () at amd64-invalid-stack-middle.c:27 #1 0x00000000004008f0 in func5 () at amd64-invalid-stack-middle.c:32 #2 0x0000000000400900 in func4 () at amd64-invalid-stack-middle.c:38 #3 0x0000000000400910 in func3 () at amd64-invalid-stack-middle.c:44 #4 0x0000000000400928 in func2 () at amd64-invalid-stack-middle.c:50 Backtrace stopped: Cannot access memory at address 0x2aaaaaab0000 Each and every time that the backtrace is requested, while the MI output will similarly be consistently: (gdb) -stack-info-depth ^done,depth="5" Or, (gdb) -stack-list-frames ^done,stack=[frame={level="0", .. snip lots .. }] gdb/ChangeLog: * frame.c (struct frame_info): Add stop_string field. (get_prev_frame_always_1): Renamed from get_prev_frame_always. (get_prev_frame_always): Old content moved into get_prev_frame_always_1. Call get_prev_frame_always_1 inside TRY_CATCH, handle MEMORY_ERROR exceptions. (frame_stop_reason_string): New function definition. * frame.h (unwind_stop_reason_to_string): Extend comment to mention frame_stop_reason_string. (frame_stop_reason_string): New function declaration. * stack.c (frame_info): Switch to frame_stop_reason_string. (backtrace_command_1): Switch to frame_stop_reason_string. * unwind_stop_reason.def: Add UNWIND_MEMORY_ERROR. (LAST_ENTRY): Changed to UNWIND_MEMORY_ERROR. * guile/lib/gdb.scm: Add FRAME_UNWIND_MEMORY_ERROR to export list. gdb/doc/ChangeLog: * guile.texi (Frames In Guile): Mention FRAME_UNWIND_MEMORY_ERROR. * python.texi (Frames In Python): Mention gdb.FRAME_UNWIND_MEMORY_ERROR. gdb/testsuite/ChangeLog: * gdb.arch/amd64-invalid-stack-middle.exp: Update expected results. * gdb.arch/amd64-invalid-stack-top.exp: Likewise.
2014-05-29 00:34:43 +02:00
2014-05-30 Andrew Burgess <aburgess@broadcom.com>
* gdb.arch/amd64-invalid-stack-middle.exp: Update expected
results.
* gdb.arch/amd64-invalid-stack-top.exp: Likewise.
Remove previous frame if an error occurs when computing frame id during unwind. https://sourceware.org/ml/gdb-patches/2014-05/msg00712.html If an error is thrown during computing a frame id then the frame is left in existence but without a valid frame id, this will trigger internal errors if/when the frame is later visited (for example in a backtrace). This patch catches errors raised while computing the frame id, and arranges for the new frame, the one without a frame id, to be removed from the linked list of frames. gdb/ChangeLog: * frame.c (remove_prev_frame): New function. (get_prev_frame_if_no_cycle): Create / discard cleanup using remove_prev_frame. gdb/testsuite/ChangeLog: * gdb.arch/amd64-invalid-stack-middle.S: New file. * gdb.arch/amd64-invalid-stack-middle.c: New file. * gdb.arch/amd64-invalid-stack-middle.exp: New file. * gdb.arch/amd64-invalid-stack-top.c: New file. * gdb.arch/amd64-invalid-stack-top.exp: New file.
2014-04-02 18:02:51 +02:00
2014-05-30 Andrew Burgess <aburgess@broadcom.com>
* gdb.arch/amd64-invalid-stack-middle.S: New file.
* gdb.arch/amd64-invalid-stack-middle.c: New file.
* gdb.arch/amd64-invalid-stack-middle.exp: New file.
* gdb.arch/amd64-invalid-stack-top.c: New file.
* gdb.arch/amd64-invalid-stack-top.exp: New file.
PR breakpoints/17000: user breakpoint not inserted if software-single-step at same location - test GDB gets confused when removing a software single-step breakpoint that is at the same address as another breakpoint. Add a kfailed test. gdb/testsuite/ 2014-05-30 Pedro Alves <palves@redhat.com> PR breakpoints/17000 * gdb.base/sss-bp-on-user-bp.c: New file. * gdb.base/sss-bp-on-user-bp.exp: New file.
2014-05-30 18:21:02 +02:00
2014-05-30 Pedro Alves <palves@redhat.com>
PR breakpoints/17000
* gdb.base/sss-bp-on-user-bp.c: New file.
* gdb.base/sss-bp-on-user-bp.exp: New file.
Use attribute to specify the required inlining semantics As suggested by Andrew Pinski. gdb/testsuite/ * gdb.opt/inline-break.c: Fix clang compatibility by specifying gnu_inline semantics via attribute. * gdb.opt/inline-break.exp: Remove -std=c89 now that the test source explicitly specifies the required semantics.
2014-05-30 13:20:50 +02:00
2014-05-30 David Blaikie <dblaikie@gmail.com>
* gdb.opt/inline-break.c: Fix clang compatibility by specifying
gnu_inline semantics via attribute.
* gdb.opt/inline-break.exp: Remove -std=c89 now that the test
source explicitly specifies the required semantics.
gdb.reverse/sigall-reverse.exp: Typo fix * gdb.reverse/sigall-reverse.exp: Fix a typo.
2014-05-30 05:14:17 +02:00
2014-05-30 Maciej W. Rozycki <macro@codesourcery.com>
* gdb.reverse/sigall-reverse.exp: Fix a typo.
enable target async by default; separate MI and target notions of async This finally makes background execution commands possible by default. However, in order to do that, there's one last thing we need to do -- we need to separate the MI and target notions of "async". Unlike the CLI, where the user explicitly requests foreground vs background execution in the execution command itself (c vs c&), MI chose to treat "set target-async" specially -- setting it changes the default behavior of execution commands. So, we can't simply "set target-async" default to on, as that would affect MI frontends. Instead we have to make the setting MI-specific, and teach MI about sync commands on top of an async target. Because the "target" word in "set target-async" ends up as a potential source of confusion, the patch adds a "set mi-async" option, and makes "set target-async" a deprecated alias. Rather than make the targets always async, this patch introduces a new "maint set target-async" option so that the GDB developer can control whether the target is async. This makes it simpler to debug issues arising only in the synchronous mode; important because sync mode seems unlikely to go away. Unlike in previous revisions, "set target-async" does not affect this new maint parameter. The rationale for this is that then one can easily run the test suite in the "maint set target-async off" mode and have tests that enable mi-async fail just like they fail on non-async-capable targets. This emulation is exactly the point of the maint option. I had asked Tom in a previous iteration to split the actual change of the target async default to a separate patch, but it turns out that that is quite awkward in this version of the patch, because with MI async and target async decoupled (unlike in previous versions), if we don't flip the default at the same time, then just "set target-async on" alone never actually manages to do anything. It's best to not have that transitory state in the tree. Given "set target-async on" now only has effect for MI, the patch goes through the testsuite removing it from non-MI tests. MI tests are adjusted to use the new and less confusing "mi-async" spelling. 2014-05-29 Pedro Alves <palves@redhat.com> Tom Tromey <tromey@redhat.com> * NEWS: Mention "maint set target-async", "set mi-async", and that background execution commands are now always available. * target.h (target_async_permitted): Update comment. * target.c (target_async_permitted, target_async_permitted_1): Default to 1. (set_target_async_command): Rename to ... (maint_set_target_async_command): ... this. (show_target_async_command): Rename to ... (maint_show_target_async_command): ... this. (_initialize_target): Adjust. * infcmd.c (prepare_execution_command): Make extern. * inferior.h (prepare_execution_command): Declare. * infrun.c (set_observer_mode): Leave target async alone. * mi/mi-interp.c (mi_interpreter_init): Install mi_on_sync_execution_done as sync_execution_done observer. (mi_on_sync_execution_done): New function. (mi_execute_command_input_handler): Don't print the prompt if we just started a synchronous command with an async target. (mi_on_resume): Check sync_execution before printing prompt. * mi/mi-main.h (mi_async_p): Declare. * mi/mi-main.c: Include gdbcmd.h. (mi_async_p): New function. (mi_async, mi_async_1): New globals. (set_mi_async_command, show_mi_async_command, mi_async): New functions. (exec_continue): Call prepare_execution_command. (run_one_inferior, mi_cmd_exec_run, mi_cmd_list_target_features) (mi_execute_async_cli_command): Use mi_async_p. (_initialize_mi_main): Install "set mi-async". Make "target-async" a deprecated alias. 2014-05-29 Pedro Alves <palves@redhat.com> Tom Tromey <tromey@redhat.com> * gdb.texinfo (Non-Stop Mode): Remove "set target-async 1" from example. (Asynchronous and non-stop modes): Document '-gdb-set mi-async'. Mention that target-async is now deprecated. (Maintenance Commands): Document maint set/show target-async. 2014-05-29 Pedro Alves <palves@redhat.com> Tom Tromey <tromey@redhat.com> * gdb.base/async-shell.exp: Don't enable target-async. * gdb.base/async.exp * gdb.base/corefile.exp (corefile_test_attach): Remove 'async' parameter. Adjust. (top level): Don't test with "target-async". * gdb.base/dprintf-non-stop.exp: Don't enable target-async. * gdb.base/gdb-sigterm.exp: Don't test with "target-async". * gdb.base/inferior-died.exp: Don't enable target-async. * gdb.base/interrupt-noterm.exp: Likewise. * gdb.mi/mi-async.exp: Use "mi-async" instead of "target-async". * gdb.mi/mi-nonstop-exit.exp: Likewise. * gdb.mi/mi-nonstop.exp: Likewise. * gdb.mi/mi-ns-stale-regcache.exp: Likewise. * gdb.mi/mi-nsintrall.exp: Likewise. * gdb.mi/mi-nsmoribund.exp: Likewise. * gdb.mi/mi-nsthrexec.exp: Likewise. * gdb.mi/mi-watch-nonstop.exp: Likewise. * gdb.multi/watchpoint-multi.exp: Adjust comment. * gdb.python/py-evsignal.exp: Don't enable target-async. * gdb.python/py-evthreads.exp: Likewise. * gdb.python/py-prompt.exp: Likewise. * gdb.reverse/break-precsave.exp: Don't test with "target-async". * gdb.server/solib-list.exp: Don't enable target-async. * gdb.threads/thread-specific-bp.exp: Likewise. * lib/mi-support.exp: Adjust to use mi-async.
2014-05-29 20:58:57 +02:00
2014-05-29 Pedro Alves <palves@redhat.com>
Tom Tromey <tromey@redhat.com>
* gdb.base/async-shell.exp: Don't enable target-async.
* gdb.base/async.exp
* gdb.base/corefile.exp (corefile_test_attach): Remove 'async'
parameter. Adjust.
(top level): Don't test with "target-async".
* gdb.base/dprintf-non-stop.exp: Don't enable target-async.
* gdb.base/gdb-sigterm.exp: Don't test with "target-async".
* gdb.base/inferior-died.exp: Don't enable target-async.
* gdb.base/interrupt-noterm.exp: Likewise.
* gdb.mi/mi-async.exp: Use "mi-async" instead of "target-async".
* gdb.mi/mi-nonstop-exit.exp: Likewise.
* gdb.mi/mi-nonstop.exp: Likewise.
* gdb.mi/mi-ns-stale-regcache.exp: Likewise.
* gdb.mi/mi-nsintrall.exp: Likewise.
* gdb.mi/mi-nsmoribund.exp: Likewise.
* gdb.mi/mi-nsthrexec.exp: Likewise.
* gdb.mi/mi-watch-nonstop.exp: Likewise.
* gdb.multi/watchpoint-multi.exp: Adjust comment.
* gdb.python/py-evsignal.exp: Don't enable target-async.
* gdb.python/py-evthreads.exp: Likewise.
* gdb.python/py-prompt.exp: Likewise.
* gdb.reverse/break-precsave.exp: Don't test with "target-async".
* gdb.server/solib-list.exp: Don't enable target-async.
* gdb.threads/thread-specific-bp.exp: Likewise.
* lib/mi-support.exp: Adjust to use mi-async.
PR gdb/13860 - Make MI sync vs async output (closer to) the same. Ignoring expected and desired differences like whether the prompt is output after *stoppped records, GDB MI output is still different in sync and async modes. In sync mode, when a CLI execution command is entered, the "reason" field is missing in the *stopped async record. And in async mode, for some events, like program exits, the corresponding CLI output is missing in the CLI channel. Vis, diff between sync vs async modes: run ^running *running,thread-id="1" (gdb) ... - ~"[Inferior 1 (process 15882) exited normally]\n" =thread-exited,id="1",group-id="i1" =thread-group-exited,id="i1",exit-code="0" - *stopped + *stopped,reason="exited-normally" si ... (gdb) ~"0x000000000045e033\t29\t memset (&args, 0, sizeof args);\n" - *stopped,frame=...,thread-id="1",stopped-threads="all",core="0" + *stopped,reason="end-stepping-range",frame=...,thread-id="1",stopped-threads="all",core="0" (gdb) In addition, in both cases, when a MI execution command is entered, and a breakpoint triggers, the event is sent to the console too. But some events like program exits have the CLI output missing in the CLI channel: -exec-run ^running *running,thread-id="1" (gdb) ... =thread-exited,id="1",group-id="i1" =thread-group-exited,id="i1",exit-code="0" - *stopped + *stopped,reason="exited-normally" We'll want to make background commands always possible by default. IOW, make target-async be the default. But, in order to do that, we'll need to emulate MI sync on top of an async target. That means we'll have yet another combination to care for in the testsuite. Rather than making the testsuite cope with all these differences, I thought it better to just fix GDB to always have the complete output, no matter whether it's in sync or async mode. This is all related to interpreter-exec, and the corresponding uiout switching. (Typing a CLI command directly in MI is shorthand for running it through -interpreter-exec console.) In sync mode, when a CLI command is active, normal_stop is called when the current interpreter and uiout are CLI's. So print_XXX_reason prints the stop reason to CLI uiout (only), and we don't show it in MI. In async mode the stop event is processed when we're back in the MI interpreter, so the stop reason is printed directly to the MI uiout. Fix this by making run control event printing roughly independent of whatever is the current interpreter or uiout. That is, move these prints to interpreter observers, that know whether to print or be quiet, and if printing, which uiout to print to. In the case of the console/tui interpreters, only print if the top interpreter. For MI, always print. Breakpoint hits / normal stops are already handled similarly -- MI has a normal_stop observer that prints the event to both MI and the CLI, though that could be cleaned up further in the direction of this patch. This also makes all of: (gdb) foo and (gdb) interpreter-exec MI "-exec-foo" and (gdb) -exec-foo and (gdb) -interpreter-exec console "foo" print as expected. Tested on x86_64 Fedora 20, sync and async modes. gdb/ 2014-05-29 Pedro Alves <palves@redhat.com> PR gdb/13860 * cli/cli-interp.c: Include infrun.h and observer.h. (cli_uiout, cli_interp): New globals. (cli_on_signal_received, cli_on_end_stepping_range) (cli_on_signal_exited, cli_on_exited, cli_on_no_history): New functions. (cli_interpreter_init): Install them as 'end_stepping_range', 'signal_received' 'signal_exited', 'exited' and 'no_history' observers. (_initialize_cli_interp): Remove cli_interp local. * infrun.c (handle_inferior_event): Call the several stop reason observers instead of printing the stop reason directly. (end_stepping_range): New function. (print_end_stepping_range_reason, print_signal_exited_reason) (print_exited_reason, print_signal_received_reason) (print_no_history_reason): Make static, and add an uiout parameter. Print to that instead of to CURRENT_UIOUT. * infrun.h (print_end_stepping_range_reason) (print_signal_exited_reason, print_exited_reason) (print_signal_received_reason print_no_history_reason): New declarations. * mi/mi-common.h (struct mi_interp): Rename 'uiout' field to 'mi_uiout'. <cli_uiout>: New field. * mi/mi-interp.c (mi_interpreter_init): Adjust. Create the new uiout for CLI output. Install 'signal_received', 'end_stepping_range', 'signal_exited', 'exited' and 'no_history' observers. (find_mi_interpreter, mi_interp_data, mi_on_signal_received) (mi_on_end_stepping_range, mi_on_signal_exited, mi_on_exited) (mi_on_no_history): New functions. (ui_out_free_cleanup): Delete function. (mi_on_normal_stop): Don't allocate a new uiout for CLI output, instead use the one already stored in the MI interpreter data. (mi_ui_out): Adjust. * tui/tui-interp.c: Include infrun.h and observer.h. (tui_interp): New global. (tui_on_signal_received, tui_on_end_stepping_range) (tui_on_signal_exited, tui_on_exited) (tui_on_no_history): New functions. (tui_init): Install them as 'end_stepping_range', 'signal_received' 'signal_exited', 'exited' and 'no_history' observers. (_initialize_tui_interp): Delete tui_interp local. gdb/doc/ 2014-05-29 Pedro Alves <palves@redhat.com> PR gdb/13860 * observer.texi (signal_received, end_stepping_range) (signal_exited, exited, no_history): New observer subjects. gdb/testsuite/ 2014-05-29 Pedro Alves <palves@redhat.com> PR gdb/13860 * gdb.mi/mi-cli.exp: Always expect "end-stepping-range" stop reason, even in sync mode.
2014-05-29 14:09:45 +02:00
2014-05-29 Pedro Alves <palves@redhat.com>
PR gdb/13860
* gdb.mi/mi-cli.exp: Always expect "end-stepping-range" stop
reason, even in sync mode.
PR15693 - Fix spurious *running events, thread state, dprintf-style call If one sets a breakpoint with a condition that involves calling a function in the inferior, and then the condition evaluates false, GDB outputs one *running event for each time the program hits the breakpoint. E.g., $ gdb return-false -i=mi (gdb) start ... (gdb) b 14 if return_false () &"b 14 if return_false ()\n" ~"Breakpoint 2 at 0x4004eb: file return-false.c, line 14.\n" ... ^done (gdb) c &"c\n" ~"Continuing.\n" ^running *running,thread-id=(...) (gdb) *running,thread-id=(...) *running,thread-id=(...) *running,thread-id=(...) *running,thread-id=(...) *running,thread-id=(...) ... repeat forever ... An easy way a user can trip on this is with a dprintf with "set dprintf-style call". In that case, a dprintf is just a breakpoint that when hit GDB calls the printf function in the inferior, and then resumes it, just like the case above. If the breakpoint/dprintf is set in a loop, then these spurious events can potentially slow down a frontend much, if it decides to refresh its GUI whenever it sees this event (Eclipse is one such case). When we run an infcall, we pretend we don't actually run the inferior. This is already handled for the usual case of calling a function directly from the CLI: (gdb) p return_false () &"p return_false ()\n" ~"$1 = 0" ~"\n" ^done (gdb) Note no *running, nor *stopped events. That's handled by: static void mi_on_resume (ptid_t ptid) { ... /* Suppress output while calling an inferior function. */ if (tp->control.in_infcall) return; and equivalent code on normal_stop. However, in the cases of the PR, after finishing the infcall there's one more resume, and mi_on_resume doesn't know that it should suppress output then too, somehow. The "running/stopped" state is a high level user/frontend state. Internal stops are invisible to the frontend. If follows from that that we should be setting the thread to running at a higher level where we still know the set of threads the user _intends_ to resume. Currently we mark a thread as running from within target_resume, a low level target operation. As consequence, today, if we resume a multi-threaded program while stopped at a breakpoint, we see this: -exec-continue ^running *running,thread-id="1" (gdb) *running,thread-id="all" The first *running was GDB stepping over the breakpoint, and the second is GDB finally resuming everything. Between those two *running's, threads other than "1" still have their state set to stopped. That's bogus -- in async mode, this opens a tiny window between both resumes where the user might try to run another execution command to threads other than thread 1, and very much confuse GDB. That is, the "step" below should fail the "step", complaining that the thread is running: (gdb) c -a & (gdb) thread 2 (gdb) step IOW, threads that GDB happens to not resume immediately (say, because it needs to step over a breakpoint) shall still be marked as running. Then, if we move marking threads as running to a higher layer, decoupled from target_resume, plus skip marking threads as running when running an infcall, the spurious *running events disappear, because there will be no state transitions at all. I think we might end up adding a new thread state -- THREAD_INFCALL or some such, however since infcalls are always synchronous today, I didn't find a need. There's no way to execute a CLI/MI command directly from the prompt if some thread is running an infcall. Tested on x86_64 Fedora 20. gdb/ 2014-05-29 Pedro Alves <palves@redhat.com> PR PR15693 * infrun.c (resume): Determine how much to resume depending on whether the caller wanted a step, not whether we can hardware step the target. Mark all threads that we intend to run as running, unless we're calling an inferior function. (normal_stop): If the thread is running an infcall, don't finish thread state. * target.c (target_resume): Don't mark threads as running here. gdb/testsuite/ 2014-05-29 Pedro Alves <palves@redhat.com> Hui Zhu <hui@codesourcery.com> PR PR15693 * gdb.mi/mi-condbreak-call-thr-state-mt.c: New file. * gdb.mi/mi-condbreak-call-thr-state-st.c: New file. * gdb.mi/mi-condbreak-call-thr-state.c: New file. * gdb.mi/mi-condbreak-call-thr-state.exp: New file.
2014-05-29 13:27:01 +02:00
2014-05-29 Pedro Alves <palves@redhat.com>
Hui Zhu <hui@codesourcery.com>
PR PR15693
* gdb.mi/mi-condbreak-call-thr-state-mt.c: New file.
* gdb.mi/mi-condbreak-call-thr-state-st.c: New file.
* gdb.mi/mi-condbreak-call-thr-state.c: New file.
* gdb.mi/mi-condbreak-call-thr-state.exp: New file.
Remove "set/show remotebaud" (deprecated) commands. This patch removes support for the "set/show remotebaud" command, which were deprecated in GDB 7.7, and should be now be removed ahead of cutting the GDB 7.8 branch. gdb/ChangeLog: * serial.c (_initialize_serial): Remove support for the "set remotebaud" and "show remotebaud" commands. * NEWS: Add entry documenting the removal of that command. gdb/testsuite/ChangeLog: * config/monitor.exp (gdb_target_monitor): Replace use of "set remotebaud" by "set serial baud".
2014-05-19 20:46:19 +02:00
2014-05-28 Joel Brobecker <brobecker@adacore.com>
* config/monitor.exp (gdb_target_monitor): Replace use of
"set remotebaud" by "set serial baud".
gdb smob cleanups * guile/guile-internal.h (GDB_SMOB_HEAD): Replace properties with empty_base_class. All uses updated. (gdbscm_mark_gsmob, gdbscm_mark_chained_gsmob) (gdbscm_mark_eqable_gsmob): Remove these now-unneeded functions. Adapt all callers. * guile/scm-gsmob.c (gdbscm_mark_gsmob) (gdbscm_mark_chained_gsmob, gdbscm_mark_eqable_gsmob): Remove. (gdbscm_gsmob_property, gdbscm_set_gsmob_property_x) (gdbscm_gsmob_has_property_p, add_property_name) (gdbscm_gsmob_properties): Remove, and remove them from gsmob_functions. * guile/lib/gdb.scm (gdb-object-property, set-gdb-object-property) (gdb-object-has-property?, gdb-object-properties): Remove. (gdb-object-kind): Renamed from gsmob-kind. doc/ * guile.texi (GDB Scheme Data Types): Remove documentation for removed interfaces. Update spelling of gdb-object-kind. testsuite/ * gdb.guile/scm-breakpoint.exp: * gdb.guile/scm-gsmob.exp: Update to use plain old object properties instead of gdb-object-properties.
2014-05-27 02:34:27 +02:00
2014-05-26 Andy Wingo <wingo@igalia.com>
* gdb.guile/scm-breakpoint.exp:
* gdb.guile/scm-gsmob.exp: Update to use plain old object
properties instead of gdb-object-properties.
Specify source file explicitly when setting a breakpoint When I run no-thread-db.exp, the breakpoint is set on line 26. However, the breakpoint is set to line 26 of dl-start.S rather than no-thread-db.c, which is not intended. (gdb) monitor set libthread-db-search-path /foo/bar^M libthread-db-search-path set to `/foo/bar'^M (gdb) PASS: gdb.server/no-thread-db.exp: libthread-db is now unresolvable break 26^M Breakpoint 1 at 0x48018078: file ../sysdeps/powerpc/powerpc32/dl-start.S, line 26.^M (gdb) continue^M Continuing. This patch is to change the breakpoint setting with source file specified, then it is correct now. gdb/testsuite: 2014-05-26 Yao Qi <yao@codesourcery.com> * gdb.server/no-thread-db.exp: Specify source file name explicitly when setting a breakpoint.
2014-05-20 07:45:54 +02:00
2014-05-26 Yao Qi <yao@codesourcery.com>
* gdb.server/no-thread-db.exp: Specify source file name
explicitly when setting a breakpoint.
btrace, vdso: add vdso target sections When loading symbols for the vdso, also add its sections to target_sections. This fixes an issue with record btrace where vdso instructions could not be disassembled during replay. * symfile-mem.c (symbol_file_add_from_memory): Add BFD sections. testsuite/ * gdb.btrace/vdso.c: New. * gdb.btrace/vdso.exp: New.
2014-04-02 09:54:11 +02:00
2014-05-23 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/vdso.c: New.
* gdb.btrace/vdso.exp: New.
test, gcore: move capture_command_output into lib/gdb.exp Allow gcore's capture_command_output function to be used by other tests. testsuite/ * gdb.base/gcore.exp (capture_command_output): Move ... * lib/gdb.exp (capture_command_output): ... here.
2014-05-20 09:48:43 +02:00
2014-05-23 Markus Metzger <markus.t.metzger@intel.com>
* gdb.base/gcore.exp (capture_command_output): Move ...
* lib/gdb.exp (capture_command_output): ... here.
btrace: control memory access during replay The btrace record target does not trace data. We therefore do not allow accessing read-write memory during replay. In some cases, this might be useful to advanced users, though, who we assume to know what they are doing. Add a set|show command pair to turn this memory access restriction off. * record-btrace.c (record_btrace_allow_memory_access): Remove. (replay_memory_access_read_only, replay_memory_access_read_write) (replay_memory_access_types, replay_memory_access) (set_record_btrace_cmdlist, show_record_btrace_cmdlist) (cmd_set_record_btrace, cmd_show_record_btrace) (cmd_show_replay_memory_access): New. (record_btrace_xfer_partial, record_btrace_insert_breakpoint) (record_btrace_remove_breakpoint): Replace record_btrace_allow_memory_access with replay_memory_access. (_initialize_record_btrace): Add commands. * NEWS: Announce it. testsuite/ * gdb.btrace/data.exp: Test it. doc/ * gdb.texinfo (Process Record and Replay): Document it.
2014-03-05 15:38:11 +01:00
2014-05-23 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/data.exp: Test memory access during btrace replay.
Add comment for mi_run_cmd_full It should clear up confusion about the args parameter to mi_run_cmd_full. Thanks to Joel for clear formulation. I also added a comment about the impact of use_gdb_stub. gdb/testsuite/ChangeLog: 2014-05-22 Simon Marchi <simon.marchi@ericsson.com> * lib/mi-support.exp (mi_run_cmd_full): Add comments.
2014-05-22 20:01:46 +02:00
2014-05-22 Simon Marchi <simon.marchi@ericsson.com>
* lib/mi-support.exp (mi_run_cmd_full): Add comments.
PR gdb/13860: don't lose '-interpreter-exec console EXECUTION_COMMAND''s output in async mode. The other part of PR gdb/13860 is about console execution commands in MI getting their output half lost. E.g., take the finish command, executed on a frontend's GDB console: sync: finish &"finish\n" ~"Run till exit from #0 usleep (useconds=10) at ../sysdeps/unix/sysv/linux/usleep.c:27\n" ^running *running,thread-id="1" (gdb) ~"0x00000000004004d7 in foo () at stepinf.c:6\n" ~"6\t usleep (10);\n" ~"Value returned is $1 = 0\n" *stopped,reason="function-finished",frame={addr="0x00000000004004d7",func="foo",args=[],file="stepinf.c",fullname="/home/pedro/gdb/tests/stepinf.c",line="6"},thread-id="1",stopped-threads="all",core="1" async: finish &"finish\n" ~"Run till exit from #0 usleep (useconds=10) at ../sysdeps/unix/sysv/linux/usleep.c:27\n" ^running *running,thread-id="1" (gdb) *stopped,reason="function-finished",frame={addr="0x00000000004004d7",func="foo",args=[],file="stepinf.c",fullname="/home/pedro/gdb/tests/stepinf.c",line="6"},gdb-result-var="$1",return-value="0",thread-id="1",stopped-threads="all",core="0" Note how all the "Value returned" etc. output is missing in async mode. The same happens with e.g., catchpoints: =breakpoint-modified,bkpt={number="1",type="catchpoint",disp="keep",enabled="y",what="22016",times="1"} ~"\nCatchpoint " ~"1 (forked process 22016), 0x0000003791cbd8a6 in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:131\n" ~"131\t pid = ARCH_FORK ();\n" *stopped,reason="fork",disp="keep",bkptno="1",newpid="22016",frame={addr="0x0000003791cbd8a6",func="__libc_fork",args=[],file="../nptl/sysdeps/unix/sysv/linux/fork.c",fullname="/usr/src/debug/glibc-2.14-394-g8f3b1ff/nptl/sysdeps/unix/sysv/linux/fork.c",line="131"},thread-id="1",stopped-threads="all",core="0" where all those ~ lines are missing in async mode, or just the "step" current line indication: s &"s\n" ^running *running,thread-id="all" (gdb) ~"13\t foo ();\n" *stopped,frame={addr="0x00000000004004ef",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffdd78"}],file="stepinf.c",fullname="/home/pedro/gdb/tests/stepinf.c",line="13"},thread-id="1",stopped-threads="all",core="3" (gdb) Or in the case of the PRs example, the "Stopped due to shared library event" note: start &"start\n" ~"Temporary breakpoint 1 at 0x400608: file ../../../src/gdb/testsuite/gdb.mi/solib-main.c, line 21.\n" =breakpoint-created,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000000400608",func="main",file="../../../src/gdb/testsuite/gdb.mi/solib-main.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/solib-main.c",line="21",times="0",original-location="main"} ~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n" =thread-group-started,id="i1",pid="21990" =thread-created,id="1",group-id="i1" ^running *running,thread-id="all" (gdb) =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1" ~"Stopped due to shared library event (no libraries added or removed)\n" *stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="3" (gdb) IMO, if you're typing execution commands in a frontend's console, you expect to see their output. Indeed it's what you get in sync mode. I think async mode should do the same. Deciding what to mirror to the console wrt to breakpoints and random stops gets messy real fast. E.g., say "s" trips on a breakpoint. We'd clearly want to mirror the event to the console in this case. But what about more complicated cases like "s&; thread n; s&", and one of those steps spawning a new thread, and that thread hitting a breakpoint? It's impossible in general to track whether the thread had any relation to the commands that had been executed. So I think we should just simplify and always mirror breakpoints and random events to the console. Notes: - mi->out is the same as gdb_stdout when MI is the current interpreter. I think that referring to that directly is cleaner. An earlier revision of this patch made the changes that are now done in mi_on_normal_stop directly in infrun.c:normal_stop, and so not having an obvious place to put the new uiout by then, and not wanting to abuse CLI's uiout, I made a temporary uiout when necessary. - Hopefuly the rest of the patch is more or less obvious given the comments added. Tested on x86_64 Fedora 20, no regressions. 2014-05-21 Pedro Alves <palves@redhat.com> PR gdb/13860 * gdbthread.h (struct thread_control_state): New field `command_interp'. * infrun.c (follow_fork): Copy the new thread control field to the child fork thread. (clear_proceed_status_thread): Clear the new thread control field. (proceed): Set the new thread control field. * interps.h (command_interp): Declare. * interps.c (command_interpreter): New global. (command_interp): New function. (interp_exec): Set `command_interpreter' while here. * cli-out.c (cli_uiout_dtor): New function. (cli_ui_out_impl): Install it. * mi/mi-interp.c: Include cli-out.h. (mi_cmd_interpreter_exec): Add comment. (restore_current_uiout_cleanup): New function. (ui_out_free_cleanup): New function. (mi_on_normal_stop): If finishing an execution command started by a CLI command, or any kind of breakpoint-like event triggered, print the stop event to the output (CLI) stream. * mi/mi-out.c (mi_ui_out_impl): Install NULL `dtor' handler. 2014-05-21 Pedro Alves <palves@redhat.com> PR gdb/13860 * gdb.mi/mi-cli.exp (line_callee4_next_step): New global. (top level): Test that output related to execution commands is sent to the console with CLI commands, but not with MI commands. Test that breakpoint events are always mirrored to the console. Also expect the new source line to be output after a "next" in async mode too. Make it a pass/fail test. * gdb.mi/mi-solib.exp: Test that the CLI solib event note is output. * lib/mi-support.exp (mi_gdb_expect_cli_output): New procedure.
2014-03-11 21:31:36 +01:00
2014-05-21 Pedro Alves <palves@redhat.com>
PR gdb/13860
* gdb.mi/mi-cli.exp (line_callee4_next_step): New global.
(top level): Test that output related to execution commands is
sent to the console with CLI commands, but not with MI commands.
Test that breakpoint events are always mirrored to the console.
Also expect the new source line to be output after a "next" in
async mode too. Make it a pass/fail test.
* gdb.mi/mi-solib.exp: Test that the CLI solib event note is
output.
* lib/mi-support.exp (mi_gdb_expect_cli_output): New procedure.
PR gdb/13860: make -interpreter-exec console "list" behave more like "list". I noticed that "list" behaves differently in CLI vs MI. Particularly: $ ./gdb -nx -q ./testsuite/gdb.mi/mi-cli Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/mi-cli...done. (gdb) start Temporary breakpoint 1 at 0x40054d: file ../../../src/gdb/testsuite/gdb.mi/basics.c, line 62. Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/mi-cli Temporary breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.mi/basics.c:62 62 callee1 (2, "A string argument.", 3.5); (gdb) list 57 { 58 } 59 60 main () 61 { 62 callee1 (2, "A string argument.", 3.5); 63 callee1 (2, "A string argument.", 3.5); 64 65 do_nothing (); /* Hello, World! */ 66 (gdb) Note the list started at line 57. IOW, the program stopped at line 62, and GDB centered the list on that. compare with: $ ./gdb -nx -q ./testsuite/gdb.mi/mi-cli -i=mi =thread-group-added,id="i1" ~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/mi-cli..." ~"done.\n" (gdb) start &"start\n" ... ~"\nTemporary breakpoint " ~"1, main () at ../../../src/gdb/testsuite/gdb.mi/basics.c:62\n" ~"62\t callee1 (2, \"A string argument.\", 3.5);\n" *stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x000000000040054d",func="main",args=[],file="../../../src/gdb/testsuite/gdb.mi/basics.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/basics.c",line="62"},thread-id="1",stopped-threads="all",core="0" =breakpoint-deleted,id="1" (gdb) -interpreter-exec console list ~"62\t callee1 (2, \"A string argument.\", 3.5);\n" ~"63\t callee1 (2, \"A string argument.\", 3.5);\n" ~"64\t\n" ~"65\t do_nothing (); /* Hello, World! */\n" ~"66\t\n" ~"67\t callme (1);\n" ~"68\t callme (2);\n" ~"69\t\n" ~"70\t return 0;\n" ~"71\t}\n" ^done (gdb) Here the list starts at line 62, where the program was stopped. This happens because print_stack_frame, called from both normal_stop and mi_on_normal_stop, is the function responsible for setting the current sal from the selected frame, overrides the PRINT_WHAT argument, and only after that does it decide whether to center the current sal line or not, based on the overridden value, and it will always decide false. (The print_stack_frame call in mi_on_normal_stop is a little different from the call in normal_stop, in that it is an unconditional SRC_AND_LOC call. A future patch will make those uniform.) A previous version of this patch made MI uniform with CLI here, by making print_stack_frame also center when MI is active. That changed the output of a "list" command in mi-cli.exp, to expect line 57 instead of 62, as per the example above. However, looking deeper, that list in question is the first "list" after the program stops, and right after the stop, before the "list", the test did "set listsize 1". Let's try the same thing with the CLI: (gdb) start 62 callee1 (2, "A string argument.", 3.5); (gdb) set listsize 1 (gdb) list 57 { Huh, that's unexpected. Why the 57? It's because print_stack_frame, called in reaction to the breakpoint stop, expecting the next "list" to show 10 lines (the listsize at the time) around line 62, sets the lines listed range to 57-67 (62 +/- 5). If the user changes the listsize before "list", why would we still show that range? Looks bogus to me. So the fix for this whole issue should be delay trying to center the listing to until actually listing, so that the correct listsize can be taken into account. This makes MI and CLI uniform too, as it deletes the center code from print_stack_frame. A series of tests are added to list.exp to cover this. mi-cli.exp was after all correct all along, but it now gains an additional test that lists lines with listsize 10, to ensure the centering is consistent with CLI's. One related Python test changed related output -- it's a test that prints the line number after stopping for a breakpoint, similar to the new list.exp tests. Previously we'd print the stop line minus 5 (due to the premature centering), now we print the stop line. I think that's a good change. Tested on x86_64 Fedora 20. gdb/ 2014-05-21 Pedro Alves <palves@redhat.com> * cli/cli-cmds.c (list_command): Handle the first "list" after the current source line having changed. * frame.h (set_current_sal_from_frame): Remove 'center' parameter. * infrun.c (normal_stop): Adjust call to set_current_sal_from_frame. * source.c (clear_lines_listed_range): New function. (set_current_source_symtab_and_line, identify_source_line): Clear the lines listed range. (line_info): Handle the first "info line" after the current source line having changed. * stack.c (print_stack_frame): Remove center handling. (set_current_sal_from_frame): Remove 'center' parameter. Don't center sal.line. gdb/testsuite/ 2014-05-21 Pedro Alves <palves@redhat.com> * gdb.base/list.exp (build_pattern, test_list): New procedures. Use them to test variations of "list" after reaching a breakpoint. * gdb.mi/mi-cli.exp (line_main_callme_2): New global. Test "list" with listsize 10 after reaching a breakpoint. * gdb.python/python.exp (decode_line current location line number): Adjust expected line number.
2014-05-22 00:15:27 +02:00
2014-05-21 Pedro Alves <palves@redhat.com>
* gdb.base/list.exp (build_pattern, test_list): New procedures.
Use them to test variations of "list" after reaching a breakpoint.
* gdb.mi/mi-cli.exp (line_main_callme_2): New global.
Test "list" with listsize 10 after reaching a breakpoint.
* gdb.python/python.exp (decode_line current location line
number): Adjust expected line number.
Revert "Fix argument passing in mi_run_cmd_full" This reverts commit 8c217a4b684386aa5ce6a078dffbe63265a524e6. Following this https://sourceware.org/ml/gdb-patches/2014-05/msg00462.html I suggest reverting my previous commit. I will follow with another patch to add comments, to clarify some things as stated in the mail thread. I ran make check with on gdb.mi, and the test that the commit broke passes again. gdb/testsuite/ChangeLog: 2014-05-21 Simon Marchi <simon.marchi@ericsson.com> * lib/mi-support.exp (mi_run_cmd_full): Revert to original behavior for $args, pass it directly to "run".
2014-05-21 23:22:48 +02:00
2014-05-21 Simon Marchi <simon.marchi@ericsson.com>
* lib/mi-support.exp (mi_run_cmd_full): Revert to original
behavior for $args, pass it directly to "run".
gdb/testsuite: Bump up `match_max' This fixes: PASS: gdb.base/info-macros.exp: info macro -a -- FOO ERROR: internal buffer is full. UNRESOLVED: gdb.base/info-macros.exp: info macros 2 ERROR: internal buffer is full. UNRESOLVED: gdb.base/info-macros.exp: info macros 3 ERROR: internal buffer is full. UNRESOLVED: gdb.base/info-macros.exp: info macros 4 FAIL: gdb.base/info-macros.exp: info macros *$pc ERROR: internal buffer is full. UNRESOLVED: gdb.base/info-macros.exp: next FAIL: gdb.base/info-macros.exp: info macros ERROR: internal buffer is full. UNRESOLVED: gdb.base/info-macros.exp: next FAIL: gdb.base/info-macros.exp: info macros 6 ERROR: internal buffer is full. UNRESOLVED: gdb.base/info-macros.exp: next FAIL: gdb.base/info-macros.exp: info macros 7 ERROR: internal buffer is full. UNRESOLVED: gdb.base/info-macros.exp: info macros info-macros.c:42 (PRMS gdb/NNNN) with the arm-eabi target tested on the i686-mingw32 host where GCC defines enough macros to exhaust expect's 30000 characters of buffer space. * lib/gdb.exp (default_gdb_init): Bump `match_max' up from 30000 to 65536.
2014-05-21 21:34:57 +02:00
2014-05-21 Maciej W. Rozycki <macro@codesourcery.com>
* lib/gdb.exp (default_gdb_init): Bump `match_max' up from
30000 to 65536.
Allow making GDB not automatically connect to the native target. Sometimes it's useful to be able to disable the automatic connection to the native target. E.g., sometimes GDB disconnects from the extended-remote target I was debugging, without me noticing it, and then I do "run". That starts the program locally, and only after a little head scratch session do I figure out the program is running locally instead of remotely as intended. Same thing with "attach", "info os", etc. With the patch, we now can have this instead: (gdb) set auto-connect-native-target off (gdb) target extended-remote :9999 ... *gdb disconnects* (gdb) run Don't know how to run. Try "help target". To still be able to connect to the native target with auto-connect-native-target set to off, I've made "target native" work instead of erroring out as today. Before: (gdb) target native Use the "run" command to start a native process. After: (gdb) target native Done. Use the "run" command to start a process. (gdb) maint print target-stack The current target stack is: - native (Native process) - exec (Local exec file) - None (None) (gdb) run Starting program: ./a.out ... I've also wanted this for the testsuite, when running against the native-extended-gdbserver.exp board (runs against gdbserver in extended-remote mode). With a non-native-target board, it's always a bug to launch a program with the native target. Turns out we still have one such case this patch catches: (gdb) break main Breakpoint 1 at 0x4009e5: file ../../../src/gdb/testsuite/gdb.base/coremaker.c, line 138. (gdb) run Don't know how to run. Try "help target". (gdb) FAIL: gdb.base/corefile.exp: run: with core On the patch itself, probably the least obvious bit is the need to go through all targets, and move the unpush_target call to after the generic_mourn_inferior call instead of before. This is what inf-ptrace.c does too, ever since multi-process support was added. The reason inf-ptrace.c does things in that order is that in the current multi-process/single-target model, we shouldn't unpush the target if there are still other live inferiors being debugged. The check for that is "have_inferiors ()" (a misnomer nowadays...), which does: have_inferiors (void) { for (inf = inferior_list; inf; inf = inf->next) if (inf->pid != 0) return 1; It's generic_mourn_inferior that ends up clearing inf->pid, so we need to call it before the have_inferiors check. To make all native targets behave the same WRT to explicit "target native", I've added an inf_child_maybe_unpush_target function that targets call instead of calling unpush_target directly, and as that includes the have_inferiors check, I needed to adjust the targets. Tested on x86_64 Fedora 20, native, and also with the extended-gdbserver board. Confirmed a cross build of djgpp gdb still builds. Smoke tested a cross build of Windows gdb under Wine. Untested otherwise. gdb/ 2014-05-21 Pedro Alves <palves@redhat.com> * inf-child.c (inf_child_ops, inf_child_explicitly_opened): New globals. (inf_child_open_target): New function. (inf_child_open): Use inf_child_open_target to push the target instead of erroring out. (inf_child_disconnect, inf_child_close) (inf_child_maybe_unpush_target): New functions. (inf_child_target): Install inf_child_disconnect and inf_child_close. Store a pointer to the returned object. * inf-child.h (inf_child_open_target, inf_child_maybe_unpush): New declarations. * target.c (auto_connect_native_target): New global. (show_default_run_target): New function. (find_default_run_target): Return NULL if automatically connecting to the native target is disabled. (_initialize_target): Install set/show auto-connect-native-target. * NEWS: Mention "set auto-connect-native-target", and "target native". * linux-nat.c (super_close): New global. (linux_nat_close): Call super_close. (linux_nat_add_target): Store a pointer to the base class's to_close method. * inf-ptrace.c (inf_ptrace_mourn_inferior, inf_ptrace_detach): Use inf_child_maybe_unpush. * inf-ttrace.c (inf_ttrace_him): Don't push the target if it is already pushed. (inf_ttrace_mourn_inferior): Only unpush the target after mourning the inferior. Use inf_child_maybe_unpush_target. (inf_ttrace_attach): Don't push the target if it is already pushed. (inf_ttrace_detach): Use inf_child_maybe_unpush_target. * darwin-nat.c (darwin_mourn_inferior): Only unpush the target after mourning the inferior. Use inf_child_maybe_unpush_target. (darwin_attach_pid): Don't push the target if it is already pushed. * gnu-nat.c (gnu_mourn_inferior): Only unpush the target after mourning the inferior. Use inf_child_maybe_unpush_target. (gnu_detach): Use inf_child_maybe_unpush_target. * go32-nat.c (go32_create_inferior): Don't push the target if it is already pushed. (go32_mourn_inferior): Use inf_child_maybe_unpush_target. * nto-procfs.c (procfs_is_nto_target): Adjust comment. (procfs_open): Rename to ... (procfs_open_1): ... this. Add target_ops parameter. Adjust comments. Can target_preopen before changing node. Call inf_child_open_target to push the target explicitly. (procfs_attach): Don't push the target if it is already pushed. (procfs_detach): Use inf_child_maybe_unpush_target. (procfs_create_inferior): Don't push the target if it is already pushed. (nto_native_ops): New global. (procfs_open): Reimplement. (procfs_native_open): New function. (init_procfs_targets): Install procfs_native_open as to_open of "target native". Store a pointer to the "native" target in nto_native_ops. * procfs.c (procfs_attach): Don't push the target if it is already pushed. (procfs_detach): Use inf_child_maybe_unpush_target. (procfs_mourn_inferior): Only unpush the target after mourning the inferior. Use inf_child_maybe_unpush_target. (procfs_init_inferior): Don't push the target if it is already pushed. * windows-nat.c (do_initial_windows_stuff): Don't push the target if it is already pushed. (windows_detach): Use inf_child_maybe_unpush_target. (windows_mourn_inferior): Only unpush the target after mourning the inferior. Use inf_child_maybe_unpush_target. gdb/doc/ 2014-05-21 Pedro Alves <palves@redhat.com> * gdb.texinfo (Starting): Document "set/show auto-connect-native-target". (Target Commands): Document "target native". gdb/testsuite/ 2014-05-21 Pedro Alves <palves@redhat.com> * boards/gdbserver-base.exp (GDBFLAGS): Set to "set auto-connect-native-target off". * gdb.base/auto-connect-native-target.c: New file. * gdb.base/auto-connect-native-target.exp: New file.
2014-05-21 19:30:47 +02:00
2014-05-21 Pedro Alves <palves@redhat.com>
* boards/gdbserver-base.exp (GDBFLAGS): Set to "set
auto-connect-native-target off".
* gdb.base/auto-connect-native-target.c: New file.
* gdb.base/auto-connect-native-target.exp: New file.
Rename "target child" to "target native". I had been pondering renaming "target child" to something else. "child" is a little lie in case of "attach", and not exactly very clear to users, IMO. By best suggestion is "target native". If I were to explain what "target child" is, I'd just start out with "it's the native target" anyway. I was worrying a little that "native" might be a lie too if some port comes up with a default target that can run but is not really native, but I think that's a very minor issue - we can consider that "native" really means the default built in target that GDB supports, instead of saying that's the target that debugs host native processes, if it turns out necessary. This change doesn't affect users much, because "target child" results in error today: (gdb) target child Use the "run" command to start a child process. Other places "child" is visible: (gdb) help target ... List of target subcommands: target child -- Child process (started by the "run" command) target core -- Use a core file as a target target exec -- Use an executable file as a target ... (gdb) info target Symbols from "/home/pedro/gdb/mygit/build/gdb/gdb". Child process: Using the running image of child Thread 0x7ffff7fc9740 (LWP 4818). While running this, GDB does not access memory from... ... These places will say "native" instead. I think that's a good thing. gdb/ 2014-05-21 Pedro Alves <palves@redhat.com> * inf-child.c (inf_child_open): Remove mention of "child". (inf_child_target): Rename target to "native" instead of "child". gdb/testsuite/ 2014-05-21 Pedro Alves <palves@redhat.com> * gdb.base/default.exp: Test "target native" instead of "target child".
2014-05-21 19:30:43 +02:00
2014-05-21 Pedro Alves <palves@redhat.com>
* gdb.base/default.exp: Test "target native" instead of "target
child".
gdb/testsuite: Handle underlying type in gdb.cp/var-tag.exp. * gdb.cp/var-tag.exp (do_global_tests): Handle underlying type.
2014-05-21 16:00:05 +02:00
2014-05-21 Mark Wielaard <mjw@redhat.com>
* gdb.cp/var-tag.exp (do_global_tests): Handle underlying type.
Fix TLS access for -static -pthread I have posted: TLS variables access for -static -lpthread executables https://sourceware.org/ml/libc-help/2014-03/msg00024.html and the GDB patch below has been confirmed as OK for current glibcs. Further work should be done for newer glibcs: Improve TLS variables glibc compatibility https://sourceware.org/bugzilla/show_bug.cgi?id=16954 Still the patch below implements the feature in a fully functional way backward compatible with current glibcs, it depends on the following glibc source line: csu/libc-tls.c main_map->l_tls_modid = 1; gdb/ 2014-05-21 Jan Kratochvil <jan.kratochvil@redhat.com> Fix TLS access for -static -pthread. * linux-thread-db.c (struct thread_db_info): Add td_thr_tlsbase_p. (try_thread_db_load_1): Initialize it. (thread_db_get_thread_local_address): Call it if LM is zero. * target.c (target_translate_tls_address): Remove LM_ADDR zero check. * target.h (struct target_ops) (to_get_thread_local_address): Add load_module_addr comment. gdb/gdbserver/ 2014-05-21 Jan Kratochvil <jan.kratochvil@redhat.com> Fix TLS access for -static -pthread. * gdbserver/thread-db.c (struct thread_db): Add td_thr_tlsbase_p. (thread_db_get_tls_address): Call it if LOAD_MODULE is zero. (thread_db_load_search, try_thread_db_load_1): Initialize it. gdb/testsuite/ 2014-05-21 Jan Kratochvil <jan.kratochvil@redhat.com> Fix TLS access for -static -pthread. * gdb.threads/staticthreads.c <HAVE_TLS> (tlsvar): New. <HAVE_TLS> (thread_function, main): Initialize it. * gdb.threads/staticthreads.exp: Try gdb_compile_pthreads for $have_tls. Add clean_restart. <$have_tls != "">: Check TLSVAR. Message-ID: <20140410115204.GB16411@host2.jankratochvil.net>
2014-05-21 16:25:53 +02:00
2014-05-21 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix TLS access for -static -pthread.
* gdb.threads/staticthreads.c <HAVE_TLS> (tlsvar): New.
<HAVE_TLS> (thread_function, main): Initialize it.
* gdb.threads/staticthreads.exp: Try gdb_compile_pthreads for $have_tls.
Add clean_restart.
<$have_tls != "">: Check TLSVAR.
Make the dcache (code/stack cache) handle line reading errors better The dcache (code/stack cache) is supposed to be transparent, but it's actually not in one case. dcache tries to read chunks (cache lines) at a time off of the target. This may end up trying to read unaccessible or unavailable memory. Currently the caller gets an xfer error in this case. But if the specific bits of memory the caller actually wanted are available and accessible, then the caller should get the memory it wanted, not an error. gdb/ 2014-05-21 Pedro Alves <palves@redhat.com> * dcache.c (dcache_read_memory_partial): If reading the cache line fails, fallback to reading just the memory the caller wanted. gdb/testsuite/ 2014-05-21 Pedro Alves <palves@redhat.com> * gdb.base/dcache-line-read-error.c: New. * gdb.base/dcache-line-read-error.exp: New.
2014-05-21 14:58:16 +02:00
2014-05-21 Pedro Alves <palves@redhat.com>
* gdb.base/dcache-line-read-error.c: New.
* gdb.base/dcache-line-read-error.exp: New.
Make compare-sections work against all targets; add compare-sections [-r] tests. This does two things: 1. Adds a test. Recently compare-sections got a new "-r" switch, but given no test existed for compare-sections, the patch was allowed in with no testsuite addition. This now adds a test for both compare-sections and compare-sections -r. 2. Makes the compare-sections command work against all targets. Currently, compare-sections only works with remote targets, and only those that support the qCRC packet. The patch makes it so that if the target doesn't support accelerating memory verification, then GDB falls back to comparing memory itself. This is of course slower, but it's better than nothing, IMO. While testing against extended-remote GDBserver I noticed that we send the qCRC request to the target if we're connected, but not yet running a program. That can't work of course -- the patch fixes that. This all also goes in the direction of bridging the local/remote parity gap. I didn't decouple 1. from 2., because that would mean that the test would need to handle the case of the target not supporting the command. Tested on x86_64 Fedora 17, native, remote GDBserver, and extended-remote GDBserver. I also hack-disabled qCRC support to make sure the fallback paths in remote.c work. gdb/doc/ 2014-05-20 Pedro Alves <palves@redhat.com> * gdb.texinfo (Memory) <compare-sections>: Generalize comments to not be remote specific. Add cross reference to the qCRC packet. (Separate Debug Files): Update cross reference to the qCRC packet. (General Query Packets) <qCRC packet>: Add anchor. gdb/ 2014-05-20 Pedro Alves <palves@redhat.com> * NEWS: Mention that compare-sections now works with all targets. * remote.c (PACKET_qCRC): New enum value. (remote_verify_memory): Don't send qCRC if the target has no execution. Use packet_support/packet_ok. If the target doesn't support the qCRC packet, fallback to a deep memory copy. (compare_sections_command): Say "target image" instead of "remote executable". (_initialize_remote): Add PACKET_qCRC to the list of config packets that have no associated command. Extend comment. * target.c (simple_verify_memory, default_verify_memory): New function. * target.h (struct target_ops) <to_verify_memory>: Default to default_verify_memory. (simple_verify_memory): New declaration. * target-delegates.c: Regenerate. gdb/testsuite/ 2014-05-20 Pedro Alves <palves@redhat.com> * gdb.base/compare-sections.c: New file. * gdb.base/compare-sections.exp: New file.
2014-05-20 20:11:39 +02:00
2014-05-20 Pedro Alves <palves@redhat.com>
* gdb.base/compare-sections.c: New file.
* gdb.base/compare-sections.exp: New file.
[GDBserver] Make Zx/zx packet handling idempotent. This patch fixes hardware breakpoint regressions exposed by my fix for "PR breakpoints/7143 - Watchpoint does not trigger when first set", at https://sourceware.org/ml/gdb-patches/2014-03/msg00167.html The testsuite caught them on Linux/x86_64, at least. gdb.sum: gdb.sum: FAIL: gdb.base/hbreak2.exp: next over recursive call FAIL: gdb.base/hbreak2.exp: backtrace from factorial(5.1) FAIL: gdb.base/hbreak2.exp: continue until exit at recursive next test gdb.log: (gdb) next Program received signal SIGTRAP, Trace/breakpoint trap. factorial (value=4) at ../../../src/gdb/testsuite/gdb.base/break.c:113 113 if (value > 1) { /* set breakpoint 7 here */ (gdb) FAIL: gdb.base/hbreak2.exp: next over recursive call Actually, that patch just exposed a latent issue to "breakpoints always-inserted off" mode, not really caused it. After that patch, GDB no longer removes breakpoints at each internal event, thus making some scenarios behave like breakpoint always-inserted on. The bug is easy to trigger with always-inserted on. The issue is that since the target-side breakpoint conditions support, if the stub/server supports evaluating breakpoint conditions on the target side, then GDB is sending duplicate Zx packets to the target without removing them before, and GDBserver is not really expecting that for Z packets other than Z0/z0. E.g., with "set breakpoint always-inserted on" and "set debug remote 1": (gdb) b main Sending packet: $m410943,1#ff...Packet received: 48 Breakpoint 4 at 0x410943: file ../../../src/gdb/gdbserver/server.c, line 3028. Sending packet: $Z0,410943,1#48...Packet received: OK ^^^^^^^^^^^^ (gdb) b main Note: breakpoint 4 also set at pc 0x410943. Sending packet: $m410943,1#ff...Packet received: 48 Breakpoint 5 at 0x410943: file ../../../src/gdb/gdbserver/server.c, line 3028. Sending packet: $Z0,410943,1#48...Packet received: OK ^^^^^^^^^^^^ (gdb) b main Note: breakpoints 4 and 5 also set at pc 0x410943. Sending packet: $m410943,1#ff...Packet received: 48 Breakpoint 6 at 0x410943: file ../../../src/gdb/gdbserver/server.c, line 3028. Sending packet: $Z0,410943,1#48...Packet received: OK ^^^^^^^^^^^^ (gdb) del Delete all breakpoints? (y or n) y Sending packet: $Z0,410943,1#48...Packet received: OK Sending packet: $Z0,410943,1#48...Packet received: OK Sending packet: $z0,410943,1#68...Packet received: OK And for Z1, similarly: (gdb) hbreak main Sending packet: $m410943,1#ff...Packet received: 48 Hardware assisted breakpoint 4 at 0x410943: file ../../../src/gdb/gdbserver/server.c, line 3028. Sending packet: $Z1,410943,1#49...Packet received: OK ^^^^^^^^^^^^ Packet Z1 (hardware-breakpoint) is supported (gdb) hbreak main Note: breakpoint 4 also set at pc 0x410943. Sending packet: $m410943,1#ff...Packet received: 48 Hardware assisted breakpoint 5 at 0x410943: file ../../../src/gdb/gdbserver/server.c, line 3028. Sending packet: $Z1,410943,1#49...Packet received: OK ^^^^^^^^^^^^ (gdb) hbreak main Note: breakpoints 4 and 5 also set at pc 0x410943. Sending packet: $m410943,1#ff...Packet received: 48 Hardware assisted breakpoint 6 at 0x410943: file ../../../src/gdb/gdbserver/server.c, line 3028. Sending packet: $Z1,410943,1#49...Packet received: OK ^^^^^^^^^^^^ (gdb) del Delete all breakpoints? (y or n) y Sending packet: $Z1,410943,1#49...Packet received: OK ^^^^^^^^^^^^ Sending packet: $Z1,410943,1#49...Packet received: OK ^^^^^^^^^^^^ Sending packet: $z1,410943,1#69...Packet received: OK ^^^^^^^^^^^^ So GDB sent a bunch of Z1 packets, and then when finally removing the breakpoint, only one z1 packet was sent. On the GDBserver side (with monitor set debug-hw-points 1), in the Z1 case, we see: $ ./gdbserver :9999 ./gdbserver Process ./gdbserver created; pid = 8629 Listening on port 9999 Remote debugging from host 127.0.0.1 insert_watchpoint (addr=410943, len=1, type=instruction-execute): CONTROL (DR7): 00000101 STATUS (DR6): 00000000 DR0: addr=0x410943, ref.count=1 DR1: addr=0x0, ref.count=0 DR2: addr=0x0, ref.count=0 DR3: addr=0x0, ref.count=0 insert_watchpoint (addr=410943, len=1, type=instruction-execute): CONTROL (DR7): 00000101 STATUS (DR6): 00000000 DR0: addr=0x410943, ref.count=2 DR1: addr=0x0, ref.count=0 DR2: addr=0x0, ref.count=0 DR3: addr=0x0, ref.count=0 insert_watchpoint (addr=410943, len=1, type=instruction-execute): CONTROL (DR7): 00000101 STATUS (DR6): 00000000 DR0: addr=0x410943, ref.count=3 DR1: addr=0x0, ref.count=0 DR2: addr=0x0, ref.count=0 DR3: addr=0x0, ref.count=0 insert_watchpoint (addr=410943, len=1, type=instruction-execute): CONTROL (DR7): 00000101 STATUS (DR6): 00000000 DR0: addr=0x410943, ref.count=4 DR1: addr=0x0, ref.count=0 DR2: addr=0x0, ref.count=0 DR3: addr=0x0, ref.count=0 insert_watchpoint (addr=410943, len=1, type=instruction-execute): CONTROL (DR7): 00000101 STATUS (DR6): 00000000 DR0: addr=0x410943, ref.count=5 DR1: addr=0x0, ref.count=0 DR2: addr=0x0, ref.count=0 DR3: addr=0x0, ref.count=0 remove_watchpoint (addr=410943, len=1, type=instruction-execute): CONTROL (DR7): 00000101 STATUS (DR6): 00000000 DR0: addr=0x410943, ref.count=4 DR1: addr=0x0, ref.count=0 DR2: addr=0x0, ref.count=0 DR3: addr=0x0, ref.count=0 That's one insert_watchpoint call for each Z1 packet, and then one remove_watchpoint call for the z1 packet. Notice how ref.count increased for each insert_watchpoint call, and then in the end, after GDB told GDBserver to forget about the hardware breakpoint, GDBserver ends with the the first debug register still with ref.count=4! IOW, the hardware breakpoint is left armed on the target, while on the GDB end it's gone. If the program happens to execute 0x410943 afterwards, then the CPU traps, GDBserver reports the trap to GDB, and GDB not having a breakpoint set at that address anymore, reports to the user a spurious SIGTRAP. This is exactly what is happening in the hbreak2.exp test, though in that case, it's a shared library event that triggers a breakpoint_re_set, when breakpoints are still inserted (because nowadays GDB doesn't remove breakpoints while handling internal events), and that recreates breakpoint locations, which likewise forces breakpoint reinsertion and Zx packet resends... That is a lot of bogus Zx duplication that should possibly be addressed on the GDB side. GDB resends Zx packets because the way to change the target-side condition, is to resend the breakpoint to the server with the new condition. (That's an option in the packet: e.g., "Z1,410943,1;X3,220027" for "hbreak main if 0". The packets in the examples above are shorter because the breakpoints don't have conditions attached). GDB doesn't remove the breakpoint first before reinserting it because that'd be bad for non-stop, as it'd open a window where the inferior could miss the breakpoint. The conditions actually haven't changed between the resends, but GDB isn't smart enough to realize that. (TBC, if the target doesn't support target-side conditions, then GDB doesn't trigger these resends (init_bp_location calls mark_breakpoint_location_modified, and that does nothing if condition evaluation is on the host side. The resends are caused by the 'loc->condition_changed = condition_modified.' line.) But, even if GDB was made smarter, GDBserver should really still handle the resends anyway. So target-side conditions also aren't really to blame. The documentation of the Z/z packets says: "To avoid potential problems with duplicate packets, the operations should be implemented in an idempotent way." As such, we may want to fix GDB, but we should definitely fix GDBserver. The fix is a prerequisite for target-side conditions on hardware breakpoints anyway (and while at it, on watchpoints too). GDBserver indeed already treats duplicate Z0 packets in an idempotent way. mem-break.c has the concept of high-level and low-level breakpoints, somewhat similar to GDB's split of breakpoints vs breakpoint locations, and keeps track of multiple breakpoints referencing the same address/location, for the case of an internal GDBserver breakpoint or a tracepoint being set at the same address as a GDB breakpoint. But, it only allows GDB to ever contribute one reference to a software breakpoint location. IOW, if gdbserver sees a Z0 packet for the same address where it already had a GDB breakpoint set, then GDBserver won't create another high-level GDB breakpoint. However, mem-break.c only tracks GDB Z0 breakpoints. The same logic should apply to all kinds of Zx packets. Currently, gdbserver passes down each duplicate Zx (other than Z0) request directly to the target->insert_point routine. The x86 watchpoint support itself refcounts watchpoint / hw breakpoint requests, to handle overlapping watchpoints, and save debug registers. But that code doesn't (and really shouldn't) handle the duplicate requests, assuming that for each insert there will be a corresponding remove. So the fix is to generalize mem-break.c to track all kinds of Zx breakpoints, and filter out duplicates. As mentioned, this ends up adding support for target-side conditions on hardware breakpoints and watchpoints too (though GDB itself doesn't support the latter yet). Probably the least obvious change in the patch is that it kind of turns the breakpoint insert/remove APIs inside out. Before, the target methods were only called for GDB breakpoints. The internal breakpoint set/delete methods inserted memory breakpoints directly bypassing the insert/remove target methods. That's not good when the target should use a debug API to set software breakpoints, instead of relying on GDBserver patching memory with breakpoint instructions, as is the case of NTO. Now removal/insertion of all kinds of breakpoints/watchpoints, either internal, or from GDB, always go through the target methods. The insert_point/remove_point methods no longer get passed a Z packet type, but an internal/raw breakpoint type. They're also passed a pointer to the raw breakpoint itself (note that's still opaque outside mem-break.c), so that insert_memory_breakpoint / remove_memory_breakpoint have access to the breakpoint's shadow buffer. I first tried passing down a new structure based on GDB's "struct bp_target_info" (actually with that name exactly), but then decided against it as unnecessary complication. As software/memory breakpoints work by poking at memory, when setting a GDB Z0 breakpoint (but not internal breakpoints, as those can assume the conditions are already right), we need to tell the target to prepare to access memory (which on Linux means stop threads). If that operation fails, we need to return error to GDB. Seeing an error, if this is the first breakpoint of that type that GDB tries to insert, GDB would then assume the breakpoint type is supported, but it may actually not be. So we need to check whether the type is supported at all before preparing to access memory. And to solve that, the patch adds a new target->supports_z_point_type method that is called before actually trying to insert the breakpoint. Other than that, hopefully the change is more or less obvious. New test added that exercises the hbreak2.exp regression in a more direct way, without relying on a breakpoint re-set happening before main is reached. Tested by building GDBserver for: aarch64-linux-gnu arm-linux-gnueabihf i686-pc-linux-gnu i686-w64-mingw32 m68k-linux-gnu mips-linux-gnu mips-uclinux nios2-linux-gnu powerpc-linux-gnu sh-linux-gnu tilegx-unknown-linux-gnu x86_64-redhat-linux x86_64-w64-mingw32 And also regression tested on x86_64 Fedora 20. gdb/gdbserver/ 2014-05-20 Pedro Alves <palves@redhat.com> * linux-aarch64-low.c (aarch64_insert_point) (aarch64_remove_point): No longer check whether the type is supported here. Adjust to new interface. (the_low_target): Install aarch64_supports_z_point_type as supports_z_point_type method. * linux-arm-low.c (raw_bkpt_type_to_arm_hwbp_type): New function. (arm_linux_hw_point_initialize): Take an enum raw_bkpt_type instead of a Z packet char. Adjust. (arm_supports_z_point_type): New function. (arm_insert_point, arm_remove_point): Adjust to new interface. (the_low_target): Install arm_supports_z_point_type. * linux-crisv32-low.c (cris_supports_z_point_type): New function. (cris_insert_point, cris_remove_point): Adjust to new interface. Don't check whether the type is supported here. (the_low_target): Install cris_supports_z_point_type. * linux-low.c (linux_supports_z_point_type): New function. (linux_insert_point, linux_remove_point): Adjust to new interface. * linux-low.h (struct linux_target_ops) <insert_point, remove_point>: Take an enum raw_bkpt_type instead of a char. Add raw_breakpoint pointer parameter. <supports_z_point_type>: New method. * linux-mips-low.c (mips_supports_z_point_type): New function. (mips_insert_point, mips_remove_point): Adjust to new interface. Use mips_supports_z_point_type. (the_low_target): Install mips_supports_z_point_type. * linux-ppc-low.c (the_low_target): Install NULL as supports_z_point_type method. * linux-s390-low.c (the_low_target): Install NULL as supports_z_point_type method. * linux-sparc-low.c (the_low_target): Install NULL as supports_z_point_type method. * linux-x86-low.c (x86_supports_z_point_type): New function. (x86_insert_point): Adjust to new insert_point interface. Use insert_memory_breakpoint. Adjust to new i386_low_insert_watchpoint interface. (x86_remove_point): Adjust to remove_point interface. Use remove_memory_breakpoint. Adjust to new i386_low_remove_watchpoint interface. (the_low_target): Install x86_supports_z_point_type. * lynx-low.c (lynx_target_ops): Install NULL as supports_z_point_type callback. * nto-low.c (nto_supports_z_point_type): New. (nto_insert_point, nto_remove_point): Adjust to new interface. (nto_target_ops): Install nto_supports_z_point_type. * mem-break.c: Adjust intro comment. (struct raw_breakpoint) <raw_type, size>: New fields. <inserted>: Update comment. <shlib_disabled>: Delete field. (enum bkpt_type) <gdb_breakpoint>: Delete value. <gdb_breakpoint_Z0, gdb_breakpoint_Z1, gdb_breakpoint_Z2, gdb_breakpoint_Z3, gdb_breakpoint_Z4>: New values. (raw_bkpt_type_to_target_hw_bp_type): New function. (find_enabled_raw_code_breakpoint_at): New function. (find_raw_breakpoint_at): New type and size parameters. Use them. (insert_memory_breakpoint): New function, based off set_raw_breakpoint_at. (remove_memory_breakpoint): New function. (set_raw_breakpoint_at): Reimplement. (set_breakpoint): New, based on set_breakpoint_at. (set_breakpoint_at): Reimplement. (delete_raw_breakpoint): Go through the_target->remove_point instead of assuming memory breakpoints. (find_gdb_breakpoint_at): Delete. (Z_packet_to_bkpt_type, Z_packet_to_raw_bkpt_type): New functions. (find_gdb_breakpoint): New function. (set_gdb_breakpoint_at): Delete. (z_type_supported): New function. (set_gdb_breakpoint_1): New function, loosely based off set_gdb_breakpoint_at. (check_gdb_bp_preconditions, set_gdb_breakpoint): New functions. (delete_gdb_breakpoint_at): Delete. (delete_gdb_breakpoint_1): New function, loosely based off delete_gdb_breakpoint_at. (delete_gdb_breakpoint): New function. (clear_gdb_breakpoint_conditions): Rename to ... (clear_breakpoint_conditions): ... this. Don't handle a NULL breakpoint. (add_condition_to_breakpoint): Make static. (add_breakpoint_condition): Take a struct breakpoint pointer instead of an address. Adjust. (gdb_condition_true_at_breakpoint): Rename to ... (gdb_condition_true_at_breakpoint_z_type): ... this, and add z_type parameter. (gdb_condition_true_at_breakpoint): Reimplement. (add_breakpoint_commands): Take a struct breakpoint pointer instead of an address. Adjust. (gdb_no_commands_at_breakpoint): Rename to ... (gdb_no_commands_at_breakpoint_z_type): ... this. Add z_type parameter. Return true if no breakpoint was found. Change debug output. (gdb_no_commands_at_breakpoint): Reimplement. (run_breakpoint_commands): Rename to ... (run_breakpoint_commands_z_type): ... this. Add z_type parameter, and change return type to boolean. (run_breakpoint_commands): New function. (gdb_breakpoint_here): Also check for Z1 breakpoints. (uninsert_raw_breakpoint): Don't try to reinsert a disabled breakpoint. Go through the_target->remove_point instead of assuming memory breakpoint. (uninsert_breakpoints_at, uninsert_all_breakpoints): Uninsert software and hardware breakpoints. (reinsert_raw_breakpoint): Go through the_target->insert_point instead of assuming memory breakpoint. (reinsert_breakpoints_at, reinsert_all_breakpoints): Reinsert software and hardware breakpoints. (check_breakpoints, breakpoint_here, breakpoint_inserted_here): Check both software and hardware breakpoints. (validate_inserted_breakpoint): Assert the breakpoint is a software breakpoint. Set the inserted flag to -1 instead of setting shlib_disabled. (delete_disabled_breakpoints): Adjust. (validate_breakpoints): Only validate software breakpoints. Adjust to inserted flag change. (check_mem_read, check_mem_write): Skip breakpoint types other than software breakpoints. Adjust to inserted flag change. * mem-break.h (enum raw_bkpt_type): New enum. (raw_breakpoint, struct process_info): Forward declare. (Z_packet_to_target_hw_bp_type): Delete declaration. (raw_bkpt_type_to_target_hw_bp_type, Z_packet_to_raw_bkpt_type) (set_gdb_breakpoint, delete_gdb_breakpoint) (clear_breakpoint_conditions): New declarations. (set_gdb_breakpoint_at, clear_gdb_breakpoint_conditions): Delete. (breakpoint_inserted_here): Update comment. (add_breakpoint_condition, add_breakpoint_commands): Replace address parameter with a breakpoint pointer parameter. (gdb_breakpoint_here): Update comment. (delete_gdb_breakpoint_at): Delete. (insert_memory_breakpoint, remove_memory_breakpoint): Declare. * server.c (process_point_options): Take a struct breakpoint pointer instead of an address. Adjust. (process_serial_event) <Z/z packets>: Use set_gdb_breakpoint and delete_gdb_breakpoint. * spu-low.c (spu_target_ops): Install NULL as supports_z_point_type method. * target.h: Include mem-break.h. (struct target_ops) <prepare_to_access_memory>: Update comment. <supports_z_point_type>: New field. <insert_point, remove_point>: Take an enum raw_bkpt_type argument instead of a char. Also take a raw breakpoint pointer. * win32-arm-low.c (the_low_target): Install NULL as supports_z_point_type. * win32-i386-low.c (i386_supports_z_point_type): New function. (i386_insert_point, i386_remove_point): Adjust to new interface. (the_low_target): Install i386_supports_z_point_type. * win32-low.c (win32_supports_z_point_type): New function. (win32_insert_point, win32_remove_point): Adjust to new interface. (win32_target_ops): Install win32_supports_z_point_type. * win32-low.h (struct win32_target_ops): <supports_z_point_type>: New method. <insert_point, remove_point>: Take an enum raw_bkpt_type argument instead of a char. Also take a raw breakpoint pointer. gdb/testsuite/ 2014-05-20 Pedro Alves <palves@redhat.com> * gdb.base/break-idempotent.c: New file. * gdb.base/break-idempotent.exp: New file.
2014-05-20 19:24:28 +02:00
2014-05-20 Pedro Alves <palves@redhat.com>
* gdb.base/break-idempotent.c: New file.
* gdb.base/break-idempotent.exp: New file.
btrace: no replay without history When using a reverse execution command without execution history, GDB might end up in a state where replaying has been started but remains at the current instruction. This state is illegal. Do not step if there is no execution history to avoid this. 2014-05-20 Markus Metzger <markus.t.metzger@intel.com> * record-btrace.c (record_btrace_step_thread): Check for empty history. testsuite/ * gdb.btrace/nohist.exp: New.
2014-05-15 10:57:36 +02:00
2014-05-20 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/nohist.exp: New.
Set timeout for gdb.reverse/*.exp test cases Hi, This patch is to add a new board setting gdb_reverse_timeout, which is used to set timeout for all gdb.reverse test cases, which are usually very slow and cause some TIMEOUT failures, for example, on some arm boards. We have some alternatives to this approach, but I am not satisfied with them: - Increase the timeout value. This is the global change, and it may cause some delay where actual failures happen. - Set timeout by gdb_reverse_timeout in every gdb.reverse/*.exp. Then, we have to touch every file under gdb.reverse. In this patch, we choose a central place to set timeout for all tests in gdb.reverse, which is convenient. gdb/testsuite: 2014-05-20 Yao Qi <yao@codesourcery.com> * lib/gdb.exp (gdb_init): Set timeout if test file is under gdb.reverse directory and gdb_reverse_timeout exists in board setting. * README: Document gdb_reverse_timeout.
2014-05-09 09:06:12 +02:00
2014-05-20 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (gdb_init): Set timeout if test file is under
gdb.reverse directory and gdb_reverse_timeout exists in board
setting.
* README: Document gdb_reverse_timeout.
gdb_init argument ARGS is a string rather than a list The argument ARGS of gdb_init is passed from dejagnu is a string, the test file name. In dejagnu/runtest.exp: proc runtest { test_file_name } { .... .... if [info exists tool] { if { [info procs "${tool}_init"] != "" } { ${tool}_init $test_file_name; } } .... } but inn default_gdb_init (callee of gdb_init), we have set gdb_test_file_name [file rootname [file tail [lindex $args 0]]] In tcl, all actual arguments are combined to a list and assigned to args. This code here isn't wrong, but unnecessary, because its caller (proc runtest) only passes one string to it, and IMO, we don't need such tricky tcl "args". I doubt that "[lindex $args 0]" is to be backward compatible with old dejagnu, but dejagnu-1.4 release started to pass $test_file_name to ${too}_init, as I showed above. dejagnu-1.4 was released in 2001, and it should be old enough. I also tried to check whether gdb testusite works with dejagnu-1.3 or not, but failed to build dejagnu-1.3 on my machine. Supposing GDB testsuite requires at least dejagnu-1.4, this change should be safe. This patch is update default_gdb_init to treat ARGS as a string instead of a list. Then, 'args' sounds like a list, and this patch also renames it by 'test_file_name', to align with dejagnu. gdb/testsuite: 2014-05-20 Yao Qi <yao@codesourcery.com> * lib/gdb.exp (default_gdb_init): Rename argument 'args' by 'test_file_name'. Treat args as a string instead of a list. (gdb_init): Rename argument 'args' by 'test_file_name'.
2014-05-09 05:01:07 +02:00
2014-05-20 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (default_gdb_init): Rename argument 'args' by
'test_file_name'. Treat args as a string instead of a list.
(gdb_init): Rename argument 'args' by 'test_file_name'.
[testsuite patch] Test power{5,6,7} disassembly Power5, Power6 and Power7 disassembly testing. gdb/testsuite/ 2014-05-19 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.arch/powerpc-power.exp: New file. * gdb.arch/powerpc-power.s: New file. Message-ID: <20140514205425.GA15398@host2.jankratochvil.net>
2014-05-19 15:39:24 +02:00
2014-05-19 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/powerpc-power.exp: New file.
* gdb.arch/powerpc-power.s: New file.
* gdb.base/Makefile.in (EXECUTABLES): Add completion.
2014-05-16 21:34:05 +02:00
2014-05-16 Doug Evans <dje@google.com>
* gdb.base/Makefile.in (EXECUTABLES): Add completion.
* gdb.base/completion.exp: Check that all expected files exist before doing file completion.
2014-05-16 21:46:24 +02:00
* gdb.base/completion.exp: Check that all expected files exist
before doing file completion.
* gdb.base/Makefile.in (EXECUTABLES): Add completion.
2014-05-16 21:34:05 +02:00
New command line option -D. * NEWS: Mention it. * main.c (set_gdb_data_directory): New function. (captured_main): Recognize -D. Flag error for --data-directory "". Call set_gdb_data_directory. (print_gdb_help): Print --data-directory, -D. * main.h (set_gdb_data_directory): Declare. * top.c (staged_gdb_datadir): New static global. (set_gdb_datadir): Call set_gdb_data_directory (show_gdb_datadir): New function. (init_main): Update init of data-directory parameter. testsuite/ * gdb.base/catch-syscall.exp (test_catch_syscall_fail_nodatadir): Update. (do_syscall_tests_without_xml): Update. doc/ * gdb.texinfo (Mode Options): Add -D.
2014-05-16 21:15:10 +02:00
2014-05-16 Doug Evans <dje@google.com>
* gdb.base/catch-syscall.exp (test_catch_syscall_fail_nodatadir):
Update.
(do_syscall_tests_without_xml): Update.
mi-support.exp: Fix some pastos. gdb/testsuite/ 2014-05-16 Pedro Alves <palves@redhat.com> * lib/mi-support.exp (mi_expect_stop): On timeout, say "timeout" instead of "unknown output after running".
2014-05-16 15:43:47 +02:00
2014-05-16 Pedro Alves <palves@redhat.com>
* lib/mi-support.exp (mi_expect_stop): On timeout, say "timeout"
instead of "unknown output after running".
Copy file1.txt to remote host in dw2-filename.exp and dw2-anonymous-func.exp Some gdb.dwarf2/*.exp tests copy file1.txt to host via gdb_remote_download but dw2-filename.exp and dw2-anonymous-func.exp don't do that. Looks like an oversight in this patch https://sourceware.org/ml/gdb-patches/2013-08/msg00365.html There are some fails in remote host testing. FAIL: gdb.dwarf2/dw2-anonymous-func.exp: list file1.txt FAIL: gdb.dwarf2/dw2-filename.exp: interpreter-exec mi -file-list-exec-source-files FAIL: gdb.dwarf2/dw2-filename.exp: info sources This patch is to invoke gdb_remote_download to copy file1.txt to host and remote it at the end. This patch fixes these fails above. gdb/testsuite: 2014-05-16 Yao Qi <yao@codesourcery.com> * gdb.dwarf2/dw2-filename.exp: Copy file1.txt to host. Remove file1.txt from host at the end. * gdb.dwarf2/dw2-anonymous-func.exp: Likewise.
2014-05-13 05:41:03 +02:00
2014-05-16 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dw2-filename.exp: Copy file1.txt to host. Remove
file1.txt from host at the end.
* gdb.dwarf2/dw2-anonymous-func.exp: Likewise.
Make more robust when run in parallel mode. Since we're not compiling with gcc, we don't know where the DWO file will ultimately be built. It could be built in testsuite/gdb.dwarf2/foo (non-parallel mode) or testsuite/outputs/gdb.dwarf2/foo (parallel mode). * gdb.dwarf2/fission-reread.S: Remove directory from .dwo file path. * gdb.dwarf2/fission-reread.exp: Set debug-file-directory before loading file. Add test for TU lookup.
2014-05-16 00:50:34 +02:00
2014-05-15 Doug Evans <dje@google.com>
* gdb.dwarf2/fission-reread.S: Remove directory from .dwo file path.
* gdb.dwarf2/fission-reread.exp: Set debug-file-directory before
loading file. Add test for TU lookup.
Fix argument passing in mi_run_cmd_full Passing arguments did not work when use_mi_command was set. gdb/testsuite/ChangeLog: 2014-05-13 Simon Marchi <simon.marchi@ericsson.com> * lib/mi-support.exp (mi_run_cmd_full): Set arguments by calling "-exec-arguments" or "set args" before running the inferior.
2014-05-13 23:37:44 +02:00
2014-05-15 Simon Marchi <simon.marchi@ericsson.com>
* lib/mi-support.exp (mi_run_cmd_full): Set arguments by
calling "-exec-arguments" or "set args" before running the
inferior.
Fix mi_expect_stop for non-zero exit codes The message displayed by gdb is different when the inferior exits with zero and non-zero values, this fix takes that into account. gdb/testsuite/ChangeLog: 2014-05-13 Simon Marchi <simon.marchi@ericsson.com> * lib/mi-support.exp (mi_expect_stop): Expect message for inferiors that exit with non-zero exit code.
2014-05-13 23:07:33 +02:00
2014-05-15 Simon Marchi <simon.marchi@ericsson.com>
* lib/mi-support.exp (mi_expect_stop): Expect message for
inferiors that exit with non-zero exit code.
Fix mi-file.exp fails on remote host This patch fixes mi-file.exp fails on remote host. First, we can't assume ${srcdir}/${subdir}/${srcfile} directory exists on remote host, so this patch changes it to match ${srcfile} only on remote host. Second, regexp pattern ".*/${srcfile}" isn't friendly to Windows path. The file name is "basics.c" in my test env and can't match the pattern due to "/" in it. Remove "/" from the pattern. gdb/testsuite: 2014-05-14 Yao Qi <yao@codesourcery.com> * gdb.mi/mi-file.exp (test_file_list_exec_source_file): Don't match absolute path on remote host. (test_file_list_exec_source_files): Remove "/" from the pattern.
2014-05-13 08:40:22 +02:00
2014-05-14 Yao Qi <yao@codesourcery.com>
* gdb.mi/mi-file.exp (test_file_list_exec_source_file): Don't
match absolute path on remote host.
(test_file_list_exec_source_files): Remove "/" from the
pattern.
Overwrite ${board}_file in local-remote-host After I run test like this, $ make check RUNTESTFLAGS='--host_board=local-remote-host dw2-basic.exp' gdb.dwarf2/file1.txt in source tree was removed. In some gdb.dwarf2/*.exp, file1.txt is copied to host and then removed at the end. However, in local-remote-host-notty.exp, ${board}_download doesn't copy the file but return the absolute path of the src file. 'remote_file host delete' at the end will remove the file in source tree. This patch is to overwrite ${board}_file, and specially make "delete" option do nothing. This approach is used in gdbserver-base.exp and remote-stdio-gdbserver.exp too. gdb/testsuite: 2014-05-14 Yao Qi <yao@codesourcery.com> * boards/local-remote-host-notty.exp (${board}_file): New proc.
2014-05-13 03:37:54 +02:00
2014-05-14 Yao Qi <yao@codesourcery.com>
* boards/local-remote-host-notty.exp (${board}_file): New
proc.
aarch64: detect atomic sequences like other ll/sc architectures gdb/Changelog: * aarch64-tdep.c (aarch64_software_single_step): New function. (aarch64_gdbarch_init): Handle single stepping of atomic sequences with aarch64_software_single_step. gdb/testsuite/ChangeLog: * gdb.arch/aarch64-atomic-inst.c: New file. * gdb.arch/aarch64-atomic-inst.exp: New file.
2014-04-30 18:04:50 +02:00
2014-05-07 Kyle McMartin <kyle@redhat.com>
Pushed by Joel Brobecker <brobecker@adacore.com>.
* gdb.arch/aarch64-atomic-inst.c: New file.
* gdb.arch/aarch64-atomic-inst.exp: New file.
Relax the pattern in dwzbuildid.exp Hi, I recently see the fail in dwzbuildid.exp below on some targets, (gdb) print the_int No symbol "the_int" in current context. (gdb) FAIL: gdb.dwarf2/dwzbuildid.exp: mismatch: print the_int Looks the pattern expects to see "No symbol table is loaded", which is emitted in c-exp.y, variable: name_not_typename .... if (msymbol.minsym != NULL) write_exp_msymbol (pstate, msymbol); else if (!have_full_symbols () && !have_partial_symbols ()) error (_("No symbol table is loaded. Use the \"file\" command.")); else error (_("No symbol \"%s\" in current context."), copy_name ($1.stoken)); it is expected to have no full symbols nor partial symbols, but something brings full symbols or partial symbols in. I added "maint info symtabs" and "maint info psymtabs" in dwzbuildid.exp, and it shows symbols are from ld.so, which has debug information. Then, I reproduce the fail like this, $ make check RUNTESTFLAGS="CFLAGS_FOR_TARGET='-Wl,-rpath=${glibc_build}:${glibc_build}/math -Wl,--dynamic-linker=${glibc_build}/elf/ld.so' dwzbuildid.exp" ${glibc_build} is the glibc build tree. Debug information is not striped, so the test fail. However, if I strip debug information from libc.so, libm.so and ld.so. The test passes. This patch is to relax the pattern to match the both cases that glibc build has and has not debug information. gdb/testsuite: 2014-05-07 Yao Qi <yao@codesourcery.com> * gdb.dwarf2/dwzbuildid.exp: Match output "No symbol "the_int" in current context" too.
2014-05-06 15:47:36 +02:00
2014-05-07 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dwzbuildid.exp: Match output "No symbol "the_int"
in current context" too.
Fix a dangling cleanup in linspec_parse_basic. 2014-05-05 Keith Seitz <keiths@redhat.com> * linespec.c (linespec_parse_basic): Run cleanups if a convenience variable or history value is successfully parsed. 2014-05-05 Keith Seitz <keiths@redhat.com> * gdb.linespec/ls-dollar.exp: Add test for linespec file:convenience_variable.
2014-05-05 22:43:31 +02:00
2014-05-05 Keith Seitz <keiths@redhat.com>
* gdb.linespec/ls-dollar.exp: Add test for linespec
file:convenience_variable.
Partially available/unavailable data in requested range In gdb.trace/unavailable.exp, an action is defined to collect struct_b.struct_a.array[2] and struct_b.struct_a.array[100], struct StructB { int d, ef; StructA struct_a; int s:1; static StructA static_struct_a; const char *string; }; and the other files are not collected. When GDB examine traceframe collected by the action, "struct_b" is unavailable completely, which is wrong. (gdb) p struct_b $1 = <unavailable> When GDB reads 'struct_b', it will request to read memory at struct_b's address of length LEN. Since struct_b.d is not collected, no 'M' block includes the first part of the desired range, so tfile_xfer_partial returns TARGET_XFER_UNAVAILABLE and GDB thinks the whole requested range is unavailable. In order to fix this problem, in the iteration to 'M' blocks, we record the lowest address of blocks within the request range. If it has, the requested range isn't unavailable completely. This applies to ctf too. With this patch applied, the result looks good and fails in unavailable.exp is fixed. (gdb) p struct_b $1 = {d = <unavailable>, ef = <unavailable>, struct_a = {a = <unavailable>, b = <unavailable>, array = {<unavailable>, <unavailable>, -1431655766, <unavailable> <repeats 97 times>, -1431655766, <unavailable> <repeats 9899 times>}, ptr = <unavailable>, bitfield = <unavailable>}, s = <unavailable>, static static_struct_a = {a = <unavailable>, b = <unavailable>, array = {<unavailable> <repeats 10000 times>}, ptr = <unavailable>, bitfield = <unavailable>}, string = <unavailable>} gdb: 2014-05-05 Yao Qi <yao@codesourcery.com> Pedro Alves <palves@redhat.com> * tracefile-tfile.c (tfile_xfer_partial): Record the lowest address of blocks that intersects the requested range. Trim LEN up to LOW_ADDR_AVAILABLE if read from executable read-only sections. * ctf.c (ctf_xfer_partial): Likewise. gdb/testsuite: 2014-05-05 Yao Qi <yao@codesourcery.com> * gdb.trace/unavailable.exp (gdb_collect_args_test): Save traceframes into tfile and ctf trace files. Read data from trace file and test collected data. (gdb_collect_locals_test): Likewise. (gdb_unavailable_registers_test): Likewise. (gdb_unavailable_floats): Likewise. (gdb_collect_globals_test): Likewise. (top-level): Append "ctf" to trace_file_targets if GDB supports.
2014-04-26 04:14:52 +02:00
2014-05-05 Yao Qi <yao@codesourcery.com>
* gdb.trace/unavailable.exp (gdb_collect_args_test): Save
traceframes into tfile and ctf trace files. Read data from
trace file and test collected data.
(gdb_collect_locals_test): Likewise.
(gdb_unavailable_registers_test): Likewise.
(gdb_unavailable_floats): Likewise.
(gdb_collect_globals_test): Likewise.
(top-level): Append "ctf" to trace_file_targets if GDB
supports.
Move traceframe checking out of traceframe generation This patch moves traceframe checking code out of traceframe generation, so that we can generation traceframe once, and do the checking in multiple times (with target remote, tfile and ctf respectively). This is a pure refactor, not functional changes in unavailable.exp. gdb/testsuite: 2014-05-05 Yao Qi <yao@codesourcery.com> * gdb.trace/unavailable.exp (gdb_collect_args_test): Move some code to ... (gdb_collect_args_test_1): ... it. New proc. (gdb_collect_locals_test): Move some code to ... (gdb_collect_locals_test_1): ... it. New proc. (gdb_unavailable_registers_test): Move some code to ... (gdb_unavailable_registers_test_1): ... it. New proc. (gdb_unavailable_floats): Move some code to ... (gdb_unavailable_floats_1): ... it. New proc.
2014-04-25 10:18:52 +02:00
2014-05-05 Yao Qi <yao@codesourcery.com>
* gdb.trace/unavailable.exp (gdb_collect_args_test): Move some
code to ...
(gdb_collect_args_test_1): ... it. New proc.
(gdb_collect_locals_test): Move some code to ...
(gdb_collect_locals_test_1): ... it. New proc.
(gdb_unavailable_registers_test): Move some code to ...
(gdb_unavailable_registers_test_1): ... it. New proc.
(gdb_unavailable_floats): Move some code to ...
(gdb_unavailable_floats_1): ... it. New proc.
Extend recognized types of SDT probe's arguments This commit is actually an update to make the parser in gdb/stap-probe.c be aware of all the possible prefixes that a probe argument can have. According to the section "Argument Format" in: <https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation> The bitness of the arguments can be 8, 16, 32 or 64 bits, signed or unsigned. Currently GDB recognizes only 32 and 64-bit arguments. This commit extends this. It also provides a testcase, only for x86_64 systems. gdb/ 2014-05-02 Sergio Durigan Junior <sergiodj@redhat.com> * stap-probe.c (enum stap_arg_bitness): New enums to represent 8 and 16-bit signed and unsigned arguments. Update comment. (stap_parse_probe_arguments): Extend code to handle such arguments. Use warning instead of complaint to notify about unrecognized bitness. gdb/testsuite/ 2014-05-02 Sergio Durigan Junior <sergiodj@redhat.com> * gdb.arch/amd64-stap-optional-prefix.S (main): Add several probes to test for bitness recognition. * gdb.arch/amd64-stap-optional-prefix.exp (test_probe_value_without_reg): New procedure. Add code to test for different kinds of bitness.
2014-05-02 22:50:45 +02:00
2014-05-02 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.arch/amd64-stap-optional-prefix.S (main): Add several
probes to test for bitness recognition.
* gdb.arch/amd64-stap-optional-prefix.exp
(test_probe_value_without_reg): New procedure.
Add code to test for different kinds of bitness.
Fix PR breakpoints/16889: gdb segfaults when printing ASM SDT arguments This commit fixes PR breakpoints/16889, which is about a bug that triggers when GDB tries to parse probes whose arguments do not contain the initial (and optional) "N@" part. For reference sake, the de facto format is described here: <https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation> Anyway, this PR actually uncovered two bugs (related) that were happening while parsing the arguments. The first one was that the parser *was* catching *some* arguments that were missing the "N@" part, but it wasn't correctly setting the argument's type. This was causing a NULL pointer being dereferenced, ouch... The second bug uncovered was that the parser was not catching all of the cases for a probe which did not provide the "N@" part. The fix for that was to simplify the check that the code was making to identify non-prefixed probes. The code is simpler and easier to read now. I am also providing a testcase for this bug, only for x86_64 architectures. gdb/ 2014-05-02 Sergio Durigan Junior <sergiodj@redhat.com> PR breakpoints/16889 * stap-probe.c (stap_parse_probe_arguments): Simplify check for non-prefixed probes (i.e., probes whose arguments do not start with "N@"). Always set the argument type to a sane value. gdb/testsuite/ 2014-05-02 Sergio Durigan Junior <sergiodj@redhat.com> PR breakpoints/16889 * gdb.arch/amd64-stap-optional-prefix.S: New file. * gdb.arch/amd64-stap-optional-prefix.exp: Likewise.
2014-05-02 22:45:35 +02:00
2014-05-02 Sergio Durigan Junior <sergiodj@redhat.com>
PR breakpoints/16889
* gdb.arch/amd64-stap-optional-prefix.S: New file.
* gdb.arch/amd64-stap-optional-prefix.exp: Likewise.
gdb_load: Fix latent bugs In a test I was writting, I needed a procedure that would connect to the target, and do "load", or equivalent. Years ago, boards would override gdb_load to implement that. Then gdb_reload was added, and gdb_load was relaxed to allow boards avoid the spawing and connecting to the target. This sped up gdbserver testing. See https://www.sourceware.org/ml/gdb-patches/2007-02/msg00318.html. To actually spawn the target and load the executable on the target side, gdb_reload was born: # gdb_reload -- load a file into the target. Called before "running", # either the first time or after already starting the program once, # for remote targets. Most files that override gdb_load should now # override this instead. proc gdb_reload { } { # For the benefit of existing configurations, default to gdb_load. # Specifying no file defaults to the executable currently being # debugged. return [gdb_load ""] } Note the comment about specifying no file. Indeed looking at config/sid.exp, or config/monitor.exp, we see examples of that. However, the default gdb_load itself doesn't handle the case of no file specified. When passed no file, it just calls gdb_file_cmd with no file either, which ends up invocing the "file" command with no argument, which means unloading the file and its symbols... That means calling gdb_reload when testing against native targets is broken. We don't see that today because the only call to gdb_reload that exists today is guarded by target_info exists gdb,do_reload_on_run. The native-extended-gdbserver.exp board is likewise broken here. When [gdb_load ""] is called, the board sets the remote exec-file to "" ... Tested on x86_64 Fedora 17, native, remote gdbserver and extended-remote gdbserver. testsuite/ 2014-05-01 Pedro Alves <palves@redhat.com> * lib/gdb.exp (gdb_load): Extend comment. Skip calling gdb_file_cmd if no file is specified. * boards/native-extended-gdbserver.exp (gdb_load): Use the last_loaded_file to set the remote exec-file.
2014-05-02 01:59:31 +02:00
2014-05-01 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_load): Extend comment. Skip calling
gdb_file_cmd if no file is specified.
* boards/native-extended-gdbserver.exp (gdb_load): Use the
last_loaded_file to set the remote exec-file.
New testsuite/boards/local-remote-host.exp board, now with editing on This adds a variant of local-remote-host-notty.exp that forces pseudo-tty allocation, so that readline/editing is enabled. $ ssh localhost gdb -q (gdb) show editing Editing of command lines as they are typed is off. (gdb) vs: $ ssh -t localhost gdb -q (gdb) show editing Editing of command lines as they are typed is on. We now get, e.g.: Running ../../../src/gdb/testsuite/gdb.base/filesym.exp ... PASS: gdb.base/filesym.exp: complete on "filesy" PASS: gdb.base/filesym.exp: completion list for "filesym" PASS: gdb.base/filesym.exp: set breakpoint at filesym gdb/testsuite/ 2014-05-01 Pedro Alves <palves@redhat.com> * boards/local-remote-host.exp: New file.
2014-05-01 18:25:52 +02:00
2014-05-01 Pedro Alves <palves@redhat.com>
* boards/local-remote-host.exp: New file.
Rename testsuite/boards/local-remote-host.exp -> testsuite/boards/local-remote-host-notty.exp When testing with this board, stdin is not a tty, and so readline/editing is disabled: $ ssh localhost gdb -q (gdb) show editing Editing of command lines as they are typed is off. (gdb) Rename the file, to make room for a version of this board that forces a pseudo-tty. gdb/testsuite/ 2014-05-01 Pedro Alves <palves@redhat.com> * boards/local-remote-host.exp: Rename to ... * boards/local-remote-host-notty.exp: ... this.
2014-05-01 18:25:51 +02:00
2014-05-01 Pedro Alves <palves@redhat.com>
* boards/local-remote-host.exp: Rename to ...
* boards/local-remote-host-notty.exp: ... this.
Add gdb.ada/dyn_arrayidx testcase. This add a testcases that verifies correct handling of dynamicity for lower bounds of arrays. gdb/testsuite/ChangeLog: * gdb.ada/dyn_arrayidx: New testcase.
2014-04-20 07:19:02 +02:00
2014-04-28 Joel Brobecker <brobecker@adacore.com>
* gdb.ada/dyn_arrayidx: New testcase.
Compute the function length instead of hard coding it In Dwarf::assemble in dwz.exp, 10 is hard-coded in it, subprogram { {name main} {low_pc main addr} {high_pc "main + 10" addr} } however, the length of main function varies on architectures. The hard-coded 10 here causes dwz.exp fails on some targets, such as nios2. This patch is to add some code to compute the length of function main, which is similar to what we are doing in entry-values.exp. gdb/testsuite: 2014-04-26 Yao Qi <yao@codesourcery.com> * gdb.dwarf2/dwz.exp: Compile main.c to object. Restart GDB and compute the length of function main. Save it in $main_length. (Dwarf::assemble): Use $main_length instead of hard-coded 10. (top-level): Use gdb_compile to compile objects into executable and restart GDB. Remove invocation to prepare_for_testing.
2014-04-24 10:51:33 +02:00
2014-04-26 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dwz.exp: Compile main.c to object. Restart GDB
and compute the length of function main. Save it in
$main_length.
(Dwarf::assemble): Use $main_length instead of hard-coded 10.
(top-level): Use gdb_compile to compile objects into
executable and restart GDB. Remove invocation to
prepare_for_testing.
PR server/16255: gdbserver cannot attach to a second inferior that is multi-threaded. On Linux, we need to explicitly ptrace attach to all lwps of a process. Because GDB might not be connected yet when an attach is requested, and thus it may not be possible to activate thread_db, as that requires access to symbols (IOW, gdbserver --attach), a while ago we make linux_attach loop over the lwps as listed by /proc/PID/task to find the lwps to attach to. linux_attach_lwp_1 has: ... if (initial) /* If lwp is the tgid, we handle adding existing threads later. Otherwise we just add lwp without bothering about any other threads. */ ptid = ptid_build (lwpid, lwpid, 0); else { /* Note that extracting the pid from the current inferior is safe, since we're always called in the context of the same process as this new thread. */ int pid = pid_of (current_inferior); ptid = ptid_build (pid, lwpid, 0); } That "safe" comment referred to linux_attach_lwp being called by thread-db.c. But this was clearly missed when a new call to linux_attach_lwp_1 was added to linux_attach. As a result, current_inferior will be set to some random process, and non-initial lwps of the second inferior get assigned the pid of the wrong inferior. E.g., in the case of attaching to two inferiors, for the second inferior (and so on), non-initial lwps of the second inferior get assigned the pid of the first inferior. This doesn't trigger on the first inferior, when current_inferior is NULL, add_thread switches the current inferior to the newly added thread. Rather than making linux_attach switch current_inferior temporarily (thus avoiding further reliance on global state), or making linux_attach_lwp_1 get the tgid from /proc, which add extra syscalls, and will be wrong in case of the user having originally attached directly to a non-tgid lwp, and then that lwp spawning new clones (the ptid.pid field of further new clones should be the same as the original lwp's pid, which is not the tgid), we note that callers of linux_attach_lwp/linux_attach_lwp_1 always have the right pid handy already, so they can pass it down along with the lwpid. The only other reason for the "initial" parameter is to error out instead of warn in case of attach failure, when we're first attaching to a process. There are only three callers of linux_attach_lwp/linux_attach_lwp_1, and each wants to print a different warn/error string, so we can just move the error/warn out of linux_attach_lwp_1 to the callers, thus getting rid of the "initial" parameter. There really nothing gdbserver-specific about attaching to two threaded processes, so this adds a new test under gdb.multi/. The test passes cleanly against the native GNU/Linux target, but fails/triggers the bug against GDBserver (before the patch), with the native-extended-remote board (as plain remote doesn't support multi-process). Tested on x86_64 Fedora 17, with the native-extended-gdbserver board. gdb/gdbserver/ 2014-04-25 Pedro Alves <palves@redhat.com> PR server/16255 * linux-low.c (linux_attach_fail_reason_string): New function. (linux_attach_lwp): Delete. (linux_attach_lwp_1): Rename to ... (linux_attach_lwp): ... this. Take a ptid instead of a pid as argument. Remove "initial" parameter. Return int instead of void. Don't error or warn here. (linux_attach): Adjust to call linux_attach_lwp. Call error on failure to attach to the tgid. Call warning when failing to attach to an lwp. * linux-low.h (linux_attach_lwp): Take a ptid instead of a pid as argument. Remove "initial" parameter. Return int instead of void. Don't error or warn here. (linux_attach_fail_reason_string): New declaration. * thread-db.c (attach_thread): Adjust to linux_attach_lwp's interface change. Use linux_attach_fail_reason_string. gdb/ 2014-04-25 Pedro Alves <palves@redhat.com> PR server/16255 * common/linux-ptrace.c (linux_ptrace_attach_warnings): Rename to ... (linux_ptrace_attach_fail_reason): ... this. Remove "warning: " and newline from built string. * common/linux-ptrace.h (linux_ptrace_attach_warnings): Rename to ... (linux_ptrace_attach_fail_reason): ... this. * linux-nat.c (linux_nat_attach): Adjust to use linux_ptrace_attach_fail_reason. gdb/testsuite/ 2014-04-25 Simon Marchi <simon.marchi@ericsson.com> Pedro Alves <palves@redhat.com> PR server/16255 * gdb.multi/multi-attach.c: New file. * gdb.multi/multi-attach.exp: New file.
2014-04-25 20:07:33 +02:00
2014-04-25 Simon Marchi <simon.marchi@ericsson.com>
Pedro Alves <palves@redhat.com>
PR server/16255
* gdb.multi/multi-attach.c: New file.
* gdb.multi/multi-attach.exp: New file.
Fix several "set remote foo-packet on/off" commands. For several RSP packets, there's a corresponding "set remote foo-packet on/off/auto" command that one can use do bypass auto-detection of support for the packet or feature. However, I noticed that setting several of these commands to 'on' or 'off' doesn't actually have any effect. These are, at least: set remote breakpoint-commands-packet set remote conditional-breakpoints-packet set remote fast-tracepoints-packet set remote static-tracepoints-packet set remote install-in-trace-packet These are commands that control a remote protocol feature that doesn't have a corresponding regular packet, and because of that we cache the knowledge of the remote side support as returned by the qSupported packet in the remote_state object. E.g., in the case of the 'set remote breakpoint-commands-packet' command, whether the feature is supported is recorded in the 'breakpoint_commands' field of the remote_state object. Whether to bypass packet support auto-detection or not is controlled by the 'detect' field of the corresponding packet's packet_config structure. That field is the variable associated directly with the "set remote foo-packet" command. Actual remote stub support for the packet (or feature) is recorded in the 'support' field of the same structure. However, when the user toggles the command, the 'support' field is also correspondingly updated to PACKET_ENABLE/DISABLE/SUPPORT_UNKNOWN, discarding the knowledge of whether the target actually supports the feature. If one toggles back to 'auto', it's no big issue for real packets, as they'll just end up re-probed the next time they might be necessary. But features whose support is only reported through qSupported don't get their corresponding (manually added/maintained) fields in remote_state objected updated. As we lost the actual status of the target support for the feature, GDB would need to probe the qSupported features again, which GDB doesn't do. But we can avoid that extra traffic, and clean things up, IMO. Instead of going in that direction, this patch completely decouples struct packet_config's 'detect' and 'support' fields. E.g., when the user does "set remote foo-packet off", instead of setting the packet config's 'support' field to PACKET_DISABLE, the 'support' field is not touched at all anymore. That is, we end up respecting this simple table: | packet_config->detect | packet_config->support | should use packet/feature? | |-----------------------+------------------------+----------------------------| | auto | PACKET_ENABLE | PACKET_ENABLE | | auto | PACKET_DISABLE | PACKET_DISABLE | | auto | PACKET_UNKNOWN | PACKET_UNKNOWN | | yes | don't care | PACKET_ENABLE | | no | don't care | PACKET_DISABLE | This is implemented by the new packet_support function. With that, we need to update this pattern throughout: if (remote_protocol_packets[PACKET_foo].support == PACKET_DISABLE) to do this instead: if (packet_support (PACKET_qAttached) == PACKET_DISABLE) where as mentioned, the packet_support function takes struct packet_config's 'detect' field into account, like in the table above. As when the packet is force-disabled or force-enabled, the 'support' field is just ignored, if the command is set back to auto, we'll resume respecting whatever the target said it supports. IOW, the end result is that the 'support' field always represents whether the target actually supports the packet or not. After all that, the manually maintained breakpoint_commands and equivalent fields of struct remote_state can then be eliminated, with references replaced by checking the result of calling the packet_support function on the corresponding packet or feature. This required adding new PACKET_foo enum values for several features that didn't have it yet. (The patch does not add corresponding "set remote foo-packet" style commands though, focusing only on bug fixing and laying the groundwork). Tested on x86_64 Fedora 17, native GDBserver. The new tests all fail without this patch. gdb/ 2014-04-25 Pedro Alves <palves@redhat.com> * remote.c (struct remote_state): Remove multi_process_aware, non_stop_aware, cond_tracepoints, cond_breakpoints, breakpoint_commands, fast_tracepoints, static_tracepoints, install_in_trace, disconnected_tracing, enable_disable_tracepoints, string_tracing, and augmented_libraries_svr4_read fields. (remote_multi_process_p): Move further below in the file. (struct packet_config): Add comments. (update_packet_config): Delete function. (show_packet_config_cmd): Use packet_config_support. (add_packet_config_cmd): Use NULL as set callback. (packet_ok): "set remote foo-packet"-style commands no longer change config->supported -- adjust. (PACKET_ConditionalTracepoints, PACKET_ConditionalBreakpoints) (PACKET_BreakpointCommands, PACKET_FastTracepoints) (PACKET_StaticTracepoints, PACKET_InstallInTrace): Add comments. (PACKET_QNonStop, PACKET_multiprocess_feature) (PACKET_EnableDisableTracepoints_feature, PACKET_tracenz_feature) (PACKET_DisconnectedTracing_feature) (PACKET_augmented_libraries_svr4_read_feature): New enum values. (set_remote_protocol_packet_cmd): Delete function. (packet_config_support, packet_support): New functions. (set_remote_protocol_Z_packet_cmd): Don't call update_packet_config. (remote_query_attached, remote_pass_signals) (remote_program_signals, remote_threads_info) (remote_threads_extra_info, remote_start_remote): Use packet_support. (remote_start_remote): Use packet_config_support and packet_support. (init_all_packet_configs): Set all packets to unknown support, instead of calling update_packet_config. (remote_check_symbols): Use packet_support. (remote_supported_packet): Unconditionally set the packet config's support status. (remote_multi_process_feature, remote_non_stop_feature) (remote_cond_tracepoint_feature, remote_cond_breakpoint_feature) (remote_breakpoint_commands_feature) (remote_fast_tracepoint_feature, remote_static_tracepoint_feature) (remote_install_in_trace_feature) (remote_disconnected_tracing_feature) (remote_enable_disable_tracepoint_feature) (remote_string_tracing_feature) (remote_augmented_libraries_svr4_read_feature): Delete functions. (remote_protocol_features): Adjust to use remote_supported_packet for "augmented-libraries-svr4-read", "multiprocess", "QNonStop", "ConditionalTracepoints", "ConditionalBreakpoints", "BreakpointCommands", "FastTracepoints", "StaticTracepoints", "InstallInTrace", "DisconnectedTracing", "DisconnectedTracing", "EnableDisableTracepoints", and "tracenz". (remote_query_supported): Use packet_support. (remote_open_1): Adjust. (extended_remote_attach_1): Use packet_support. Switch on the result of packet_ok instead of checking whether the packet ended up disabled. (remote_vcont_resume): Use packet_support. (remote_resume, remote_stop_ns, fetch_register_using_p) (remote_prepare_to_store, store_register_using_P) (check_binary_download, remote_write_bytes): Use packet_support. (remote_vkill): Use packet_support. Switch on the result of packet_ok instead of checking whether the packet ended up disabled. (extended_remote_supports_disable_randomization): Use packet_support. (extended_remote_run): Switch on the result of packet_ok instead of checking whether the packet ended up disabled. (remote_insert_breakpoint, remote_remove_breakpoint) (remote_insert_watchpoint, remote_remove_watchpoint) (remote_insert_hw_breakpoint, remote_remove_hw_breakpoint): Use packet_support. (remote_search_memory): Use packet_config_support. (remote_get_thread_local_address, remote_get_tib_address) (remote_hostio_send_command, remote_can_execute_reverse): Use packet_support. (remote_supports_cond_tracepoints) (remote_supports_cond_breakpoints) (remote_supports_fast_tracepoints) (remote_supports_static_tracepoints) (remote_supports_install_in_trace) (remote_supports_enable_disable_tracepoint) (remote_supports_string_tracing) (remote_can_run_breakpoint_commands): Rewrite, checking whether the packet config says the feature is enabled or disabled. (remote_download_tracepoint, remote_trace_set_readonly_regions) (remote_get_trace_status): Use packet_support. (remote_set_disconnected_tracing): Adjust to check whether the feature is enabled with packet_support. (remote_set_trace_buffer_size, remote_use_agent) (remote_can_use_agent, remote_supports_btrace): Use packet_support. (remote_enable_btrace, remote_disable_btrace, remote_read_btrace): Use packet_config_support. (remote_augmented_libraries_svr4_read): Rewrite, checking whether the packet config says the feature is enabled or disabled. (set_range_stepping): Use packet_support. gdb/testsuite/ 2014-04-25 Pedro Alves <palves@redhat.com> * gdb.base/cond-eval-mode.exp (warning): Move trailing \r\n to user. (top level): Test that "set remote conditional-breakpoints-packet off" works as intended. * gdb.base/dprintf.exp: Test that "set remote breakpoint-commands-packet off" works as intended. * gdb.trace/change-loc.exp (tracepoint_install_in_trace_disabled): New function. (top level): Call it. * gdb.trace/ftrace.exp (test_fast_tracepoints): Test that "set remote fast-tracepoints-packet off" works as intended. * gdb.trace/qtro.exp (gdb_is_target_remote): Moved ... * lib/gdb.exp (gdb_is_target_remote): ... here.
2014-04-25 19:07:02 +02:00
2014-04-25 Pedro Alves <palves@redhat.com>
* gdb.base/cond-eval-mode.exp (warning): Move trailing \r\n to
user.
(top level): Test that "set remote conditional-breakpoints-packet
off" works as intended.
* gdb.base/dprintf.exp: Test that "set remote
breakpoint-commands-packet off" works as intended.
* gdb.trace/change-loc.exp (tracepoint_install_in_trace_disabled):
New function.
(top level): Call it.
* gdb.trace/ftrace.exp (test_fast_tracepoints): Test that "set
remote fast-tracepoints-packet off" works as intended.
* gdb.trace/qtro.exp (gdb_is_target_remote): Moved ...
* lib/gdb.exp (gdb_is_target_remote): ... here.
Ensure unreferenced static symbols aren't omitted by clang (either marking them __attribute__((used)) or making them non-static) gdb/testsuite/ * gdb.base/catch-syscall.c: Make unreferenced statics non-static to ensure clang would not discard them. * gdb.base/gdbvars.c: Ditto. * gdb.base/memattr.c: Ditto. * gdb.base/whatis.c: Ditto. * gdb.python/py-prettyprint.c: Ditto. * gdb.trace/actions.c: Ditto. * gdb.cp/ptype-cv-cp.cc: Mark unused global const int as used to ensure clang would not discard it.
2014-04-11 08:45:28 +02:00
2014-04-24 David Blaikie <dblaikie@gmail.com>
* gdb.base/catch-syscall.c: Make unreferenced statics non-static to
ensure clang would not discard them.
* gdb.base/gdbvars.c: Ditto.
* gdb.base/memattr.c: Ditto.
* gdb.base/whatis.c: Ditto.
* gdb.python/py-prettyprint.c: Ditto.
* gdb.trace/actions.c: Ditto.
* gdb.cp/ptype-cv-cp.cc: Mark unused global const int as used to
ensure clang would not discard it.
Cause clang to emit the definition of a type used only by pointer gdb/testsuite/ * gdb.stabs/gdb11479.c (tag_dummy_enum): introduce a variable to cause clang to emit the full definition of type required by the test * gdb.stabs/gdb11479.exp (do_test): correct a typo in a test message
2014-04-25 07:16:29 +02:00
2014-04-24 David Blaikie <dblaikie@gmail.com>
* gdb.stabs/gdb11479.c (tag_dummy_enum): introduce a variable to cause
clang to emit the full definition of type required by the test
* gdb.stabs/gdb11479.exp (do_test): correct a typo in a test message
Return by value to coax Clang into emitting the full definition of a test type. gdb/testsuite/ * gdb.cp/pr10728-x.cc: Return by value instead of pointer to coax Clang into emitting the definition of the type. * gdb.cp/pr10728-x.h: Ditto. * gdb.cp/pr10728-y.cc: Ditto.
2014-04-13 09:48:45 +02:00
2014-04-24 David Blaikie <dblaikie@gmail.com>
* gdb.cp/pr10728-x.cc (main::x): Return by value instead of pointer to
coax Clang into emitting the definition of the type.
* gdb.cp/pr10728-x.h (y): Ditto.
* gdb.cp/pr10728-y.cc (y): Ditto.
XFAIL under Clang tests using labels gdb/testsuite/ * gdb.base/label.exp: XFAIL label related tests under Clang. * gdb.cp/cplabel.exp: Ditto. * gdb.linespec/ls-errs.exp: Refactor tests to execute directly and XFAIL under Clang those using labels.
2014-04-13 20:42:02 +02:00
2014-04-24 David Blaikie <dblaikie@gmail.com>
* gdb.base/label.exp: XFAIL label related tests under Clang.
* gdb.cp/cplabel.exp: Ditto.
* gdb.linespec/ls-errs.exp: Refactor tests to execute directly and XFAIL
under Clang those using labels.
Remove unused labels in dwarf assembler I happen to see that 'double_label' isn't used in dwz.exp dwarf assembler. Similarly, partial_label and double_label aren't used in dwzbuildid.exp. This patch is to remove them. gdb/testsuite: 2014-04-25 Yao Qi <yao@codesourcery.com> * gdb.dwarf2/dwz.exp (Dwarf::assemble): Remove unused double_label. * gdb.dwarf2/dwzbuildid.exp (Dwarf::assemble): Remove partial_label and double_label.
2014-04-24 12:46:22 +02:00
2014-04-25 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dwz.exp (Dwarf::assemble): Remove unused
double_label.
* gdb.dwarf2/dwzbuildid.exp (Dwarf::assemble): Remove
partial_label and double_label.
Fix and XFAIL test due to GCC PR55641, passes with clang gdb/testsuite/ * gdb.python/lib-types.exp: Fix test and xfail under gcc due to gcc/55641.
2014-04-13 09:38:47 +02:00
2014-04-24 David Blaikie <dblaikie@gmail.com>
* gdb.python/lib-types.exp: Fix test and xfail under gcc due to gcc/55641.
Adjust start-of-function braces to be compatible with Clang gdb/testsuite/ * gdb.cp/cpexprs.cc: Move braces to the same line as the start of the function to work across GCC and Clang. * gdb.cp/cpexprs.exp: Account for GCC/Clang difference in vtable pointer types (const void ** const V void **).
2014-04-14 02:37:56 +02:00
2014-04-24 David Blaikie <dblaikie@gmail.com>
* gdb.cp/cpexprs.cc: Move braces to the same line as the start
of the function to work across GCC and Clang.
* gdb.cp/cpexprs.exp: Account for GCC/Clang difference in vtable
pointer types (const void ** const V void **).
Add AVX512 registers support to GDB and GDBserver. This patch adds support for the Intel(R) Advanced Vector Extensions 512 (Intel(R) AVX-512) registers. Native and remote debugging are covered by this patch. Intel(R) AVX-512 is an extension to AVX to support 512-bit wide SIMD registers in 64-bit mode (XMM0-XMM31, YMM0-YMM31, ZMM0-ZMM31). The number of available registers in 32-bit mode is still 8 (XMM0-7, YMM0-7, ZMM0-7). The lower 256-bits of the ZMM registers are aliased to the respective 256-bit YMM registers. The lower 128-bits are aliased to the respective 128-bit XMM registers. There are also 8 new, dedicated mask registers (K0-K7) in both 32-bit mode and 64-bit mode. For more information please see Intel(R) Developer Zone: Intel(R) AVX http://software.intel.com/en-us/intel-isa-extensions#pid-16007-1495 Intel(R) Architecture Instruction Set Extensions Programming Reference: http://software.intel.com/en-us/file/319433-017pdf 2014-04-24 Michael Sturm <michael.sturm@mintel.com> Walfred Tedeschi <walfred.tedeschi@intel.com> * amd64-linux-nat.c (amd64_linux_gregset32_reg_offset): Add AVX512 registers. (amd64_linux_read_description): Add code to handle AVX512 xstate mask and return respective tdesc. * amd64-linux-tdep.c: Include features/i386/amd64-avx512-linux.c and features/i386/x32-avx512-linux.c. (amd64_linux_gregset_reg_offset): Add AVX512 registers. (amd64_linux_core_read_description): Add code to handle AVX512 xstate mask and return respective tdesc. (_initialize_amd64_linux_tdep): Initialize AVX512 tdesc. * amd64-linux-tdep.h (AMD64_LINUX_ORIG_RAX_REGNUM): Adjust regnum calculation. (AMD64_LINUX_NUM_REGS): Adjust to new number of registers. (tdesc_amd64_avx512_linux): New prototype. (tdesc_x32_avx512_linux): Likewise. * amd64-tdep.c: Include features/i386/amd64-avx512.c and features/i386/x32-avx512.c. (amd64_ymm_avx512_names): New register names for pseudo registers YMM16-31. (amd64_ymmh_avx512_names): New register names for raw registers YMMH16-31. (amd64_k_names): New register names for K registers. (amd64_zmmh_names): New register names for ZMM raw registers. (amd64_zmm_names): New registers names for ZMM pseudo registers. (amd64_xmm_avx512_names): New register names for XMM16-31 registers. (amd64_pseudo_register_name): Add code to return AVX512 pseudo registers. (amd64_init_abi): Add code to intitialize AVX512 tdep variables if feature is present. (_initialize_amd64_tdep): Call AVX512 tdesc initializers. * amd64-tdep.h (enum amd64_regnum): Add AVX512 registers. (AMD64_NUM_REGS): Adjust to new number of registers. * i386-linux-nat.c (GETXSTATEREGS_SUPPLIES): Extend range of registers supplied via XSTATE by AVX512 registers. (i386_linux_read_description): Add case for AVX512. * i386-linux-tdep.c: Include i386-avx512-linux.c. (i386_linux_gregset_reg_offset): Add AVX512 registers. (i386_linux_core_read_description): Add case for AVX512. (i386_linux_init_abi): Install supported register note section for AVX512. (_initialize_i386_linux_tdep): Add call to tdesc init function for AVX512. * i386-linux-tdep.h (I386_LINUX_NUM_REGS): Set number of registers to be number of zmm7h + 1. (tdesc_i386_avx512_linux): Add tdesc for AVX512 registers. * i386-tdep.c: Include features/i386/i386-avx512.c. (i386_zmm_names): Add ZMM pseudo register names array. (i386_zmmh_names): Add ZMM raw register names array. (i386_k_names): Add K raw register names array. (num_lower_zmm_regs): Add constant for the number of lower ZMM registers. AVX512 has 16 more ZMM registers than there are YMM registers. (i386_zmmh_regnum_p): Add function to look up register number of ZMM raw registers. (i386_zmm_regnum_p): Likewise for ZMM pseudo registers. (i386_k_regnum_p): Likewise for K raw registers. (i386_ymmh_avx512_regnum_p): Likewise for additional YMM raw registers added by AVX512. (i386_ymm_avx512_regnum_p): Likewise for additional YMM pseudo registers added by AVX512. (i386_xmm_avx512_regnum_p): Likewise for additional XMM registers added by AVX512. (i386_register_name): Add code to hide YMMH16-31 and ZMMH0-31. (i386_pseudo_register_name): Add ZMM pseudo registers. (i386_zmm_type): Construct and return vector registers type for ZMM registers. (i386_pseudo_register_type): Return appropriate type for YMM16-31, ZMM0-31 pseudo registers and K registers. (i386_pseudo_register_read_into_value): Add code to read K, ZMM and YMM16-31 registers from register cache. (i386_pseudo_register_write): Add code to write K, ZMM and YMM16-31 registers. (i386_register_reggroup_p): Add code to include/exclude AVX512 registers in/from respective register groups. (i386_validate_tdesc_p): Handle AVX512 feature, add AVX512 registers if feature is present in xcr0. (i386_gdbarch_init): Add code to initialize AVX512 feature variables in tdep structure, wire in pseudo registers and call initialize_tdesc_i386_avx512. * i386-tdep.h (struct gdbarch_tdep): Add AVX512 related variables. (i386_regnum): Add AVX512 registers. (I386_SSE_NUM_REGS): New define for number of SSE registers. (I386_AVX_NUM_REGS): Likewise for AVX registers. (I386_AVX512_NUM_REGS): Likewise for AVX512 registers. (I386_MAX_REGISTER_SIZE): Change to 64 bytes, ZMM registers are 512 bits wide. (i386_xmm_avx512_regnum_p): New prototype for register look up. (i386_ymm_avx512_regnum_p): Likewise. (i386_k_regnum_p): Likewise. (i386_zmm_regnum_p): Likewise. (i386_zmmh_regnum_p): Likewise. * i387-tdep.c : Update year in copyright notice. (xsave_ymm_avx512_offset): New table for YMM16-31 offsets in XSAVE buffer. (XSAVE_YMM_AVX512_ADDR): New macro. (xsave_xmm_avx512_offset): New table for XMM16-31 offsets in XSAVE buffer. (XSAVE_XMM_AVX512_ADDR): New macro. (xsave_avx512_k_offset): New table for K register offsets in XSAVE buffer. (XSAVE_AVX512_K_ADDR): New macro. (xsave_avx512_zmm_h_offset): New table for ZMM register offsets in XSAVE buffer. (XSAVE_AVX512_ZMM_H_ADDR): New macro. (i387_supply_xsave): Add code to supply AVX512 registers to XSAVE buffer. (i387_collect_xsave): Add code to collect AVX512 registers from XSAVE buffer. * i387-tdep.h (I387_NUM_XMM_AVX512_REGS): New define for number of XMM16-31 registers. (I387_NUM_K_REGS): New define for number of K registers. (I387_K0_REGNUM): New define for K0 register number. (I387_NUM_ZMMH_REGS): New define for number of ZMMH registers. (I387_ZMM0H_REGNUM): New define for ZMM0H register number. (I387_NUM_YMM_AVX512_REGS): New define for number of YMM16-31 registers. (I387_YMM16H_REGNUM): New define for YMM16H register number. (I387_XMM16_REGNUM): New define for XMM16 register number. (I387_YMM0_REGNUM): New define for YMM0 register number. (I387_KEND_REGNUM): New define for last K register number. (I387_ZMMENDH_REGNUM): New define for last ZMMH register number. (I387_YMMH_AVX512_END_REGNUM): New define for YMM31 register number. (I387_XMM_AVX512_END_REGNUM): New define for XMM31 register number. * common/i386-xstate.h: Add AVX 3.1 feature bits, mask and XSTATE size. * features/Makefile: Add AVX512 related files. * features/i386/32bit-avx512.xml: New file. * features/i386/64bit-avx512.xml: Likewise. * features/i386/amd64-avx512-linux.c: Likewise. * features/i386/amd64-avx512-linux.xml: Likewise. * features/i386/amd64-avx512.c: Likewise. * features/i386/amd64-avx512.xml: Likewise. * features/i386/i386-avx512-linux.c: Likewise. * features/i386/i386-avx512-linux.xml: Likewise. * features/i386/i386-avx512.c: Likewise. * features/i386/i386-avx512.xml: Likewise. * features/i386/x32-avx512-linux.c: Likewise. * features/i386/x32-avx512-linux.xml: Likewise. * features/i386/x32-avx512.c: Likewise. * features/i386/x32-avx512.xml: Likewise. * regformats/i386/amd64-avx512-linux.dat: New file. * regformats/i386/amd64-avx512.dat: Likewise. * regformats/i386/i386-avx512-linux.dat: Likewise. * regformats/i386/i386-avx512.dat: Likewise. * regformats/i386/x32-avx512-linux.dat: Likewise. * regformats/i386/x32-avx512.dat: Likewise. * NEWS: Add note about new support for AVX512. testsuite/ * Makefile.in (EXECUTABLES): Added i386-avx512. * gdb.arch/i386-avx512.c: New file. * gdb.arch/i386-avx512.exp: Likewise. gdbserver/ * Makefile.in: Added rules to handle new files i386-avx512.c i386-avx512-linux.c amd64-avx512.c amd64-avx512-linux.c x32-avx512.c x32-avx512-linux.c. * configure.srv (srv_i386_regobj): Add i386-avx512.o. (srv_i386_linux_regobj): Add i386-avx512-linux.o. (srv_amd64_regobj): Add amd64-avx512.o and x32-avx512.o. (srv_amd64_linux_regobj): Add amd64-avx512-linux.o and x32-avx512-linux.o. (srv_i386_32bit_xmlfiles): Add i386/32bit-avx512.xml. (srv_i386_64bit_xmlfiles): Add i386/64bit-avx512.xml. (srv_amd64_xmlfiles): Add i386/amd64-avx512.xml and i386/x32-avx512.xml. (srv_i386_linux_xmlfiles): Add i386/i386-avx512-linux.xml. (srv_amd64_linux_xmlfiles): Add i386/amd64-avx512-linux.xml and i386/x32-avx512-linux.xml. * i387-fp.c (num_avx512_k_registers): New constant for number of K registers. (num_avx512_zmmh_low_registers): New constant for number of lower ZMM registers (0-15). (num_avx512_zmmh_high_registers): New constant for number of higher ZMM registers (16-31). (num_avx512_ymmh_registers): New contant for number of higher YMM registers (ymm16-31 added by avx521 on x86_64). (num_avx512_xmm_registers): New constant for number of higher XMM registers (xmm16-31 added by AVX512 on x86_64). (struct i387_xsave): Add space for AVX512 registers. (i387_cache_to_xsave): Change raw buffer size to 64 characters. Add code to handle AVX512 registers. (i387_xsave_to_cache): Add code to handle AVX512 registers. * linux-x86-low.c (init_registers_amd64_avx512_linux): New prototypei from generated file. (tdesc_amd64_avx512_linux): Likewise. (init_registers_x32_avx512_linux): Likewise. (tdesc_x32_avx512_linux): Likewise. (init_registers_i386_avx512_linux): Likewise. (tdesc_i386_avx512_linux): Likewise. (x86_64_regmap): Add AVX512 registers. (x86_linux_read_description): Add code to handle AVX512 XSTATE mask. (initialize_low_arch): Add code to initialize AVX512 registers. doc/ * gdb.texinfo (i386 Features): Add description of AVX512 registers. Change-Id: Ifc4c08c76b85dbec18d02efdbe6182e851584438 Signed-off-by: Michael Sturm <michael.sturm@intel.com>
2013-12-16 16:43:05 +01:00
2014-04-24 Michael Sturm <michael.sturm@mintel.com>
Walfred Tedeschi <walfred.tedeschi@intel.com>
* Makefile.in (EXECUTABLES): Added i386-avx512.
* gdb.arch/i386-avx512.c: New file.
* gdb.arch/i386-avx512.exp: Likewise.
Introduce some new MI test suite cleanups for breakpoint and breakpoint table handling. This is a patch in five parts (all committed here in one commit). ----- 1/5: parse_args parse_args is a very useful utility function which allows you to do getopt-y kinds of things in Tcl. Example: proc myproc {foo args} { parse_args {{bar} {baz "abc"} {qux}} # ... } myproc ABC -bar -baz DEF peanut butter will define the following variables in myproc: foo (=ABC), bar (=1), baz (=DEF), and qux (=0) args will be the list {peanut butter} ----- 2/5: mi_build_kv_pairs build_kv_pairs simply does what it says: given the input list and an option join string, it combines list elements into kv-pairs for MI handling. It knows how to handle tuples and other special MI types. Example: mi_build_kv_pairs {a b c d e f g \[.*\]} returns a=\"b\",c=\"d\",e=\"f\",g=\[.*\] ----- 3/5: mi_make_breakpoint This function builds breakpoint regexps, such as "bkpt={number=\".*\", [snip]}". Note that ONLY the options given to mi_make_breakpoint/mi_create_breakpoint will actually be tested. So if -number is omitted, the regexp will allow anything [number=\".*\"] Examples: mi_make_breakpoint -number 3 mi_create_breakpoint "myfile.c:21" -file myfile.c -line 21 ----- 4/5: mi_make_breakpoint_table This function builds MI breakpoint table regexps. Example: set bps {} lappend bps [mi_make_breakpoint -number 1 -func "main" \ -file ".*/myfile.c" -line 42 lappend bps [mi_make_breakpoint -number 2 -func "marker" \ -file ".*myfile.c" -line 21 gdb_test "-break-info" "\\^done,[mi_make_breakpoint_table $bps]" \ "breakpoint list" ----- 5/5: Update all callers Self-explanatory testsuite/ChangeLog 2014-04-23 Keith Seitz <keiths@redhat.com> * lib/mi-support.exp (mi_list_breakpoints): Delete. (mi_make_breakpoint_table): New procedure. (mi_create_breakpoint): Use mi_make_breakpoint and return the result. (mi_make_breakpoint): New procedure. (mi_build_kv_pairs): New procedure. * gdb.mi/mi-break.exp: Remove unused globals, update mi_create_breakpoint usage, and use mi_make_breakpoint_table. All callers updated. * gdb.mi/mi-dprintf.exp: Use variable to track command number. Update all callers of mi_create_breakpoint and use mi_make_breakpoint_table. Remove any unused global variables. * gdb.mi/mi-nonstop.exp: Likewise. * gdb.mi/mi-nsintrall.exp: Likewise. * gdb.mi/mi-nsmoribund.exp: Likewise. * gdb.mi/mi-nsthrexec.exp: Likewise. * gdb.mi/mi-reverse.exp: Likewise. * gdb.mi/mi-simplerun.exp: Likewise. * gdb.mi/mi-stepn.exp: Likewise. * gdb.mi/mi-syn-frame.exp: Likewise. * gdb.mi/mi-until.exp: Likewise. * gdb.mi/mi-var-cp.exp: Likewise. * gdb.mi/mi-var-display.exp: Likewise. * gdb.mi/mi2-amd64-entry-value.exp: Likewise. * gdb.mi/mi2-var-child.exp: Likewise. * gdb.mi/mi-vla-c99.exp: Likewise. * lib/mi-support.exp: Likewise. From Ian Lance Taylor <iant@cygnus.com>: * lib/gdb.exp (parse_args): New procedure.
2014-04-23 21:17:31 +02:00
2014-04-23 Keith Seitz <keiths@redhat.com>
* lib/mi-support.exp (mi_list_breakpoints): Delete.
(mi_make_breakpoint_table): New procedure.
(mi_create_breakpoint): Use mi_make_breakpoint
and return the result.
(mi_make_breakpoint): New procedure.
(mi_build_kv_pairs): New procedure.
* gdb.mi/mi-break.exp: Remove unused globals,
update mi_create_breakpoint usage, and use mi_make_breakpoint_table.
All callers updated.
* gdb.mi/mi-dprintf.exp: Use variable to track command
number.
Update all callers of mi_create_breakpoint and use
mi_make_breakpoint_table.
Remove any unused global variables.
* gdb.mi/mi-nonstop.exp: Likewise.
* gdb.mi/mi-nsintrall.exp: Likewise.
* gdb.mi/mi-nsmoribund.exp: Likewise.
* gdb.mi/mi-nsthrexec.exp: Likewise.
* gdb.mi/mi-reverse.exp: Likewise.
* gdb.mi/mi-simplerun.exp: Likewise.
* gdb.mi/mi-stepn.exp: Likewise.
* gdb.mi/mi-syn-frame.exp: Likewise.
* gdb.mi/mi-until.exp: Likewise.
* gdb.mi/mi-var-cp.exp: Likewise.
* gdb.mi/mi-var-display.exp: Likewise.
* gdb.mi/mi2-amd64-entry-value.exp: Likewise.
* gdb.mi/mi2-var-child.exp: Likewise.
* gdb.mi/mi-vla-c99.exp: Likewise.
* lib/mi-support.exp: Likewise.
From Ian Lance Taylor <iant@cygnus.com>:
* lib/gdb.exp (parse_args): New procedure.
Stale breakpoint instructions, spurious SIGTRAPS. Without the code portion of the patch, we get these failures: FAIL: gdb.base/break-unload-file.exp: always-inserted on: break: continue FAIL: gdb.base/break-unload-file.exp: always-inserted on: hbreak: continue FAIL: gdb.base/sym-file.exp: stale bkpts: continue to breakpoint: end here They all looks like random SIGTRAPs: continue Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000000400541 in foo () at ../../../src/gdb/testsuite/gdb.base/break-unload-file.c:21 21 } (gdb) FAIL: gdb.base/break-unload-file.exp: always-inserted on: break: continue (This is a regression caused by the remove-symbol-file command series.) break-unload-file.exp is about having breakpoints inserted, and then doing "file". I caught this while writing a test that does "file PROGRAM", while PROGRAM was already loaded, which internally does "file" first, because I wanted to force a breakpoint_re_set, but the test is more explicit in case GDB ever optimizes out that re-set. The problem is that unloading the file with "file" ends up in disable_breakpoints_in_freed_objfile, which marks all breakpoint locations of the objfile as both shlib_disabled, _and_ clears the inserted flag, without actually removing the breakpoints from the inferior. Now, usually, in all-stop, breakpoints will already be removed from the inferior before the user can issue the "file" command, but, with non-stop, or breakpoints always-inserted on mode, breakpoints stay inserted even while the user has the prompt. In the latter case, then, if we let the program continue, and it executes the address where we had previously set the breakpoint, it'll actually execute the breakpoint instruction that we left behind... Now, one issue is that the intent of disable_breakpoints_in_freed_objfile is really to handle the unloading of OBJF_USERLOADED objfiles. These are objfiles that were added with add-symbol-file and that are removed with remove-symbol-file. "add-symbol-file"'s docs in the manual clearly say these commands are used to let GDB know about dynamically loaded code: You would use this command when @var{filename} has been dynamically loaded (by some other means) into the program that is running. Similarly, the online help says: (gdb) help add-symbol-file Load symbols from FILE, assuming FILE has been dynamically loaded. So it makes sense to, like when shared libraries are unloaded through the generic solib machinery, mark the breakpoint locations as shlib_disabled. But, the "file" command is not about dynamically loaded code, it's about the main program. So the patch makes disable_breakpoints_in_freed_objfile skip all objfiles but OBJF_USERLOADED ones, thus skipping the main objfile. Then, the reason that disable_breakpoints_in_freed_objfile was clearing the inserted flag isn't clear, but likely to avoid breakpoint removal errors, assuming remove-symbol-file was called after the dynamic object was already unmapped from the inferior. In that case, it'd okay to simply clear the inserted flag, but not so if the user for example does remove-symbol-file to remove the library because he made a mistake in the library's address, and wants to re-do add-symbol-file with the correct address. To address all that, I propose an alternative implementation, that handles both cases. The patch includes changes to sym-file.exp to cover them. This implementation leaves the inserted flag alone, and handles breakpoint insertion/removal failure gracefully when the locations are in OBJF_USERLOADED objfiles, just like we handle insertion/removal failure gracefully for locations in shared libraries. To try to make sure we aren't patching back stale shadow memory contents into the inferior, in case the program mapped a different library at the same address where we had the breakpoint, without the user having had a chance of remove-symbol-file'ing before, this adds a new memory_validate_breakpoint function that checks if the breakpoint instruction is still in memory. ppc_linux_memory_remove_breakpoint does this unconditionally for all memory breakpoints, and questions whether memory_remove_breakpoint should be changed to do this for all breakpoints. Possibly yes, though I'm not certain, hence this baby-steps patch. Tested on x86_64 Fedora 17, native and gdbserver. gdb/ 2014-04-23 Pedro Alves <palves@redhat.com> * breakpoint.c (insert_bp_location): Tolerate errors if the breakpoint is set in a user-loaded objfile. (remove_breakpoint_1): Likewise. Also tolerate errors if the location is marked shlib_disabled. If the breakpoint is set in a user-loaded objfile is a GDB-side memory breakpoint, validate it before uninsertion. (disable_breakpoints_in_freed_objfile): Skip non-OBJF_USERLOADED objfiles. Don't clear the location's inserted flag. * mem-break.c (memory_validate_breakpoint): New function. * objfiles.c (userloaded_objfile_contains_address_p): New function. * objfiles.h (userloaded_objfile_contains_address_p): Declare. * target.h (memory_validate_breakpoint): New declaration. gdb/testsuite/ 2014-04-23 Pedro Alves <palves@redhat.com> * gdb.base/break-unload-file.c: New file. * gdb.base/break-unload-file.exp: New file. * gdb.base/sym-file-lib.c (baz): New function. * gdb.base/sym-file-loader.c (struct segment) <mapped_size>: New field. (load): Store the segment's mapped size. (unload): New function. (unload_shlib): New function. * gdb.base/sym-file-loader.h (unload_shlib): New declaration. * gdb.base/sym-file-main.c (main): Unload, and reload the library, set a breakpoint at baz, and call it. * gdb.base/sym-file.exp: New tests for stale breakpoint instructions.
2014-04-23 00:19:19 +02:00
2014-04-23 Pedro Alves <palves@redhat.com>
* gdb.base/break-unload-file.c: New file.
* gdb.base/break-unload-file.exp: New file.
* gdb.base/sym-file-lib.c (baz): New function.
* gdb.base/sym-file-loader.c (struct segment) <mapped_size>: New
field.
(load): Store the segment's mapped size.
(unload): New function.
(unload_shlib): New function.
* gdb.base/sym-file-loader.h (unload_shlib): New declaration.
* gdb.base/sym-file-main.c (main): Unload, and reload the library,
set a breakpoint at baz, and call it.
* gdb.base/sym-file.exp: New tests for stale breakpoint
instructions.
Don't suppress errors inserting/removing hardware breakpoints in shared libraries. As explained in https://sourceware.org/ml/gdb-patches/2008-08/msg00361.html, after a shared library was unloaded, we can no longer insert or remove breakpoints into/from its (no longer present) code segment. That'll fail with memory errors. However, that concern does not apply to hardware breakpoints. By definition, hardware breakpoints are implemented using a mechanism that is not dependent on being able to modify the target's memory. Usually, by setting up CPU debug registers. IOW, we should be able to set hw breakpoints in an unmapped address. We don't seem to have a test that exercises that, so this patch adds one. I noticed the error supression because of a related issue -- the target_insert_hw_breakpoint/target_remove_hw_breakpoint interfaces don't really distinguish "not supported" from "error" return, and so remote.c returns -1 in both cases. This results in hardware breakpoints set in shared libraries silently ending up pending forever even though the target doesn't actually support hw breakpoints. (gdb) set breakpoint always-inserted on (gdb) set remote Z-packet off (gdb) info breakpoints No breakpoints or watchpoints. (gdb) hbreak shrfunc Hardware assisted breakpoint 3 at 0x7ffff7dfb657: file ../../../src/gdb/testsuite/gdb.base/hbreak-in-shr-unsupported-shr.c, line 21. (gdb) info break Num Type Disp Enb Address What 3 hw breakpoint keep y <PENDING> shrfunc After the patch we get the expected: (gdb) hbreak shrfunc Hardware assisted breakpoint 3 at 0x7ffff7dfb657: file ../../../src/gdb/testsuite/gdb.base/hbreak-in-shr-unsupported-shr.c, line 21. Warning: Cannot insert hardware breakpoint 3. Could not insert hardware breakpoints: You may have requested too many hardware breakpoints/watchpoints. (gdb) info break Num Type Disp Enb Address What 3 hw breakpoint keep y 0x00007ffff7dfb657 in shrfunc at ../../../src/gdb/testsuite/gdb.base/hbreak-in-shr-unsupported-shr.c:21 (HW breakpoints set in the main executable, when the target doesn't support HW breakpoints always resulted in the latter output.) We probably should improve the insert/remove interface to return a different error code for unsupported. But I chose to fix the error supression first, as it's a deeper and wider issue. Tested on x86_64 Fedora 17, native and gdbserver. gdb/ 2014-04-23 Pedro Alves <palves@redhat.com> * breakpoint.c (insert_bp_location, remove_breakpoint_1): If the breakpoint is set in a shared library, only suppress errors for software breakpoints, not hardware breakpoints. gdb/testsuite/ 2014-04-23 Pedro Alves <palves@redhat.com> * gdb.base/hbreak-in-shr-unsupported-shr.c: New file. * gdb.base/hbreak-in-shr-unsupported.c: New file. * gdb.base/hbreak-in-shr-unsupported.exp: New file. * gdb.base/hbreak-unmapped.c: New file. * gdb.base/hbreak-unmapped.exp: New file. * gdb.trace/qtro.exp (gdb_is_target_remote): Move ... * lib/gdb.exp (gdb_is_target_remote): ... here.
2014-04-23 16:06:47 +02:00
2014-04-23 Pedro Alves <palves@redhat.com>
* gdb.base/hbreak-in-shr-unsupported-shr.c: New file.
* gdb.base/hbreak-in-shr-unsupported.c: New file.
* gdb.base/hbreak-in-shr-unsupported.exp: New file.
* gdb.base/hbreak-unmapped.c: New file.
* gdb.base/hbreak-unmapped.exp: New file.
* gdb.trace/qtro.exp (gdb_is_target_remote): Move ...
* lib/gdb.exp (gdb_is_target_remote): ... here.
Consecutive step-overs trigger internal error. If a thread trips on a breakpoint that needs stepping over just after finishing a step over, GDB currently fails an assertion. This is a regression caused by the "Handle multiple step-overs." patch (99619beac6252113fed212fdb9e1ab97bface423) at https://sourceware.org/ml/gdb-patches/2014-02/msg00765.html. (gdb) x /4i $pc => 0x400540 <main+4>: movl $0x0,0x2003da(%rip) # 0x600924 <i> 0x40054a <main+14>: movl $0x1,0x2003d0(%rip) # 0x600924 <i> 0x400554 <main+24>: movl $0x2,0x2003c6(%rip) # 0x600924 <i> 0x40055e <main+34>: movl $0x3,0x2003bc(%rip) # 0x600924 <i> (gdb) PASS: gdb.base/consecutive-step-over.exp: get breakpoint addresses break *0x40054a Breakpoint 2 at 0x40054a: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 23. (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 1: set breakpoint condition $bpnum condition (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 1: set condition break *0x400554 Breakpoint 3 at 0x400554: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 24. (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 2: set breakpoint condition $bpnum condition (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 2: set condition break *0x40055e Breakpoint 4 at 0x40055e: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 25. (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 3: set breakpoint condition $bpnum condition (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 3: set condition break 27 Breakpoint 5 at 0x400568: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 27. (gdb) continue Continuing. ../../src/gdb/infrun.c:5200: internal-error: switch_back_to_stepped_thread: Assertion `!tp->control.trap_expected' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. FAIL: gdb.base/consecutive-step-over.exp: continue to breakpoint: break here (GDB internal error) The assertion fails, because the code is not expecting that the event thread itself might need another step over. IOW, not expecting that TP in: tp = find_thread_needs_step_over (stepping_thread != NULL, stepping_thread); could be the event thread. A small fix for this would be to clear the event thread's trap_expected earlier, before asserting. But looking deeper, although currently_stepping_or_nexting_callback's intention is finding the thread that is doing a step/next, it also returns the thread that is doing a step-over dance, with trap_expected set. If there ever was a reason for that (it was I who added currently_stepping_or_nexting_callback , but I can't recall why I put trap_expected there in the first place), the only remaining reason nowadays is to aid in implementing switch_back_to_stepped_thread's assertion that is now triggering, by piggybacking on the walk over all threads, thus avoiding a separate walk. This is quite obscure, and I think we can do even better, by merging the walks that look for the stepping thread, and the walk that looks for some thread that might need a step over. Tested on x86_64 Fedora 17, native and gdbserver, and also native on top of my "software single-step on x86_64" series. gdb/ 2014-04-22 Pedro Alves <palves@redhat.com> * infrun.c (schedlock_applies): New function, factored out from find_thread_needs_step_over. (find_thread_needs_step_over): Use it. (switch_back_to_stepped_thread): Always clear trap_expected if the step over is finished. Return early if scheduler locking applies. Look for the stepping thread and a potential step-over thread with a single loop. (currently_stepping_or_nexting_callback): Delete. 2014-04-22 Pedro Alves <palves@redhat.com> * gdb.base/consecutive-step-over.c: New file. * gdb.base/consecutive-step-over.exp: New file.
2014-04-22 16:00:56 +02:00
2014-04-22 Pedro Alves <palves@redhat.com>
* gdb.base/consecutive-step-over.c: New file.
* gdb.base/consecutive-step-over.exp: New file.
Make gdb_continue_to_breakpoint fail quickly on internal errors. This switches the gdb_continue_to_breakpoint routine to use gdb_test_multiple instead of send_gdb/gdb_expect, so that an internal error is detected immediately, instead of failing on timeout. gdb/testsuite/ 2014-04-22 Pedro Alves <palves@redhat.com> * lib/gdb.exp (gdb_continue_to_breakpoint): Use gdb_test_multiple instead of send_gdb/gdb_expect.
2014-04-22 20:15:48 +02:00
2014-04-22 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_continue_to_breakpoint): Use gdb_test_multiple
instead of send_gdb/gdb_expect.
Check tracefile is generated by binary execution In gdb.trace/tfile.exp, we execute binary to generate tracefile, remote_exec target "$binfile" however, this fails on bare metal target. This patch is to handle binary execution failure by running binary in GDB. The binary will do some io operation to generate tracefile, so we need a check 'target_info exists gdb,nofileio'. This patch is to check whether tracefile is generated. tfile.exp can be skipped if generation is failed, while test_tfind_tfile in mi-traceframe-changed.exp is skipped if generated failed. The rest of the mi-traceframe-changed.exp can still be executed, because on some bare metal targets, the remote stub supports tracepoint but doesn't support fileio. gdb/testsuite: 2014-04-22 Yao Qi <yao@codesourcery.com> * lib/trace-support.exp (generate_tracefile): New procedure. * gdb.trace/tfile.exp: Skip the test if generate_tracefile return 0. * gdb.trace/mi-traceframe-changed.exp: Invoke test_tfind_tfile if generate_tracefile returns 1.
2014-03-21 05:52:24 +01:00
2014-04-22 Yao Qi <yao@codesourcery.com>
* lib/trace-support.exp (generate_tracefile): New procedure.
* gdb.trace/tfile.exp: Skip the test if generate_tracefile
return 0.
* gdb.trace/mi-traceframe-changed.exp: Invoke test_tfind_tfile
if generate_tracefile returns 1.
Fix PR backtrace/15558 This PR is about an assertion failure in GDB that can be triggered by setting "backtrace limit" to a value that causes GDB to stop unwinding after an inline frame. In this case, an assertion in inline_frame_this_id will trigger: /* We need a valid frame ID, so we need to be based on a valid frame. (...). */ gdb_assert (frame_id_p (*this_id)); Looking at the function: static void inline_frame_this_id (struct frame_info *this_frame, void **this_cache, struct frame_id *this_id) { struct symbol *func; /* In order to have a stable frame ID for a given inline function, we must get the stack / special addresses from the underlying real frame's this_id method. So we must call get_prev_frame. Because we are inlined into some function, there must be previous frames, so this is safe - as long as we're careful not to create any cycles. */ *this_id = get_frame_id (get_prev_frame (this_frame)); we see we're computing the frame id for the inline frame. If this is an inline frame, which is a virtual frame constructed based on debug info, on top of a real stack frame, we should _always_ be able to find where the frame was inlined into, as that ultimately just means peeling off the virtual frames on top of the real stack frame. If there ultimately was no prev (real) stack frame, then we wouldn't have been able to construct the inline frame either, by design. That's what the assertion catches. So we have an inline frame, we should _always_ be able to compute its ID, even if that means bypassing the user backtrace limits to get at the real stack frame's info. The problem is that inline_frame_id calls get_prev_frame, and that takes user backtrace limits into account. Code that wants to bypass the limits calls get_prev_frame_1 instead. Note how get_prev_frame_1 already skips all checks for inline frames: /* If we are unwinding from an inline frame, all of the below tests were already performed when we unwound from the next non-inline frame. We must skip them, since we can not get THIS_FRAME's ID until we have unwound all the way down to the previous non-inline frame. */ if (get_frame_type (this_frame) == INLINE_FRAME) return get_prev_frame_if_no_cycle (this_frame); And note how the related frame_unwind_caller_id function also uses get_prev_frame_1: struct frame_id frame_unwind_caller_id (struct frame_info *next_frame) { struct frame_info *this_frame; /* Use get_prev_frame_1, and not get_prev_frame. The latter will truncate the frame chain, leading to this function unintentionally returning a null_frame_id (e.g., when a caller requests the frame ID of "main()"s caller. */ next_frame = skip_artificial_frames (next_frame); this_frame = get_prev_frame_1 (next_frame); if (this_frame) return get_frame_id (skip_artificial_frames (this_frame)); else return null_frame_id; } get_prev_frame_1 is currently static in frame.c. As a _1 suffix is not a good name for an extern function, I've renamed it. Tested on x86-64 Fedora 17. gdb/ 2014-04-18 Pedro alves <palves@redhat.com> Tom Tromey <tromey@redhat.com> PR backtrace/15558 * frame.c (get_prev_frame_1): Rename to ... (get_prev_frame_always): ... this, and make extern. Adjust. (skip_artificial_frames): Use get_prev_frame_always. (frame_unwind_caller_id, frame_pop, get_prev_frame) (get_frame_unwind_stop_reason): Adjust to rename. * frame.h (get_prev_frame_always): Declare. * inline-frame.c: Include frame.h. (inline_frame_this_id): Use get_prev_frame_always. gdb/testsuite/ 2014-04-18 Tom Tromey <palves@redhat.com> Pedro alves <tromey@redhat.com> PR backtrace/15558 * gdb.opt/inline-bt.exp: Test backtracing from an inline function with a backtrace limit. * gdb.python/py-frame-inline.exp: Test running to an inline function with a backtrace limit, and printing the newest frame. * gdb.python/py-frame-inline.c (main): Call f.
2014-04-18 11:15:21 +02:00
2014-04-18 Tom Tromey <palves@redhat.com>
Pedro alves <tromey@redhat.com>
PR backtrace/15558
* gdb.opt/inline-bt.exp: Test backtracing from an inline function
with a backtrace limit.
* gdb.python/py-frame-inline.exp: Test running to an inline
function with a backtrace limit, and printing the newest frame.
* gdb.python/py-frame-inline.c (main): Call f.
Drop srcdir from untested source path.
2014-04-17 16:26:37 +02:00
2014-04-17 Marcus Shawcroft <marcus.shawcroft@arm.com>
* gdb.java/jnpe.exp: Drop srcdir from untested path.
Drop prefix from unsupported source path.
2014-04-17 11:52:43 +02:00
2014-04-17 Marcus Shawcroft <marcus.shawcroft@arm.com>
* lib/gdb.exp (gdb_compile_pthreads, gdb_compile_objc):
Drop prefix from unsupported source file path.
[testsuite] Set target-charset to ascii Hi, We find gdb.base/printcmds.exp fails a lot on windows host, like this, p ctable1[163] $204 = 163 '£' (gdb) FAIL: gdb.base/printcmds.exp: p ctable1[163] however, on linux host, p ctable1[163] $205 = 163 '\243' (gdb) PASS: gdb.base/printcmds.exp: p ctable1[163] The printing related code is in valprint.c:print_wchar, if (gdb_iswprint (w) && (!need_escape || (!gdb_iswdigit (w) && w != LCST ('8') && w != LCST ('9')))) { gdb_wchar_t wchar = w; if (w == gdb_btowc (quoter) || w == LCST ('\\')) obstack_grow_wstr (output, LCST ("\\")); obstack_grow (output, &wchar, sizeof (gdb_wchar_t)); } else { // print W in hex or octal digits } When I debug gdb on different hosts, I find on windows host, gdb_iswprint (iswprint) returns true if 'w' is 163. However, on linux host, iswprint returns false if 'w' is 163. Looks this difference is caused by the charset. On Linux host, the target-charset is ANSI_X3.4-1968, while on windows host, the target-charset is CP1252. We can see how target-charset affects the output. On linux host, (gdb) set target-charset ASCII (gdb) p ctable1[163] $1 = 163 '\243' (gdb) set target-charset CP1252 (gdb) p ctable1[163] $2 = 163 '£' we can print the pound sign too, and it shows target-charset does affect the output. This patch is to set target-charset temporarily to ASCII for some charset-sensitive tests. Tested on arm-none-eabi and powerpc-linux-gnu on mingw32 host. More than one hundred fails are fixed. gdb/testsuite: 2014-04-17 Yao Qi <yao@codesourcery.com> * lib/gdb.exp (with_target_charset): New proc. * gdb.base/printcmds.exp (test_print_all_chars): Wrap tests with with_target_charset. (test_print_strings): Likewise. (test_repeat_bytes): Likewise. * gdb.base/setvar.exp: Set target-charset to ASCII temporarily for some tests.
2014-03-24 04:26:06 +01:00
2014-04-17 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (with_target_charset): New proc.
* gdb.base/printcmds.exp (test_print_all_chars): Wrap tests with
with_target_charset.
(test_print_strings): Likewise.
(test_repeat_bytes): Likewise.
* gdb.base/setvar.exp: Set target-charset to ASCII temporarily
for some tests.
PR gdb/15827 Install some sanity checks that sibling DIE offsets are not beyond the defined limits of the DWARF input buffer in read_partial_die and skip_one_die. 2014-03-20 Keith Seitz <keiths@redhat.com> PR gdb/15827 * dwarf2read.c (skip_one_die): Check that all relative-offset sibling DIEs fall within range of the current reader's buffer. (read_partial_die): Likewise. 2014-03-20 Keith Seitz <keiths@redhat.com> PR gdb/15827 * gdb.dwarf2/corrupt.c: New file. * gdb.dwarf2/corrupt.exp: New file.
2014-04-16 23:39:10 +02:00
2014-04-16 Keith Seitz <keiths@redhat.com>
PR gdb/15827
* gdb.dwarf2/corrupt.c: New file.
* gdb.dwarf2/corrupt.exp: New file.
PR c++/16597 [forgot to commit/push these with previous push] If lookup_symbol_file tries to locate a member variable with NULL name: /* A simple lookup failed. Check if the symbol was defined in a base class. */ cleanup = make_cleanup (null_cleanup, NULL); /* Find the name of the class and the name of the method, variable, etc. */ prefix_len = cp_entire_prefix_len (name); /* If no prefix was found, search "this". */ if (prefix_len == 0) { struct type *type; struct symbol *this; this = lookup_language_this (language_def (language_cplus), block); if (this == NULL) { do_cleanups (cleanup); return NULL; } type = check_typedef (TYPE_TARGET_TYPE (SYMBOL_TYPE (this))); klass = xstrdup (TYPE_NAME (type)); nested = xstrdup (name); } TYPE_NAME (type) is NULL, so xstrdup (NULL) and boom! This can happen, e.g., with clang++. See testsuite/gdb.cp/namelessclass.exp or the bugzilla report. This patch simply adds a fencepost against this case, allowing the caller of lookup_symbol_file to search other blocks for the right symbol.
2014-04-16 23:20:19 +02:00
2014-04-16 Keith Seitz <keiths@redhat.com>
PR c++/16597
* gdb.cp/namelessclass.cc: New file.
* gdb.cp/namelessclass.exp: New file.
* gdb.cp/namelessclass.S: New file.
Fix wrapper.exp testcase with stdio gdbserver. * lib/gdbserver-support.exp (gdbserver_default_get_remote_address): Add comment. (gdbserver_default_get_comm_port): New function. (gdbserver_start): Check if board file provided "gdbserver,get_comm_port" and use it if so. * boards/native-stdio-gdbserver.exp (sockethost): Set to "". (gdb,socketport): Set to "stdio". (gdbserver,get_comm_port): Set to ${board}_get_comm_port. (stdio_gdbserver_template): Delete. (${board}_get_remote_address): Update. (${board}_build_remote_cmd): Delete. (${board}_get_comm_port): New function. (${board}_spawn): Update. * boards/remote-stdio-gdbserver.exp (${board}_build_remote_cmd): Delete. (${board}_get_remote_address): Update. (${board}_get_comm_port): New function.
2014-04-16 19:40:41 +02:00
2014-04-16 Doug Evans <dje@google.com>
* lib/gdbserver-support.exp (gdbserver_default_get_remote_address):
Add comment.
(gdbserver_default_get_comm_port): New function.
(gdbserver_start): Check if board file provided
"gdbserver,get_comm_port" and use it if so.
* boards/native-stdio-gdbserver.exp (sockethost): Set to "".
(gdb,socketport): Set to "stdio".
(gdbserver,get_comm_port): Set to ${board}_get_comm_port.
(stdio_gdbserver_template): Delete.
(${board}_get_remote_address): Update.
(${board}_build_remote_cmd): Delete.
(${board}_get_comm_port): New function.
(${board}_spawn): Update.
* boards/remote-stdio-gdbserver.exp (${board}_build_remote_cmd):
Delete.
(${board}_get_remote_address): Update.
(${board}_get_comm_port): New function.
gdb.base/memattr.exp regexp improvements. https://sourceware.org/ml/gdb-patches/2014-04/msg00210.html Improve the regexp used in the memattr.exp test so allow for different memory regions (.data / .bss) being laid out in different orders. gdb/testsuite/ChangeLog: * gdb.base/memattr.exp: Improve regexps to handle memory regions appearing in any order.
2014-04-16 18:42:29 +02:00
2014-04-16 Andrew Burgess <aburgess@broadcom.com>
* gdb.base/memattr.exp: Improve regexps to handle memory regions
appearing in any order.
* gdb.gdb/selftest.exp (do_steps_and_nexts): Don't reference uninitialized value of "description".
2014-04-16 01:11:32 +02:00
2014-04-15 Doug Evans <dje@google.com>
* gdb.gdb/selftest.exp (do_steps_and_nexts): Don't reference
uninitialized value of "description".
Remove unused globals in mi-simplerun.exp. 2014-04-15 Keith Seitz <keiths@redhat.com> * gdb.mi/mi-simplerun.exp (test_breakpoints_creation_and_listing): Remove unused globals. (test_running_the_program): Likewise. (test_controlled_execution): Likewise. (test_controlling_breakpoints): Likewise. (test_program_termination): Likewise.
2014-04-15 21:07:33 +02:00
2014-04-15 Keith Seitz <keiths@redhat.com>
* gdb.mi/mi-simplerun.exp (test_breakpoints_creation_and_listing):
Remove unused globals.
(test_running_the_program): Likewise.
(test_controlled_execution): Likewise.
(test_controlling_breakpoints): Likewise.
(test_program_termination): Likewise.
Test suite cleanup. 2014-04-15 Keith Seitz <keiths@redhat.com> * gdb.mi/mi-break.exp (test_tbreak_creation_and_listing): Remove unused globals. (test_rbreak_creation_and_listing): Likewise. (test_ignore_count): Likewise. (test_error): Likewise.
2014-04-15 20:47:57 +02:00
2014-04-15 Keith Seitz <keiths@redhat.com>
* gdb.mi/mi-break.exp (test_tbreak_creation_and_listing): Remove
unused globals.
(test_rbreak_creation_and_listing): Likewise.
(test_ignore_count): Likewise.
(test_error): Likewise.
gdb.base/sym-file.exp, hide guts of the custom loader. This test uses a simple custom elf loader, implemented in gdb.base/sym-file-loader.h|c. This loader doesn't have a dlclose-like function today, but I'll need one. But, I found that the guts of the loader are exposed too much to the client, making the interface more complicated than necessary. It's simpler if the loader just exports a few dlopen/dlsym -style functions. That's what this patch does. Tested on x86_86 Fedora 17, native and gdbserver. gdb/testsuite/ 2014-04-15 Pedro Alves <palves@redhat.com> * gdb.base/sym-file-loader.h: Move inclusion of <inttypes.h>, <ansidecl.h>, <elf/common.h> and <elf/external.h> to sym-file-loader.c. (Elf_External_Phdr, Elf_External_Ehdr, Elf_External_Shdr) (Elf_External_Sym, Elf_Addr, GET, GETADDR, struct segment): Move to sym-file-loader.c. (struct library): Forward declare. (load_shlib, lookup_function): Change prototypes. (find_shstrtab, find_strtab, find_shdr, find_symtab) (translate_offset): Remove declarations. (get_text_addr): New declaration. * gdb.base/sym-file-loader.c: Move inclusion of <inttypes.h>, <ansidecl.h>, <elf/common.h> and <elf/external.h> here from sym-file-loader.h. (Elf_External_Phdr, Elf_External_Ehdr, Elf_External_Shdr) (Elf_External_Sym, Elf_Addr, GET, GETADDR, struct segment): Move here from sym-file-loader.h. (struct library): New structure. (load_shlib, lookup_function): Change prototypes and adjust to work with a struct library. (find_shstrtab, find_strtab, find_shdr, find_symtab) (translate_offset): Make static. (get_text_addr): New function. * gdb.base/sym-file-main.c (main): Adjust to new loader interface.
2014-04-15 15:02:34 +02:00
2014-04-15 Pedro Alves <palves@redhat.com>
* gdb.base/sym-file-loader.h: Move inclusion of <inttypes.h>,
<ansidecl.h>, <elf/common.h> and <elf/external.h> to
sym-file-loader.c.
(Elf_External_Phdr, Elf_External_Ehdr, Elf_External_Shdr)
(Elf_External_Sym, Elf_Addr, GET, GETADDR, struct segment): Move
to sym-file-loader.c.
(struct library): Forward declare.
(load_shlib, lookup_function): Change prototypes.
(find_shstrtab, find_strtab, find_shdr, find_symtab)
(translate_offset): Remove declarations.
(get_text_addr): New declaration.
* gdb.base/sym-file-loader.c: Move inclusion of <inttypes.h>,
<ansidecl.h>, <elf/common.h> and <elf/external.h> here from
sym-file-loader.h.
(Elf_External_Phdr, Elf_External_Ehdr, Elf_External_Shdr)
(Elf_External_Sym, Elf_Addr, GET, GETADDR, struct segment): Move
here from sym-file-loader.h.
(struct library): New structure.
(load_shlib, lookup_function): Change prototypes and adjust to
work with a struct library.
(find_shstrtab, find_strtab, find_shdr, find_symtab)
(translate_offset): Make static.
(get_text_addr): New function.
* gdb.base/sym-file-main.c (main): Adjust to new loader interface.
gdb.base/sym-file-loader.c: Fix typo. SELF_LINK, not SELK_LINK... gdb/testsuite/ 2014-04-15 Pedro Alves <palves@redhat.com> * gdb.base/sym-file-loader.c: Fix typo. SELF_LINK, not SELK_LINK.
2014-04-15 15:13:08 +02:00
2014-04-15 Pedro Alves <palves@redhat.com>
* gdb.base/sym-file-loader.c: Fix typo. SELF_LINK, not SELK_LINK.
Make sym-file.exp work with remote targets and hosts. The main issue here is that this test passes the host's absolute path to the library to load to the "dlopen"-like routine, which doesn't work when either the target or the host are remote, unless a shared filesystem has been set up. Tests that dynamically load a library solve this by dlopen'ing by basename, and setting rpath to $ORIGIN. See gdb_compile. This test doesn't use dlopen, but instead uses its own simple elf loader. The fix is to pass this loader the library basename, and teach it to look up the library by basename in the executable's directory as well, i.e., assuming/emulating RPATH=$ORIGIN. Tested on x86_64 Fedora 17, native and gdbserver. I looked around in the web to figure out Linux's /proc/self/exe equivalents in other ELF OSs. I think I covered all relevant, but if not, I think it'll be simple enough to add more. (Note the test is skipped on non-ELF targets.) Tested on x86_64 Fedora 17, native and gdbserver. gdb/testsuite/ 2014-04-15 Pedro Alves <palves@redhat.com> * gdb.base/sym-file-loader.c: Include <limits.h>. (SELF_LINK): New define. (get_origin): New function. (load_shlib): Use it. * gdb.base/sym-file.exp: Don't early return if the target is remote. Use runto_main, and issue fail is that fails. Use gdb_load_shlibs. (shlib_name): Delete. (lib_so, lib_syms, lib_dlopen): New globals. Use them throughout.
2014-04-14 18:23:55 +02:00
2014-04-15 Pedro Alves <palves@redhat.com>
* gdb.base/sym-file-loader.c: Include <limits.h>.
(SELF_LINK): New define.
(get_origin): New function.
(load_shlib): Use it.
* gdb.base/sym-file.exp: Don't early return if the target is
remote. Use runto_main, and issue fail is that fails. Use
gdb_load_shlibs.
(shlib_name): Delete.
(lib_so, lib_syms, lib_dlopen): New globals. Use them throughout.
gdb.base/sym-file.exp: clean up test messages a bit. Remove regex characters from test message, and don't refer to breakpoint numbers in test messages (subsequent patches will add more breakpoints, changing these numbers). Result: -PASS: gdb.base/sym-file.exp: add-symbol-file .*sym-file-lib\.so addr +PASS: gdb.base/sym-file.exp: add-symbol-file sym-file-lib.so addr -PASS: gdb.base/sym-file.exp: check if Breakpoint 2 is pending. -PASS: gdb.base/sym-file.exp: check if Breakpoint 3 is pending. +PASS: gdb.base/sym-file.exp: breakpoint at foo is pending +PASS: gdb.base/sym-file.exp: breakpoint at bar is pending gdb/testsuite/ 2014-04-15 Pedro Alves <palves@redhat.com> * gdb.base/sym-file.exp: Remove regex characters from test message. Don't refer to breakpoint numbers in test messages.
2014-04-15 13:49:51 +02:00
2014-04-15 Pedro Alves <palves@redhat.com>
* gdb.base/sym-file.exp: Remove regex characters from test
message. Don't refer to breakpoint numbers in test messages.
Remove symbol_matches_domain. This fixes PR c++/16253. symbol_matches_domain was permitting searches for a VAR_DOMAIN symbol to also match STRUCT_DOMAIN symbols for languages like C++ where STRUCT_DOMAIN symbols also define a typedef of the same name, e.g., "struct foo {}" introduces a typedef of the name "foo". Problems occur if there exists both a VAR_DOMAIN and STRUCT_DOMAIN symbol of the same name. Then it is essentially a race between which symbol is found first. The other symbol is obscurred. [This is a relatively common idiom: enum e { ... } e;] This patchset moves this "language defines a typedef" logic to lookup_symbol[_in_language], looking first for a symbol in the given domain and falling back to searching STRUCT_DOMAIN when/if appropriate. 2014-04-14 Keith Seitz <keiths@redhat.com> PR c++/16253 * ada-lang.c (ada_symbol_matches_domain): Moved here and renamed from symbol_matches_domain in symtab.c. All local callers of symbol_matches_domain updated. (standard_lookup): If DOMAIN is VAR_DOMAIN and no symbol is found, search STRUCT_DOMAIN. (ada_find_any_type_symbol): Do not search STRUCT_DOMAIN independently. standard_lookup will do that automatically. * cp-namespace.c (cp_lookup_symbol_nonlocal): Explain when/why VAR_DOMAIN searches may return a STRUCT_DOMAIN match. (cp_lookup_symbol_in_namespace): Likewise. If no VAR_DOMAIN symbol is found, search STRUCT_DOMAIN. (cp_lookup_symbol_exports): Explain when/why VAR_DOMAIN searches may return a STRUCT_DOMAIN match. (lookup_symbol_file): Search for the class name in STRUCT_DOMAIN. * cp-support.c: Include language.h. (inspect_type): Explicitly search STRUCT_DOMAIN before searching VAR_DOMAIN. * psymtab.c (match_partial_symbol): Compare the requested domain with the symbol's domain directly. (lookup_partial_symbol): Likewise. * symtab.c (lookup_symbol_in_language): Explain when/why VAR_DOMAIN searches may return a STRUCT_DOMAIN match. If no VAR_DOMAIN symbol is found, search STRUCT_DOMAIN for appropriate languages. (symbol_matches_domain): Renamed `ada_symbol_matches_domain' and moved to ada-lang.c (lookup_block_symbol): Explain that this function only returns symbol matching the requested DOMAIN. Compare the requested domain with the symbol's domain directly. (iterate_over_symbols): Compare the requested domain with the symbol's domain directly. * symtab.h (symbol_matches_domain): Remove. 2014-04-14 Keith Seitz <keiths@redhat.com> PR c++/16253 * gdb.cp/var-tag.cc: New file. * gdb.cp/var-tag.exp: New file. * gdb.dwarf2/dw2-ada-ffffffff.exp: Set the language to C++. * gdb.dwarf2/dw2-anon-mptr.exp: Likewise. * gdb.dwarf2/dw2-double-set-die-type.exp: Likewise. * gdb.dwarf2/dw2-inheritance.exp: Likewise.
2014-04-15 00:47:15 +02:00
2014-04-14 Keith Seitz <keiths@redhat.com>
PR c++/16253
* gdb.cp/var-tag.cc: New file.
* gdb.cp/var-tag.exp: New file.
* gdb.dwarf2/dw2-ada-ffffffff.exp: Set the language to C++.
* gdb.dwarf2/dw2-anon-mptr.exp: Likewise.
* gdb.dwarf2/dw2-double-set-die-type.exp: Likewise.
* gdb.dwarf2/dw2-inheritance.exp: Likewise.
implement support for "enum class" This adds support for the C++11 "enum class" feature. This is PR c++/15246. I chose to use the existing TYPE_DECLARED_CLASS rather than introduce a new type code. This seemed both simple and clear to me. I made overloading support for the new enum types strict. This is how it works in C++; and it didn't seem like an undue burden to keep this, particularly because enum constants are printed symbolically by gdb. Built and regtested on x86-64 Fedora 20. 2014-04-14 Tom Tromey <tromey@redhat.com> PR c++/15246: * c-exp.y (type_aggregate_p): New function. (qualified_name, classify_inner_name): Use it. * c-typeprint.c (c_type_print_base): Handle TYPE_DECLARED_CLASS and TYPE_TARGET_TYPE of an enum type. * dwarf2read.c (read_enumeration_type): Set TYPE_DECLARED_CLASS on an enum type. (determine_prefix) <case DW_TAG_enumeration_type>: New case; handle TYPE_DECLARED_CLASS. * gdbtypes.c (rank_one_type): Handle TYPE_DECLARED_CLASS on enum types. * gdbtypes.h (TYPE_DECLARED_CLASS): Update comment. * valops.c (enum_constant_from_type): New function. (value_aggregate_elt): Use it. * cp-namespace.c (cp_lookup_nested_symbol): Handle TYPE_CODE_ENUM. 2014-04-14 Tom Tromey <tromey@redhat.com> * gdb.cp/classes.exp (test_enums): Handle underlying type. * gdb.dwarf2/enum-type.exp: Add test for enum with underlying type. * gdb.cp/enum-class.exp: New file. * gdb.cp/enum-class.cc: New file.
2014-03-27 19:24:27 +01:00
2014-04-14 Tom Tromey <tromey@redhat.com>
* gdb.cp/classes.exp (test_enums): Handle underlying type.
* gdb.dwarf2/enum-type.exp: Add test for enum with underlying
type.
* gdb.cp/enum-class.exp: New file.
* gdb.cp/enum-class.cc: New file.
handle DW_AT_type on an enumeration DWARF allows an enumeration type to have a DW_AT_type. GDB doesn't recognize this, but there is a patch to change GCC to emit it, and a DWARF proposal to further allow an enum type with a DW_AT_type to omit the DW_AT_byte_size. This patch changes gdb to implement this. Built and regtested on x86-64 Fedora 20. 2014-04-14 Tom Tromey <tromey@redhat.com> * dwarf2read.c (read_enumeration_type): Handle DW_AT_type. 2014-04-14 Tom Tromey <tromey@redhat.com> * gdb.dwarf2/enum-type.exp: New file.
2014-03-26 15:54:56 +01:00
2014-04-14 Tom Tromey <tromey@redhat.com>
* gdb.dwarf2/enum-type.exp: New file.
test: add mi vla test testsuite/ChangeLog: * gdb.mi/mi-vla-c99.exp: New file. * gdb.mi/vla.c: New file.
2013-11-15 13:48:00 +01:00
2014-04-14 Sanimir Agovic <sanimir.agovic@intel.com>
* gdb.mi/mi-vla-c99.exp: New file.
* gdb.mi/vla.c: New file.
test: basic c99 vla tests for C primitives gdb/testsuite/ChangeLog: * gdb.base/vla-datatypes.c: New file. * gdb.base/vla-datatypes.exp: New file.
2013-11-15 13:47:47 +01:00
2014-04-14 Sanimir Agovic <sanimir.agovic@intel.com>
* gdb.base/vla-datatypes.c: New file.
* gdb.base/vla-datatypes.exp: New file.
test: evaluate pointers to C99 vla correctly. gdb/testsuite/ChangeLog: * gdb.base/vla-ptr.c: New file. * gdb.base/vla-ptr.exp: New file.
2013-11-15 13:47:44 +01:00
2014-04-14 Sanimir Agovic <sanimir.agovic@intel.com>
* gdb.base/vla-ptr.c: New file.
* gdb.base/vla-ptr.exp: New file.
test: cover subranges with present DW_AT_count attribute The dwarf attribute DW_AT_count specifies the elements of a subrange. This test covers subranges with present count but absent upper bound attribute, both with static and dynamic attribute values. testsuite/ChangeLog: * gdb.dwarf2/count.exp: New file.
2013-11-26 15:47:16 +01:00
2014-04-14 Sanimir Agovic <sanimir.agovic@intel.com>
* gdb.dwarf2/count.exp: New file.
vla: evaluate operand of sizeof if its type is a vla The c99 standard in "6.5.3.4 The sizeof operator" states: If the type of the operand is a variable length array type, the operand is evaluated;[...] This patch mirrors the following c99 semantic in gdb: 1| int vla[n][m]; 2| int i = 1; 3| sizeof(vla[i++][0]); // No sideffect 4| assert (i == 1); 5| sizeof(vla[i++]); // With sideffect 6| assert (i == 2); Note: ptype/whatis still do not allow any sideeffects. This patch was motivated by: https://sourceware.org/ml/gdb-patches/2014-01/msg00732.html gdb/ChangeLog: * eval.c (evaluate_subexp_for_sizeof): Add enum noside argument. (evaluate_subexp_standard): Pass noside argument. (evaluate_subexp_for_sizeof) <BINOP_SUBSCRIPT>: Handle subscript case if noside equals EVAL_NORMAL. If the subscript yields a vla type re-evaluate subscript operation with EVAL_NORMAL to enable sideffects. * gdbtypes.c (resolve_dynamic_bounds): Mark bound as evaluated. * gdbtypes.h (enum range_flags): Add RANGE_EVALUATED case. testsuite/ChangeLog: * gdb.base/vla-sideeffect.c: New file. * gdb.base/vla-sideeffect.exp: New file.
2014-02-05 17:22:08 +01:00
2014-04-14 Sanimir Agovic <sanimir.agovic@intel.com>
* gdb.base/vla-sideeffect.c: New file.
* gdb.base/vla-sideeffect.exp: New file.
Add return value for non-void function return statements to fix error in clang build. Clang defaults this warning to an error, breaking the build & causing these tests not to run. gdb/testsuite/ * gdb.mi/non-stop.c: Add return value for non-void function return statement. * gdb.threads/staticthreads.c: Ditto.
2014-04-12 02:20:49 +02:00
2014-04-14 David Blaikie <dblaikie@gmail.com>
* gdb.mi/non-stop.c: Add return value for non-void function return
statement.
* gdb.threads/staticthreads.c: Ditto.
Copy over fix for fetching dynamic type of a reference from python side. * guile/scm-value.c (gdbscm_value_dynamic_type): Use coerce_ref to dereference TYPE_CODE_REF values. testsuite/ * gdb.guile/scm-value.c: Improve test case. * gdb.guile/scm-value.exp: Add new test.
2014-04-12 18:09:41 +02:00
2014-04-12 Siva Chandra Reddy <sivachandra@google.com>
Doug Evans <xdje42@gmail.com>
* gdb.guile/scm-value.c: Improve test case.
* gdb.guile/scm-value.exp: Add new test.
Compile inline test with -std=gnu89 explicitly to override Clang's default (-std=c99) gdb/testsuite/ * gdb.opt/inline-break.exp: Explicitly specify -std=gnu89 to override Clang's default.
2014-04-11 21:45:37 +02:00
2014-04-11 David Blaikie <dblaikie@gmail.com>
* gdb.opt/inline-break.exp: Explicitly specify -std=gnu89 to
override Clang's default.
Revert the entire VLA series. This reverts the following patch series, as they cause some regresssions. commit 37c1ab67a35025d37d42c449deab5f254f9f59da type: add c99 variable length array support gdb/ * dwarf2loc.c (dwarf2_locexpr_baton_eval): New function. (dwarf2_evaluate_property): New function. * dwarf2loc.h (dwarf2_evaluate_property): New function prototype. * dwarf2read.c (attr_to_dynamic_prop): New function. (read_subrange_type): Use attr_to_dynamic_prop to read high bound attribute. * gdbtypes.c: Include dwarf2loc.h. (is_dynamic_type): New function. (resolve_dynamic_type): New function. (resolve_dynamic_bounds): New function. (get_type_length): New function. (check_typedef): Use get_type_length to compute type length. * gdbtypes.h (TYPE_HIGH_BOUND_KIND): New macro. (TYPE_LOW_BOUND_KIND): New macro. (is_dynamic_type): New function prototype. * value.c (value_from_contents_and_address): Call resolve_dynamic_type to resolve dynamic properties of the type. Update comment. * valops.c (get_value_at, value_at, value_at_lazy): Update comment. commit 26cb189f8b46dbe7b2d485525329a8919005ca8a vla: enable sizeof operator to work with variable length arrays gdb/ * eval.c (evaluate_subexp_for_sizeof) <OP_VAR_VALUE>: If the type passed to sizeof is dynamic evaluate the argument to compute the length. commit 04b19544ef6a97b62b2cc4a3170b900e046ab185 vla: enable sizeof operator for indirection gdb/ * eval.c (evaluate_subexp_for_sizeof) <UNOP_IND>: Create an indirect value and retrieve the dynamic type size. commit bcd629a44fff61527430f353cf77e20fe3afc395 vla: update type from newly created value gdb/ * ada-lang.c (ada_value_primitive_packed_val): Re-fetch type from value. (ada_template_to_fixed_record_type_1): Likewise. (ada_to_fixed_type_1): Likewise. * cp-valprint.c (cp_print_value_fields_rtti): Likewise. (cp_print_value): Likewise. * d-valprint.c (dynamic_array_type): Likewise. * eval.c (evaluate_subexp_with_coercion): Likewise. * findvar.c (address_of_variable): Likewise. * jv-valprint.c (java_value_print): Likewise. * valops.c (value_ind): Likewise. * value.c (coerce_ref): Likewise. commit b86138fb0484f42db6cb83abed1e3d0ad2ec4eac vla: print "variable length" for unresolved dynamic bounds gdb/ * c-typeprint.c (c_type_print_varspec_suffix): Added check for not yet resolved high bound. If unresolved, print "variable length" string to the console instead of random length. commit e1969afbd454c09c3aad1990305715f70bc47c3c vla: support for DW_AT_count gdb/ * dwarf2read.c (read_subrange_type): Convert DW_AT_count to a dynamic property and store it as the high bound and flag the range accordingly. * gdbtypes.c (resolve_dynamic_bounds): If range is flagged as RANGE_UPPER_BOUND_IS_COUNT assign low + high - 1 as the new high bound. * gdbtypes.h (enum range_flags): New enum. (struct range_bounds): Add flags member. commit 92b09522dc5a93ba4bda3c1c0b3c58264e357c8a vla: resolve dynamic bounds if value contents is a constant byte-sequence gdb/ * findvar.c (default_read_var_value): Resolve dynamic bounds if location points to a constant blob. commit 3bce82377f683870cc89925ff43aefb7dcce4a77 vla: evaluate operand of sizeof if its type is a vla gdb/ * eval.c (evaluate_subexp_for_sizeof): Add enum noside argument. (evaluate_subexp_standard): Pass noside argument. (evaluate_subexp_for_sizeof) <BINOP_SUBSCRIPT>: Handle subscript case if noside equals EVAL_NORMAL. If the subscript yields a vla type re-evaluate subscript operation with EVAL_NORMAL to enable sideffects. * gdbtypes.c (resolve_dynamic_bounds): Mark bound as evaluated. * gdbtypes.h (enum range_flags): Add RANGE_EVALUATED case. gdb/testsuite * gdb.base/vla-sideeffect.c: New file. * gdb.base/vla-sideeffect.exp: New file. commit 504f34326e5ae7c78ebfcdd6ed03c7403b42048b test: cover subranges with present DW_AT_count attribute gdb/testsuite/ * gdb.dwarf2/count.exp: New file. commit 1a237e0ee53bbdee97d72d794b5b42e774cc81c0 test: multi-dimensional c99 vla. gdb/testsuite/ * gdb.base/vla-multi.c: New file. * gdb.base/vla-multi.exp: New file. commit 024e13b46f9c33d151ae82fd9d64c53092fd9313 test: evaluate pointers to C99 vla correctly. gdb/testsuite/ * gdb.base/vla-ptr.c: New file. * gdb.base/vla-ptr.exp: New file. commit c8655f75e2f0fada311be193e3090087a77ec802 test: basic c99 vla tests for C primitives gdb/testsuite/ * gdb.base/vla-datatypes.c: New file. * gdb.base/vla-datatypes.exp: New file. commit 58a84dcf29b735ee776536b4c51ba90b51612b71 test: add mi vla test gdb/testsuite/ * gdb.mi/mi-vla-c99.exp: New file. * gdb.mi/vla.c: New file.
2014-04-11 23:47:15 +02:00
2014-04-11 Joel Brobecker <brobecker@adacore.com>
Revert the following changes (regressions):
* gdb.base/vla-sideeffect.c: New file.
* gdb.base/vla-sideeffect.exp: New file.
* gdb.dwarf2/count.exp: New file.
* gdb.base/vla-multi.c: New file.
* gdb.base/vla-multi.exp: New file.
* gdb.base/vla-ptr.c: New file.
* gdb.base/vla-ptr.exp: New file.
* gdb.base/vla-datatypes.c: New file.
* gdb.base/vla-datatypes.exp: New file.
* gdb.mi/mi-vla-c99.exp: New file.
* gdb.mi/vla.c: New file.
Fix c++/16675 -- sizeof reference type should give the size of the referent, not the size of the actual reference variable.
2014-04-11 23:17:17 +02:00
2014-04-11 Keith Seitz <keiths@redhat.com>
PR c++/16675
* gdb.cp/cpsizeof.exp: New file.
* gdb.cp/cpsizeof.cc: New file.
test: add mi vla test testsuite/gdb.mi/ * mi-vla-c99.exp: New file. * vla.c: New file.
2013-11-15 13:48:00 +01:00
2014-04-11 Sanimir Agovic <sanimir.agovic@intel.com>
gdb/testsuite/ChangeLog: Fix path to a few files in previous entries.
2014-04-12 00:28:08 +02:00
* gdb.mi/mi-vla-c99.exp: New file.
* gdb.mi/vla.c: New file.
test: add mi vla test testsuite/gdb.mi/ * mi-vla-c99.exp: New file. * vla.c: New file.
2013-11-15 13:48:00 +01:00
test: basic c99 vla tests for C primitives gdb/testsuite: * gdb.base/vla-datatypes.c: New file. * gdb.base/vla-datatypes.exp: New file.
2013-11-15 13:47:47 +01:00
2014-04-11 Sanimir Agovic <sanimir.agovic@intel.com>
* gdb.base/vla-datatypes.c: New file.
* gdb.base/vla-datatypes.exp: New file.
test: evaluate pointers to C99 vla correctly. gdb/testsuite: * gdb.base/vla-ptr.c: New file. * gdb.base/vla-ptr.exp: New file.
2013-11-15 13:47:44 +01:00
2014-04-11 Sanimir Agovic <sanimir.agovic@intel.com>
* gdb.base/vla-ptr.c: New file.
* gdb.base/vla-ptr.exp: New file.
test: multi-dimensional c99 vla. gdb/testsuite: * gdb.base/vla-multi.c: New file. * gdb.base/vla-multi.exp: New file.
2013-11-15 13:47:32 +01:00
2014-04-11 Sanimir Agovic <sanimir.agovic@intel.com>
* gdb.base/vla-multi.c: New file.
* gdb.base/vla-multi.exp: New file.
test: cover subranges with present DW_AT_count attribute The dwarf attribute DW_AT_count specifies the elements of a subrange. This test covers subranges with present count but absent upper bound attribute, both with static and dynamic attribute values. testsuite: * gdb.dwarf2/count.exp: New file.
2013-11-26 15:47:16 +01:00
2014-04-11 Sanimir Agovic <sanimir.agovic@intel.com>
* gdb.dwarf2/count.exp: New file.
vla: evaluate operand of sizeof if its type is a vla The c99 standard in "6.5.3.4 The sizeof operator" states: If the type of the operand is a variable length array type, the operand is evaluated;[...] This patch mirrors the following c99 semantic in gdb: 1| int vla[n][m]; 2| int i = 1; 3| sizeof(vla[i++][0]); // No sideffect 4| assert (i == 1); 5| sizeof(vla[i++]); // With sideffect 6| assert (i == 2); Note: ptype/whatsis still do not allow any sideeffects. This patch was motivated by: https://sourceware.org/ml/gdb-patches/2014-01/msg00732.html * eval.c (evaluate_subexp_for_sizeof): Add enum noside argument. (evaluate_subexp_standard): Pass noside argument. (evaluate_subexp_for_sizeof) <BINOP_SUBSCRIPT>: Handle subscript case if noside equals EVAL_NORMAL. If the subscript yields a vla type re-evaluate subscript operation with EVAL_NORMAL to enable sideffects. * gdbtypes.c (resolve_dynamic_bounds): Mark bound as evaluated. * gdbtypes.h (enum range_flags): Add RANGE_EVALUATED case. testsuite/gdb.base/ * vla-sideeffect.c: New file. * vla-sideeffect.exp: New file.
2014-02-05 17:22:08 +01:00
2014-04-11 Sanimir Agovic <sanimir.agovic@intel.com>
gdb/testsuite/ChangeLog: Fix path to a few files in previous entries.
2014-04-12 00:28:08 +02:00
* gdb.base/vla-sideeffect.c: New file.
* gdb.base/vla-sideeffect.exp: New file.
vla: evaluate operand of sizeof if its type is a vla The c99 standard in "6.5.3.4 The sizeof operator" states: If the type of the operand is a variable length array type, the operand is evaluated;[...] This patch mirrors the following c99 semantic in gdb: 1| int vla[n][m]; 2| int i = 1; 3| sizeof(vla[i++][0]); // No sideffect 4| assert (i == 1); 5| sizeof(vla[i++]); // With sideffect 6| assert (i == 2); Note: ptype/whatsis still do not allow any sideeffects. This patch was motivated by: https://sourceware.org/ml/gdb-patches/2014-01/msg00732.html * eval.c (evaluate_subexp_for_sizeof): Add enum noside argument. (evaluate_subexp_standard): Pass noside argument. (evaluate_subexp_for_sizeof) <BINOP_SUBSCRIPT>: Handle subscript case if noside equals EVAL_NORMAL. If the subscript yields a vla type re-evaluate subscript operation with EVAL_NORMAL to enable sideffects. * gdbtypes.c (resolve_dynamic_bounds): Mark bound as evaluated. * gdbtypes.h (enum range_flags): Add RANGE_EVALUATED case. testsuite/gdb.base/ * vla-sideeffect.c: New file. * vla-sideeffect.exp: New file.
2014-02-05 17:22:08 +01:00
Check file exists before completion tests Doug told me that there are some regressions in gdb.base/completion.exp. They are caused by my recent change, and can be reproduced via: $ make check-parallel TESTS=gdb.base/completion.exp FAIL: gdb.base/completion.exp: complete target core ./gdb.base/completion FAIL: gdb.base/completion.exp: complete target tfile ./gdb.base/completion FAIL: gdb.base/completion.exp: complete target exec ./gdb.base/completion Current tests assume that gdb.base/completion exists but that is wrong in a parallel run, because binary file and object files are placed in outputs/gdb.base/completion/. This patch is to check file exists on two candidate directories, "gdb.base" and "outputs/gdb.base/completion/", and run tests with files existed in either of them. gdb/testsuite: 2014-04-11 Yao Qi <yao@codesourcery.com> * gdb.base/completion.exp: Check file exists before running tests on file completion.
2014-04-02 06:44:22 +02:00
2014-04-11 Yao Qi <yao@codesourcery.com>
* gdb.base/completion.exp: Check file exists before running tests
on file completion.
Conditional Z1 breakpoint hangs GDBserver. While trying to fix hbreak2.exp against GDBserver I noticed this... (gdb) hbreak main if 1 Sending packet: $m400580,40#2e...Packet received: e8d2ffffff5dc3554889e54883ec10c745fc00000000eb0eb800000000e8c1ffffff8345fc01817dfce70300007ee9b800000000c9c3662e0f1f840000000000 Sending packet: $m40058f,1#31...Packet received: c7 Hardware assisted breakpoint 1 at 0x40058f: file ../../../src/gdb/testsuite/gdb.base/break-idempotent.c, line 46. Sending packet: $Z1,40058f,1;X3,220127#9b... *hangs forever* The issue is that nothing advances the packet pointer if add_breakpoint_condition either fails to parse the agent expression, or fails to find the breakpoint, resulting in an infinite loop in process_point_options. The latter case should really be fixed by GDBserver tracking GDB Z1 breakpoints in its breakpoint structures like Z0 breakpoints are, but the latter case still needs handling. add_breakpoint_commands has the same issue, though at present I don't know any way to trigger it other than sending a manually cooked packet. Unbelievably, it doesn't look like we have any test that tries setting a conditional hardware breakpoint. Looking at cond-eval-mode.exp, it looks like the file was meant to actually test something, but it's mostly empty today. This patch adds tests that tries all sorts of conditional breakpoints and watchpoints. The test hangs/fails without the GDBserver fix. Tested on x86_64 Fedora 17. gdb/gdbserver/ 2014-04-10 Pedro Alves <palves@redhat.com> * mem-break.c (add_breakpoint_condition, add_breakpoint_commands): Check if the condition or command is NULL before checking if the breakpoint is known. On success, return true. * mem-break.h (add_breakpoint_condition): Document return. (add_breakpoint_commands): Add describing comment. * server.c (skip_to_semicolon): New function. (process_point_options): Use it. gdb/testsuite/ 2014-04-10 Pedro Alves <palves@redhat.com> * gdb.base/cond-eval-mode.c: New file. * gdb.base/cond-eval-mode.exp: Use standard_testfile. Adjust prepare_for_testing to build the new file. Check result of runto_main. (test_break, test_watch): New procedures. (top level): Use them.
2014-04-10 20:22:23 +02:00
2014-04-10 Pedro Alves <palves@redhat.com>
* gdb.base/cond-eval-mode.c: New file.
* gdb.base/cond-eval-mode.exp: Use standard_testfile. Adjust
prepare_for_testing to build the new file. Check result of
runto_main.
(test_break, test_watch): New procedures.
(top level): Use them.
[testsuite] Disable Ctrl-V use for mingw hosts. On mingw host, we have seen two fails as below, p int1dim[0]^V@2 Invalid character '^V' in expression. (gdb) FAIL: gdb.base/printcmds.exp: p int1dim[0]@2 p int1dim[0]^V@2^V@3 Invalid character '^V' in expression. (gdb) FAIL: gdb.base/printcmds.exp: p int1dim[0]@2@3 In the test, the comment says "# Send \026@ instead of just @ in case the kill character is @". Historically, kill character was @, and Ctrl-V (\026) is to escape the next character. However, we don't have to do so on mingw. This patch is to disable ctrl-v usage on mingw hots. With this patch applied, it becomes: p int1dim[0]@2 $607 = {0, 1} (gdb) PASS: gdb.base/printcmds.exp: p int1dim[0]@2 p int1dim[0]@2@3 $608 = {{0, 1}, {2, 3}, {4, 5}} Note that this patch is picked from Pierre's submission, [RFC 6/6] Fix remaining failures in gdb.base/printcmds.exp for mingw hosts. https://www.sourceware.org/ml/gdb-patches/2013-09/msg00943.html gdb/testsuite: 2014-04-08 Pierre Muller <muller@sourceware.org> * gdb.base/printcmds.exp (test_artificial_arrays): Disable Ctrl-V use for mingw hosts.
2014-03-25 01:37:36 +01:00
2014-04-08 Pierre Muller <muller@sourceware.org>
* gdb.base/printcmds.exp (test_artificial_arrays): Disable
Ctrl-V use for mingw hosts.
[python] Fix gdb.Value.dynamic_type for reference values. gdb.Value.dynamic_type is supposed to work for reference and pointer values. However, the value object in the function 'valpy_get_dynamic_type' was being dereferenced using 'value_ind' irrespective of the value type being TYPE_CODE_PTR or TYPE_CODE_REF. This patch fixes that to use 'coerce_ref' for TYPE_CODE_REF values. ChangeLog: * python/py-value.c (valpy_get_dynamic_type): Use coerce_ref to dereference TYPE_CODE_REF values. testsuite/ * gdb.python/py-value.c: Improve test case. * gdb.python/py-value.exp: Add new test.
2014-03-21 14:42:50 +01:00
2014-04-07 Siva Chandra Reddy <sivachandra@google.com>
* gdb.python/py-value.c: Improve test case.
* gdb.python/py-value.exp: Add new test.
Add support to recognize clang. * lib/compiler.c: Identify the clang compiler. * lib/compiler.cc: Ditto.
2014-04-07 23:14:03 +02:00
2014-04-07 David Blaikie <dblaikie@gmail.com>
* lib/compiler.c: Identify the clang compiler.
* lib/compiler.cc: Ditto.
Escape backslash in windows path Hi, On windows host, we see the following ERROR, (gdb) PASS: gdb.base/setshow.exp: set history filename ~/foobar.baz ERROR OCCURED: couldn't compile regular expression pattern: invalid escape \ seq uence while executing "expect -nobrace -i exp13 -timeout 10 -re {.*A problem internal to GDB has been detected} { fail "$message (GDB internal error)" gdb_internal..." invoked from within "expect { -i exp13 -timeout 10 -re ".*A problem internal to GDB has been detected" { fail "$message (GDB internal error)" gdb_internal_erro..." ("uplevel" body line 1) invoked from within "uplevel $body" REGEXP REG_EESCAPE {invalid escape \ sequence} couldn't compile regular expression pattern: invalid escape \ sequenceERROR: Process no longer ex ists which leads to UNRESOLVED: gdb.base/setshow.exp: show history filename (~/foobar.baz) and this error is thrown from this test below: gdb_test "show history filename" \ "The filename in which to record the command history is \"$HOME/foobar.baz\"..*" \ "show history filename (~/foobar.baz)" HOME is a windows path, like C:\foo\bar. When it is used in gdb_test to match output, the error is thrown because backslash is a special character in regular expression. This patch is to escape backslash to fix this error by using string_to_regexp. gdb/testsuite: 2014-04-03 Yao Qi <yao@codesourcery.com> * gdb.base/setshow.exp: Invoke string_to_regexp to HOME and PWD.
2014-03-29 02:41:02 +01:00
2014-04-03 Yao Qi <yao@codesourcery.com>
* gdb.base/setshow.exp: Invoke string_to_regexp to HOME and PWD.
gdb.arch/ppc64-atomic-inst.exp: Improve error handling. gdb/testsuite/ 2014-04-01 Anton Blanchard <anton@samba.org> * gdb.arch/ppc64-atomic-inst.exp: Use untested. Make test messages unique.
2014-03-31 04:32:07 +02:00
2014-04-01 Anton Blanchard <anton@samba.org>
* gdb.arch/ppc64-atomic-inst.exp: Use untested. Make test
messages unique.
gdb.arch/ppc64-atomic-inst.exp: Use standard_testfile, prepare_for_testing. gdb/testsuite/ 2014-04-01 Anton Blanchard <anton@samba.org> * gdb.arch/ppc64-atomic-inst.exp: Use standard_testfile, prepare_for_testing.
2014-03-31 03:03:01 +02:00
2014-04-01 Anton Blanchard <anton@samba.org>
* gdb.arch/ppc64-atomic-inst.exp: Use standard_testfile,
prepare_for_testing.
Fix ppc64 single step over atomic sequence testcase. The current ppc64 single step over atomic sequence testcase is written in C and breaks with some versions of gcc. Convert the test to assembly and use stepi to step through it. gdb/testsuite/ 2014-04-01 Anton Blanchard <anton@samba.org> * gdb.arch/ppc64-atomic-inst.c: Remove. * gdb.arch/ppc64-atomic-inst.S: New file. * gdb.arch/ppc64-atomic-inst.exp: Adapt for asm based testcase.
2014-03-28 02:37:37 +01:00
2014-04-01 Anton Blanchard <anton@samba.org>
* gdb.arch/ppc64-atomic-inst.c: Remove.
* gdb.arch/ppc64-atomic-inst.S: New file.
* gdb.arch/ppc64-atomic-inst.exp: Adapt for asm based testcase.
New option "set print symbol-loading". * NEWS: Mention it. * solib.c (solib_read_symbols): Only print symbol loading messages if requested. (solib_add): If symbol loading is in "brief" mode, notify user symbols are being loaded. (reload_shared_libraries_1): Ditto. * symfile.c (print_symbol_loading_off): New static global. (print_symbol_loading_brief): New static global. (print_symbol_loading_full): New static global. (print_symbol_loading_enums): New static global. (print_symbol_loading): New static global. (print_symbol_loading_p): New function. (symbol_file_add_with_addrs): Only print symbol loading messages if requested. (_initialize_symfile): Register "print symbol-loading" set/show command. * symfile.h (print_symbol_loading_p): Declare. doc/ * gdb.texinfo (Symbols): Document set/show print symbol-loading. testsuite/ * gdb.base/print-symbol-loading-lib.c: New file. * gdb.base/print-symbol-loading-main.c: New file. * gdb.base/print-symbol-loading.exp: New file.
2014-03-31 21:07:48 +02:00
2014-03-31 Doug Evans <dje@google.com>
* gdb.base/print-symbol-loading-lib.c: New file.
* gdb.base/print-symbol-loading-main.c: New file.
* gdb.base/print-symbol-loading.exp: New file.
Allow ';' as a directory separator Hi, I find two fails in source-dir.exp on mingw32 host. (gdb) directory /nOtExStInG/a /nOtExStInG/b /nOtExStInG/c^M Warning: /nOtExStInG/a: No such file or directory.^M Warning: /nOtExStInG/b: No such file or directory.^M Warning: /nOtExStInG/c: No such file or directory.^M Source directories searched: /nOtExStInG/a;/nOtExStInG/b;/nOtExStInG/c;$cdir;$cwd^M (gdb) FAIL: gdb.base/source-dir.exp: directory /nOtExStInG/a /nOtExStInG/b /nOtExStInG/c directory /nOtExStInG/b /nOtExStInG/d /nOtExStInG/c^M Warning: /nOtExStInG/b: No such file or directory.^M Warning: /nOtExStInG/d: No such file or directory.^M Warning: /nOtExStInG/c: No such file or directory.^M Source directories searched: /nOtExStInG/b;/nOtExStInG/d;/nOtExStInG/c;/nOtExStInG/a;$cdir;$cwd^M (gdb) FAIL: gdb.base/source-dir.exp: directory /nOtExStInG/b /nOtExStInG/d /nOtExStInG/c The regular expression expects ':' and ';' is path separator on Windows. This patch is to allow ';' as a path separator in regular expression. This patch is similar to Dan's patch to fix a similar problem here Re: directory separators on minGW hosts https://sourceware.org/ml/gdb-patches/2006-02/msg00359.html It is obvious. Pushed it in. gdb/testsuite: 2014-03-31 Yao Qi <yao@codesourcery.com> * gdb.base/source-dir.exp: Allow ';' as a directory separator.
2014-03-31 08:20:05 +02:00
2014-03-31 Yao Qi <yao@codesourcery.com>
* gdb.base/source-dir.exp: Allow ';' as a directory separator.
[varobj] false type-changed status for reference to Ada array Given the following variable... BT : Bounded := New_Bounded (Low => 1, High => 3); ... where type Bounded is defined as a simple unconstrained array: type Bounded is array (Integer range <>) of Integer; Creating a varobj for that variable, and immediately asking for varobj updates, GDB says that our varobj changed types! (gdb) -var-create bt * bt ^done,name="bt",numchild="3",value="[3]",type="<ref> array (1 .. 3) of integer",has_more="0" (gdb) -var-update 1 * ^done,changelist=[{name="bt",value="[3]",in_scope="true",type_changed="true",new_type="<ref> array (1 .. 3) of integer",new_num_children="3",has_more="0"}] The expected output for the -var-update command is, in this case: (gdb) -var-update 1 * ^done,changelist=[] The problem occurs because the ada-varobj module does not handle references, and while the references gets stripped when the varobj gets created, it doesn't when computing varobj updates. More specifically, when creating the varobj, varobj_create creates a new value which is a reference to a TYPE_CODE_ARRAY. It then calls install_new_value which calls coerce_ref with the following comment: /* We are not interested in the address of references, and given that in C++ a reference is not rebindable, it cannot meaningfully change. So, get hold of the real value. */ if (value) value = coerce_ref (value); This leaves the varobj's type component still a ref, while the varobj's value is now our array, without the ref. This explains why the "value" field in the varobj indicates an array with 3 elements "[3]" while the "type" field shows a ref to an array. Generally speaking, most users have said that showing the ref was a useful piece of information, so this patch is not touching this part. Next, when the user issues the -var-update request, varobj_update calls value_of_root to compute the varobj's new value as well as determine whether the value's type has changed or not. What happens in a nutshell is that it calls value_of_root_1 (which re-evaluates the expression and returns the corresponding new value), finds that the new value is not NULL, and thus asks whether it has mutated: else if (varobj_value_has_mutated (var, value, value_type (value))) This then indirectly delegates the determination to the language-specific callback, which fails, because it does not handle references. This patch fixes the issue by adjusting varobj_value_has_mutated to expect references, and strip them when seen. This allows the various language-specific implementations to remain unaware of references. gdb/ChangeLog: * varobj.c (varobj_value_has_mutated): If NEW_VALUE is a reference, strip the reference layer before calling the lang_ops value_has_mutated callback. gdb/testsuite/ChangeLog: * gdb.ada/mi_dyn_arr: New testcase.
2014-03-20 15:43:08 +01:00
2014-03-28 Joel Brobecker <brobecker@adacore.com>
* gdb.ada/mi_dyn_arr: New testcase.
* gdb.dwarf2/dw2-abs-hi-pc.exp: Build tests with "nodebug".
2014-03-27 19:38:30 +01:00
2014-03-27 Doug Evans <dje@google.com>
* gdb.dwarf2/dw2-abs-hi-pc.exp: Build tests with "nodebug".
Return zero in can_single_step_to_signal_handler for nios2-*-* target nios2 uses software single step, so GDB is unable to single step to the signal handler. In order to reflect this, teach can_single_step_to_signal_handler to return zero for nios2 target. gdb/testsuite: 2014-03-27 Yao Qi <yao@codesourcery.com> * lib/gdb.exp (can_single_step_to_signal_handler): Return zero if target is nios2-*-*.
2014-03-26 10:44:14 +01:00
2014-03-27 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (can_single_step_to_signal_handler): Return zero
if target is nios2-*-*.
Skip tests on completion and readline when readline lib isn't used The completion feature and other features on readline depend on the readline library. However, readline library is not always used, for example, running testsuite like make check RUNTESTFLAGS="--host_board=local-remote-host" the input stream is not a tty, and GDB doesn't use readline library as a result. This patch is to skip tests on completion and readline if 'show editing' is off, which means readline isn't used. Note that some tests in gdb.base/completion.exp test command complete, which isn't related to readline, so these tests aren't affected by readline library. This patch also moves these tests up, run them unconditionally, and run the rest if readline library is used. gdb/testsuite: 2014-03-26 Yao Qi <yao@codesourcery.com> * lib/gdb.exp (readline_is_used): New proc. * gdb.base/completion.exp: Move tests on command complete up. Skip the rest of tests if readline is not used. * gdb.ada/complete.exp: Skp the test if readline is not used. * gdb.base/filesym.exp: Likewise. * gdb.base/macscp.exp: Likewise. * gdb.base/readline-ask.exp: Likewise. * gdb.base/readline.exp: Likewise. * gdb.python/py-cmd.exp: Likewise. * gdb.trace/tfile.exp: Likewise.
2014-03-19 03:16:35 +01:00
2014-03-26 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (readline_is_used): New proc.
* gdb.base/completion.exp: Move tests on command complete up.
Skip the rest of tests if readline is not used.
* gdb.ada/complete.exp: Skp the test if readline is not
used.
* gdb.base/filesym.exp: Likewise.
* gdb.base/macscp.exp: Likewise.
* gdb.base/readline-ask.exp: Likewise.
* gdb.base/readline.exp: Likewise.
* gdb.python/py-cmd.exp: Likewise.
* gdb.trace/tfile.exp: Likewise.
Fix code format issues gdb.base/macscp.exp When I do something else, I find code format in gdb.base/macscp.exp is messy. This patch is to fix various code format issues in it. Pushed as it is obvious. gdb/testsuite: 2014-03-26 Yao Qi <yao@codesourcery.com> * gdb.base/macscp.exp: Fix code format issues.
2014-03-18 13:26:58 +01:00
2014-03-26 Yao Qi <yao@codesourcery.com>
* gdb.base/macscp.exp: Fix code format issues.
Support gdb.asm/asm-source.exp on powerpc64le Add new powerpc64le.inc file appropriate for the ELFv2 ABI and use it to support the asm-source.exp test case on powerpc64le. gdb/testsuite/ 2014-03-25 Ulrich Weigand <uweigand@de.ibm.com> * gdb.asm/asm-source.exp: Handle powerpc64le-* targets. * gdb.asm/powerpc64le.inc: New file.
2014-03-25 15:39:32 +01:00
2014-03-25 Ulrich Weigand <uweigand@de.ibm.com>
* gdb.asm/asm-source.exp: Handle powerpc64le-* targets.
* gdb.asm/powerpc64le.inc: New file.
"source", foreground execution commands, and target-async Sourcing a GDB script that runs foreground execution commands in succession fails if the target can async: Breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.base/source-execution.c:36 36 func1 (); (gdb) source ../../../src/gdb/testsuite/gdb.base/source-execution.gdb ../../../src/gdb/testsuite/gdb.base/source-execution.gdb:21: Error in sourced command file: Cannot execute this command while the selected thread is running. (gdb) FAIL: gdb.base/source-execution.exp: source source-execution.gdb That is, after a foreground execution command, GDB moves on to the following command immediately before waiting for the previous command to complete. https://sourceware.org/ml/gdb-patches/2011-09/msg00037.html (b4a14fd0) addressed this for command lists, Python's gdb.execute, etc., but missed "source". Fixed now in the same way. gdb/ 2014-03-25 Pedro Alves <palves@redhat.com> * cli/cli-script.c (script_from_file): Force the interpreter to sync mode. gdb/testsuite/ 2014-03-25 Pedro Alves <palves@redhat.com> Doug Evans <dje@google.com> * gdb.base/source-execution.c: New file. * gdb.base/source-execution.exp: New file. * gdb.base/source-execution.gdb: New file.
2014-03-25 12:45:53 +01:00
2014-03-25 Pedro Alves <palves@redhat.com>
Doug Evans <dje@google.com>
* gdb.base/source-execution.c: New file.
* gdb.base/source-execution.exp: New file.
* gdb.base/source-execution.gdb: New file.
gdb.linespec/macro-relative.exp: Mark the test as unsupported if using fission.
2014-03-25 00:03:20 +01:00
2014-03-24 Doug Evans <dje@google.com>
* gdb.linespec/macro-relative.exp: Mark the test as unsupported if
using fission.
Fix PR breakpoints/16101: gdb.base/dprintf.exp agent-printf failures with non-Z0-supporting gdbservers After a previous patch that was committed by Pedro (0000e5cc), trying to set a dprintf with with a GDBserver that doesn't support agent commands at all now throws an error. But the dprintf tests still fail with some GDBserver targets because they doesn't try to handle the case of the server reporting support for breakpoint commands, but not be able to use those in combination with Z0 (because Z0 isn't actually supported, for example): FAIL: gdb.base/dprintf.exp: 1st dprintf, agent FAIL: gdb.base/dprintf.exp: 2nd dprintf, agent FAIL: gdb.base/dprintf.exp: dprintf info 2 (pattern 4) Similarly for the MI test. This patch makes the tests handle this scenario. Tested with native, and native gdbserver on x86_64 Fedora 17. Also tested with the native-gdbserver.exp board hacked with: set GDBFLAGS "${GDBFLAGS} -ex \"set remote breakpoint-commands off\"" (actually, "set remote breakpoint-commands off" is presently broken, so this was on top of a fix for that command.) which results in: (gdb) PASS: gdb.base/dprintf.exp: 2nd dprintf, gdb set dprintf-style agent warning: Target cannot run dprintf commands, falling back to GDB printf warning: Target cannot run dprintf commands, falling back to GDB printf (gdb) UNSUPPORTED: gdb.base/dprintf.exp: set dprintf style to agent gdb.sum: Running target native-gdbserver Running ../../../src/gdb/testsuite/gdb.base/dprintf.exp ... PASS: gdb.base/dprintf.exp: dprintf PASS: gdb.base/dprintf.exp: dprintf foo PASS: gdb.base/dprintf.exp: dprintf 29 PASS: gdb.base/dprintf.exp: dprintf foo,"At foo entry\n" PASS: gdb.base/dprintf.exp: ignore $bpnum 1 PASS: gdb.base/dprintf.exp: dprintf 26,"arg=%d, g=%d\n", arg, g PASS: gdb.base/dprintf.exp: dprintf info 1 PASS: gdb.base/dprintf.exp: break 27 PASS: gdb.base/dprintf.exp: 1st dprintf, gdb PASS: gdb.base/dprintf.exp: 2nd dprintf, gdb UNSUPPORTED: gdb.base/dprintf.exp: set dprintf style to agent PASS: gdb.base/dprintf.exp: Set dprintf style to an unrecognized type And also with the native-gdbserver.exp board hacked with: set GDBFLAGS "${GDBFLAGS} -ex \"set remote Z-packet off\"" which results in: (gdb) continue Continuing. Warning: Cannot insert breakpoint 3: Target doesn't support breakpoints that have target side commands. Cannot insert breakpoint 4: Target doesn't support breakpoints that have target side commands. (gdb) UNSUPPORTED: gdb.base/dprintf.exp: 1st dprintf, agent gdb.sum: Running target native-gdbserver Running ../../../src/gdb/testsuite/gdb.base/dprintf.exp ... PASS: gdb.base/dprintf.exp: dprintf PASS: gdb.base/dprintf.exp: dprintf foo PASS: gdb.base/dprintf.exp: dprintf 29 PASS: gdb.base/dprintf.exp: dprintf foo,"At foo entry\n" PASS: gdb.base/dprintf.exp: ignore $bpnum 1 PASS: gdb.base/dprintf.exp: dprintf 26,"arg=%d, g=%d\n", arg, g PASS: gdb.base/dprintf.exp: dprintf info 1 PASS: gdb.base/dprintf.exp: break 27 PASS: gdb.base/dprintf.exp: 1st dprintf, gdb PASS: gdb.base/dprintf.exp: 2nd dprintf, gdb PASS: gdb.base/dprintf.exp: set dprintf style to agent UNSUPPORTED: gdb.base/dprintf.exp: 1st dprintf, agent PASS: gdb.base/dprintf.exp: Set dprintf style to an unrecognized type (One of the new comments mentions breakpoint always-inserted mode. Actually testing with breakpoint always-inserted mode fails these dprintf tests, due to the way they are written. But that'll take a more substancial rewrite of the tests, so I'm leaving that for another day.) gdb/testsuite/ 2014-03-24 Hui Zhu <hui@codesourcery.com> Pedro Alves <palves@redhat.com> PR breakpoints/16101 * gdb.base/dprintf.exp: Use unsupported rather than changing the test pass/fail messages. Detect missing support for dprintf when breakpoints are actually inserted. * gdb.base/mi-dprintf.exp: Detect missing support for dprintf when breakpoints are actually inserted. * lib/mi-support.exp (mi_run_cmd_full): Return -1 if continue fails.
2014-03-24 20:30:50 +01:00
2014-03-24 Hui Zhu <hui@codesourcery.com>
Pedro Alves <palves@redhat.com>
PR breakpoints/16101
* gdb.base/dprintf.exp: Use unsupported rather than changing the
test pass/fail messages. Detect missing support for dprintf when
breakpoints are actually inserted.
* gdb.base/mi-dprintf.exp: Detect missing support for dprintf when
breakpoints are actually inserted.
* lib/mi-support.exp (mi_run_cmd_full): Return -1 if continue
fails.
testsuite: Remove needless linux-nat requirement in gdb-sigterm.exp. That "set debug lin-lwp 1" command even is not needed for the functionality of this testcase. This patch does fix a testcase error on aarch64-none-elf. gdb/testsuite/ 2014-03-24 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.base/gdb-sigterm.exp (do_test): Remove "set debug lin-lwp 1". Message-ID: <20140323165745.GA23830@host2.jankratochvil.net>
2014-03-24 17:37:32 +01:00
2014-03-24 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/gdb-sigterm.exp (do_test): Remove "set debug lin-lwp 1".
* extension.c (eval_ext_lang_from_control_command): Avoid dereferencing NULL pointer. testsuite/ * gdb.python/python.exp (python not supported): Verify multi-line python command issues an error.
2014-03-22 07:44:39 +01:00
2014-03-22 Doug Evans <xdje42@gmail.com>
* gdb.python/python.exp (python not supported): Verify multi-line
python command issues an error.
Fix typo in previous entry.
2014-03-22 07:59:04 +01:00
* gdb.guile/guile.exp (guile not supported): Verify multi-line
* gdb.guile/guile.exp (guile not supported): Verify multi-line guile command issues an error.
2014-03-22 07:57:08 +01:00
guile command issues an error.
* extension.c (eval_ext_lang_from_control_command): Avoid dereferencing NULL pointer. testsuite/ * gdb.python/python.exp (python not supported): Verify multi-line python command issues an error.
2014-03-22 07:44:39 +01:00
gdb.threads/thread-specific.exp: Fix uninitialized variable references This fixes: FAIL: gdb.threads/thread-specific.exp: continue to thread-specific breakpoint (timeout) ERROR: tcl error sourcing .../gdb/testsuite/gdb.threads/thread-specific.exp. ERROR: can't read "this_breakpoint": no such variable while executing "gdb_test_multiple "info breakpoint $this_breakpoint" "info on bp" { -re ".*stop only in thread (\[0-9\]*).*$gdb_prompt $" { set this_thread $expe..." (file ".../gdb/testsuite/gdb.threads/thread-specific.exp" line 108) invoked from within "source .../gdb/testsuite/gdb.threads/thread-specific.exp" ("uplevel" body line 1) invoked from within "uplevel #0 source .../gdb/testsuite/gdb.threads/thread-specific.exp" invoked from within "catch "uplevel #0 source $test_file_name"" and then: FAIL: gdb.threads/thread-specific.exp: continue to thread-specific breakpoint (timeout) UNTESTED: gdb.threads/thread-specific.exp: info on bp ERROR: tcl error sourcing .../gdb/testsuite/gdb.threads/thread-specific.exp. ERROR: can't read "this_thread": no such variable while executing "gdb_test {print $_thread} ".* = $this_thread" "thread var at break"" (file ".../gdb/testsuite/gdb.threads/thread-specific.exp" line 119) invoked from within "source .../gdb/testsuite/gdb.threads/thread-specific.exp" ("uplevel" body line 1) invoked from within "uplevel #0 source .../gdb/testsuite/gdb.threads/thread-specific.exp" invoked from within "catch "uplevel #0 source $test_file_name"" Final results: FAIL: gdb.threads/thread-specific.exp: continue to thread-specific breakpoint (timeout) UNTESTED: gdb.threads/thread-specific.exp: info on bp UNTESTED: gdb.threads/thread-specific.exp: thread var at break Of course the first failure best wasn't there, but failing that the script shouldn't crash. * gdb.threads/thread-specific.exp: Handle the lack of usable $this_breakpoint and $this_thread.
2014-03-22 00:51:16 +01:00
2014-03-21 Maciej W. Rozycki <macro@codesourcery.com>
* gdb.threads/thread-specific.exp: Handle the lack of usable
$this_breakpoint and $this_thread.
Fix internal warning when "gdb -p xxx" The issue that was fixed by b4ab256ded5020a82ff7ce8dc485e7882fc5b6a7 can not be found in regression test. Update attach.exp to test it. https://sourceware.org/ml/gdb-patches/2014-03/msg00438.html 2014-03-21 Hui Zhu <hui@codesourcery.com> * gdb.base/attach.exp (do_command_attach_tests): New.
2014-03-21 04:11:51 +01:00
2014-03-21 Hui Zhu <hui@codesourcery.com>
* gdb.base/attach.exp (do_command_attach_tests): New.
make dprintf.exp pass in target async mode When target-async is enabled, dprintf.exp fails: Running ../../../src/gdb/testsuite/gdb.base/dprintf.exp ... FAIL: gdb.base/dprintf.exp: 1st dprintf, call FAIL: gdb.base/dprintf.exp: 2nd dprintf, call FAIL: gdb.base/dprintf.exp: Set dprintf function FAIL: gdb.base/dprintf.exp: 1st dprintf, fprintf FAIL: gdb.base/dprintf.exp: 2nd dprintf, fprintf Breakpoint 2, main (argc=1, argv=0x7fffffffd3f8) at ../../../src/gdb/testsuite/gdb.base/dprintf.c:33 33 int loc = 1234; (gdb) continue Continuing. kickoff 1234 also to stderr 1234 At foo entry (gdb) FAIL: gdb.base/dprintf.exp: 1st dprintf, call The problem is that GDB gave the prompt back to the user too early. This happens when calling functions while handling an event that doesn't cause a user visible stop. dprintf with "set dprintf-style gdb" is one such case. This patch adds a test case that has a breakpoint with a condition that calls a function that returns false, so that regression testing isn't dependent on the implementation of dprintf. The problem happens because run_inferior_call causes GDB to forget that it is running in sync_execution mode, so any event that runs an inferior call causes fetch_inferior_event to display the prompt, even if the event should not result in a user visible stop (that is, gdb resumes the inferior and waits for the next event). This patch fixes the issue by noticing when GDB was in sync_execution mode in run_inferior_call, and taking care to restore this state afterward. gdb/ 2014-03-20 Tom Tromey <tromey@redhat.com> PR cli/15718 * infcall.c: Include event-top.h. (run_inferior_call): Call async_disable_stdin if needed. gdb/testsuite/ 2014-03-20 Tom Tromey <tromey@redhat.com> Pedro Alves <palves@redhat.com> PR cli/15718 * gdb.base/condbreak-call-false.c: New file. * gdb.base/condbreak-call-false.exp: New file.
2014-03-20 18:03:43 +01:00
2014-03-20 Tom Tromey <tromey@redhat.com>
Pedro Alves <palves@redhat.com>
PR cli/15718
* gdb.base/condbreak-call-false.c: New file.
* gdb.base/condbreak-call-false.exp: New file.
Further cleanup of signal-while-stepping-over-bp-other-thread.c. This test now uses pthread_kill instead of the host's kill command, so no longer need to block signals, or store the the inferior's PID. gdb/testsuite/ 2014-03-20 Pedro Alves <palves@redhat.com> * gdb.threads/signal-while-stepping-over-bp-other-thread.c (pid): Delete. (block_signals, unblock_signals): Delete. (child_function_2, main): Remove references to deleted variable and functions.
2014-03-20 15:09:53 +01:00
2014-03-20 Pedro Alves <palves@redhat.com>
* gdb.threads/signal-while-stepping-over-bp-other-thread.c (pid):
Delete.
(block_signals, unblock_signals): Delete.
(child_function_2, main): Remove references to deleted variable
and functions.
Make signal-while-stepping-over-bp-other-thread.exp run against remote targets too. Use pthread_kill instead of the host's "kill". The reason the test wasn't written that way to begin with, is that done this way, before the previous fixes to make GDB step-over all other threads before the stepping thread, the test would fail... Tested on x86_64 Fedora 17, native and gdbserver. gdb/testsuite/ 2014-03-20 Pedro Alves <palves@redhat.com> * gdb.threads/signal-while-stepping-over-bp-other-thread.c (main): Use pthread_kill to signal thread 2. * gdb.threads/signal-while-stepping-over-bp-other-thread.exp: Adjust to make the test send itself a signal rather than using the host's "kill" command.
2014-03-20 14:26:33 +01:00
2014-03-20 Pedro Alves <palves@redhat.com>
* gdb.threads/signal-while-stepping-over-bp-other-thread.c (main):
Use pthread_kill to signal thread 2.
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp:
Adjust to make the test send itself a signal rather than using the
host's "kill" command.
Handle multiple step-overs. This test fails with current mainline. If the program stopped for a breakpoint in thread 1, and then the user switches to thread 2, and resumes the program, GDB first switches back to thread 1 to step it over the breakpoint, in order to make progress. However, that logic only considers the last reported event, assuming only one thread needs that stepping over dance. That's actually not true when we play with scheduler-locking. The patch adds an example to the testsuite of multiple threads needing a step-over before the stepping thread can be resumed. With current mainline, the program re-traps the same breakpoint it had already trapped before. E.g.: Breakpoint 2, main () at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:99 99 wait_threads (); /* set wait-threads breakpoint here */ (gdb) PASS: gdb.threads/multiple-step-overs.exp: step: continue to breakpoint: run to breakpoint info threads Id Target Id Frame 3 Thread 0x7ffff77c9700 (LWP 4310) "multiple-step-o" 0x00000000004007ca in child_function_3 (arg=0x1) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:43 2 Thread 0x7ffff7fca700 (LWP 4309) "multiple-step-o" 0x0000000000400827 in child_function_2 (arg=0x0) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:60 * 1 Thread 0x7ffff7fcb740 (LWP 4305) "multiple-step-o" main () at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:99 (gdb) PASS: gdb.threads/multiple-step-overs.exp: step: info threads shows all threads set scheduler-locking on (gdb) PASS: gdb.threads/multiple-step-overs.exp: step: set scheduler-locking on break 44 Breakpoint 3 at 0x4007d3: file ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c, line 44. (gdb) break 61 Breakpoint 4 at 0x40082d: file ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c, line 61. (gdb) thread 3 [Switching to thread 3 (Thread 0x7ffff77c9700 (LWP 4310))] #0 0x00000000004007ca in child_function_3 (arg=0x1) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:43 43 (*myp) ++; (gdb) PASS: gdb.threads/multiple-step-overs.exp: step: thread 3 continue Continuing. Breakpoint 3, child_function_3 (arg=0x1) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:44 44 callme (); /* set breakpoint thread 3 here */ (gdb) PASS: gdb.threads/multiple-step-overs.exp: step: continue to breakpoint: run to breakpoint in thread 3 p *myp = 0 $1 = 0 (gdb) PASS: gdb.threads/multiple-step-overs.exp: step: unbreak loop in thread 3 thread 2 [Switching to thread 2 (Thread 0x7ffff7fca700 (LWP 4309))] #0 0x0000000000400827 in child_function_2 (arg=0x0) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:60 60 (*myp) ++; (gdb) PASS: gdb.threads/multiple-step-overs.exp: step: thread 2 continue Continuing. Breakpoint 4, child_function_2 (arg=0x0) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:61 61 callme (); /* set breakpoint thread 2 here */ (gdb) PASS: gdb.threads/multiple-step-overs.exp: step: continue to breakpoint: run to breakpoint in thread 2 p *myp = 0 $2 = 0 (gdb) PASS: gdb.threads/multiple-step-overs.exp: step: unbreak loop in thread 2 thread 1 [Switching to thread 1 (Thread 0x7ffff7fcb740 (LWP 4305))] #0 main () at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:99 99 wait_threads (); /* set wait-threads breakpoint here */ (gdb) PASS: gdb.threads/multiple-step-overs.exp: step: thread 1 set scheduler-locking off (gdb) PASS: gdb.threads/multiple-step-overs.exp: step: set scheduler-locking off At this point all thread are stopped for a breakpoint that needs stepping over. (gdb) step Breakpoint 2, main () at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:99 99 wait_threads (); /* set wait-threads breakpoint here */ (gdb) FAIL: gdb.threads/multiple-step-overs.exp: step But that "step" retriggers the same breakpoint instead of making progress. The patch teaches GDB to step over all breakpoints of all threads before resuming the stepping thread. Tested on x86_64 Fedora 17, against pristine mainline, and also my branch that implements software single-stepping on x86. gdb/ 2014-03-20 Pedro Alves <palves@redhat.com> * infrun.c (prepare_to_proceed): Delete. (thread_still_needs_step_over): New function. (find_thread_needs_step_over): New function. (proceed): If the current thread needs a step-over, set its steping_over_breakpoint flag. Adjust to use find_thread_needs_step_over instead of prepare_to_proceed. (process_event_stop_test): For BPSTAT_WHAT_STOP_NOISY and BPSTAT_WHAT_STOP_SILENT, assume the thread stopped for a breakpoint. (switch_back_to_stepped_thread): Step over breakpoints of all threads not the stepping thread, before switching back to the stepping thread. gdb/testsuite/ 2014-03-20 Pedro Alves <palves@redhat.com> * gdb.threads/multiple-step-overs.c: New file. * gdb.threads/multiple-step-overs.exp: New file. * gdb.threads/signal-while-stepping-over-bp-other-thread.exp: Adjust expected infrun debug output.
2014-03-20 14:26:32 +01:00
2014-03-20 Pedro Alves <palves@redhat.com>
* gdb.threads/multiple-step-overs.c: New file.
* gdb.threads/multiple-step-overs.exp: New file.
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp:
Adjust expected infrun debug output.
Fix for even more missed events; eliminate thread-hop code. Even with deferred_step_ptid out of the way, GDB can still lose watchpoints. If a watchpoint triggers and the PC points to an address where a thread-specific breakpoint for another thread is set, the thread-hop code triggers, and we lose the watchpoint: if (ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_TRAP) { int thread_hop_needed = 0; struct address_space *aspace = get_regcache_aspace (get_thread_regcache (ecs->ptid)); /* Check if a regular breakpoint has been hit before checking for a potential single step breakpoint. Otherwise, GDB will not see this breakpoint hit when stepping onto breakpoints. */ if (regular_breakpoint_inserted_here_p (aspace, stop_pc)) { if (!breakpoint_thread_match (aspace, stop_pc, ecs->ptid)) thread_hop_needed = 1; ^^^^^^^^^^^^^^^^^^^^^ } And on software single-step targets, even without a thread-specific breakpoint in the way, here in the thread-hop code: else if (singlestep_breakpoints_inserted_p) { ... if (!ptid_equal (singlestep_ptid, ecs->ptid) && in_thread_list (singlestep_ptid)) { /* If the PC of the thread we were trying to single-step has changed, discard this event (which we were going to ignore anyway), and pretend we saw that thread trap. This prevents us continuously moving the single-step breakpoint forward, one instruction at a time. If the PC has changed, then the thread we were trying to single-step has trapped or been signalled, but the event has not been reported to GDB yet. There might be some cases where this loses signal information, if a signal has arrived at exactly the same time that the PC changed, but this is the best we can do with the information available. Perhaps we should arrange to report all events for all threads when they stop, or to re-poll the remote looking for this particular thread (i.e. temporarily enable schedlock). */ CORE_ADDR new_singlestep_pc = regcache_read_pc (get_thread_regcache (singlestep_ptid)); if (new_singlestep_pc != singlestep_pc) { enum gdb_signal stop_signal; if (debug_infrun) fprintf_unfiltered (gdb_stdlog, "infrun: unexpected thread," " but expected thread advanced also\n"); /* The current context still belongs to singlestep_ptid. Don't swap here, since that's the context we want to use. Just fudge our state and continue. */ stop_signal = ecs->event_thread->suspend.stop_signal; ecs->event_thread->suspend.stop_signal = GDB_SIGNAL_0; ecs->ptid = singlestep_ptid; ecs->event_thread = find_thread_ptid (ecs->ptid); ecs->event_thread->suspend.stop_signal = stop_signal; stop_pc = new_singlestep_pc; } else { if (debug_infrun) fprintf_unfiltered (gdb_stdlog, "infrun: unexpected thread\n"); thread_hop_needed = 1; stepping_past_singlestep_breakpoint = 1; saved_singlestep_ptid = singlestep_ptid; } } } we either end up with thread_hop_needed, ignoring the watchpoint SIGTRAP, or switch to the stepping thread, again ignoring that the SIGTRAP could be for some other event. The new test added by this patch exercises both paths. So the fix is similar to the deferred_step_ptid fix -- defer the thread hop to _after_ the SIGTRAP had a change of passing through the regular bpstat handling. If the wrong thread hits a breakpoint, we'll just end up with BPSTAT_WHAT_SINGLE, and if nothing causes a stop, keep_going starts a step-over. Most of the stepping_past_singlestep_breakpoint mechanism is really not necessary -- setting the thread to step over a breakpoint with thread->trap_expected is sufficient to keep all other threads locked. It's best to still keep the flag in some form though, because when we get to keep_going, the software single-step breakpoint we need to step over is already gone -- an optimization done by a follow up patch will check whether a step-over is still be necessary by looking to see whether the breakpoint is still there, and would find the thread no longer needs a step-over, while we still want it. Special care is still needed to handle the case of PC of the thread we were trying to single-step having changed, like in the old code. We can't just keep_going and re-step it, as in that case we can over-step the thread (if it was already done with the step, but hasn't reported it yet, we'd ask it to step even further). That's now handled in switch_back_to_stepped_thread. As bonus, we're now using a technique that doesn't lose signals, unlike the old code -- we now insert a breakpoint at PC, and resume, which either reports the breakpoint immediately, or any pending signal. Tested on x86_64 Fedora 17, against pristine mainline, and against a branch that implements software single-step on x86. gdb/ 2014-03-20 Pedro Alves <palves@redhat.com> * breakpoint.c (single_step_breakpoint_inserted_here_p): Make extern. * breakpoint.h (single_step_breakpoint_inserted_here_p): Declare. * infrun.c (saved_singlestep_ptid) (stepping_past_singlestep_breakpoint): Delete. (resume): Remove stepping_past_singlestep_breakpoint handling. (proceed): Store the prev_pc of the stepping thread too. (init_wait_for_inferior): Adjust. Clear singlestep_ptid and singlestep_pc. (enum infwait_states): Delete infwait_thread_hop_state. (struct execution_control_state) <hit_singlestep_breakpoint>: New field. (handle_inferior_event): Adjust. (handle_signal_stop): Delete stepping_past_singlestep_breakpoint handling and the thread-hop code. Before removing single-step breakpoints, check whether the thread hit a single-step breakpoint of another thread. If it did, the trap is not a random signal. (switch_back_to_stepped_thread): If the event thread hit a single-step breakpoint, unblock it before switching to the stepping thread. Handle the case of the stepped thread having advanced already. (keep_going): Handle the case of the current thread moving past a single-step breakpoint. gdb/testsuite/ 2014-03-20 Pedro Alves <palves@redhat.com> * gdb.threads/step-over-trips-on-watchpoint.c: New file. * gdb.threads/step-over-trips-on-watchpoint.exp: New file.
2014-03-20 14:26:32 +01:00
2014-03-20 Pedro Alves <palves@redhat.com>
* gdb.threads/step-over-trips-on-watchpoint.c: New file.
* gdb.threads/step-over-trips-on-watchpoint.exp: New file.
PR breakpoints/7143 - Watchpoint does not trigger when first set Say the program is stopped at a breakpoint, and the user sets a watchpoint. When the program is next resumed, GDB will first step over the breakpoint, as explained in the manual: @value {GDBN} normally ignores breakpoints when it resumes execution, until at least one instruction has been executed. If it it did not do this, you would be unable to proceed past a breakpoint without first disabling the breakpoint. This rule applies whether or not the breakpoint already existed when your program stopped. However, GDB currently also removes watchpoints, catchpoints, etc., and that means that the first instruction off the breakpoint does not trigger the watchpoint, catchpoint, etc. testsuite/gdb.base/watchpoint.exp has a kfail for this. The PR proposes installing watchpoints only when stepping over a breakpoint, but that misses catchpoints, etc. A better fix would instead work from the opposite direction -- remove only real breakpoints, leaving all other kinds of breakpoints inserted. But, going further, it's really a waste to constantly remove/insert all breakpoints when stepping over a single breakpoint (generating a pair of RSP z/Z packets for each breakpoint), so the fix goes a step further and makes GDB remove _only_ the breakpoint being stepped over, leaving all others installed. This then has the added benefit of reducing breakpoint-related RSP traffic substancialy when there are many breakpoints set. gdb/ 2014-03-20 Pedro Alves <palves@redhat.com> PR breakpoints/7143 * breakpoint.c (should_be_inserted): Don't insert breakpoints that are being stepped over. (breakpoint_address_match): Make extern. * breakpoint.h (breakpoint_address_match): New declaration. * inferior.h (stepping_past_instruction_at): New declaration. * infrun.c (struct step_over_info): New type. (step_over_info): New global. (set_step_over_info, clear_step_over_info) (stepping_past_instruction_at): New functions. (handle_inferior_event): Clear the step-over info when trap_expected is cleared. (resume): Remove now stale comment. (clear_proceed_status): Clear step-over info. (proceed): Adjust step-over handling to set or clear the step-over info instead of removing all breakpoints. (handle_signal_stop): When setting up a thread-hop, don't remove breakpoints here. (stop_stepping): Clear step-over info. (keep_going): Adjust step-over handling to set or clear step-over info and then always inserting breakpoints, instead of removing all breakpoints when stepping over one. gdb/testsuite/ 2014-03-20 Pedro Alves <palves@redhat.com> PR breakpoints/7143 * gdb.base/watchpoint.exp: Mention bugzilla bug number instead of old gnats gdb/38. Remove kfail. Adjust to use gdb_test instead of gdb_test_multiple. * gdb.cp/annota2.exp: Remove kfail for gdb/38. * gdb.cp/annota3.exp: Remove kfail for gdb/38.
2014-03-20 14:26:32 +01:00
2014-03-20 Pedro Alves <palves@redhat.com>
PR breakpoints/7143
* gdb.base/watchpoint.exp: Mention bugzilla bug number instead of
old gnats gdb/38. Remove kfail. Adjust to use gdb_test instead
of gdb_test_multiple.
* gdb.cp/annota2.exp: Remove kfail for gdb/38.
* gdb.cp/annota3.exp: Remove kfail for gdb/38.
Fix missing breakpoint/watchpoint hits, eliminate deferred_step_ptid. Consider the case of the user doing "step" in thread 2, while thread 1 had previously stopped for a breakpoint. In order to make progress, GDB makes thread 1 step over its breakpoint first (with all other threads stopped), and once that is over, thread 2 then starts stepping (with thread 1 and all others running free, by default). If GDB didn't do that, thread 1 would just trip on the same breakpoint immediately again. This is what the prepare_to_proceed / deferred_step_ptid code is all about. However, deferred_step_ptid code resumes the target with: resume (1, GDB_SIGNAL_0); prepare_to_wait (ecs); return; Recall we were just stepping over a breakpoint when we get here. That means that _nothing_ had installed breakpoints yet! If there's another breakpoint just after the breakpoint that was just stepped, we'll miss it. The fix for that would be to use keep_going instead. However, there are more problems. What if the instruction that was just single-stepped triggers a watchpoint? Currently, GDB just happily resumes the thread, losing that too... Missed watchpoints will need yet further fixes, but we should keep those in mind. So the fix must be to let the trap fall through the regular bpstat handling, and only if no breakpoint, watchpoint, etc. claims the trap, shall we switch back to the stepped thread. Now, nowadays, we have code at the tail end of trap handling that does exactly that -- switch back to the stepped thread (switch_back_to_the_stepped_thread). So the deferred_step_ptid code is just standing in the way, and can simply be eliminated, fixing bugs in the process. Sweet. The comment about spurious "Switching to ..." made me pause, but is actually stale nowadays. That isn't needed anymore. previous_inferior_ptid used to be re-set at each (internal) event, but now it's only touched in proceed and normal stop. The two tests added by this patch fail without the fix. Tested on x86_64 Fedora 17 (also against my software single-stepping on x86 branch). gdb/ 2014-03-20 Pedro Alves <palves@redhat.com> * infrun.c (previous_inferior_ptid): Adjust comment. (deferred_step_ptid): Delete. (infrun_thread_ptid_changed, prepare_to_proceed) (init_wait_for_inferior): Adjust. (handle_signal_stop): Delete deferred_step_ptid handling. gdb/testsuite/ 2014-03-20 Pedro Alves <palves@redhat.com> * gdb.threads/step-over-lands-on-breakpoint.c: New file. * gdb.threads/step-over-lands-on-breakpoint.exp: New file.
2014-03-20 14:26:31 +01:00
2014-03-20 Pedro Alves <palves@redhat.com>
* gdb.threads/step-over-lands-on-breakpoint.c: New file.
* gdb.threads/step-over-lands-on-breakpoint.exp: New file.
gdb.base/async.exp: Enable it. There's no reason not to enable this test anymore. Even if the current output isn't ideal (we mess up the prompt), it's what we have today. We can adjust the test if the output improves. gdb/testsuite/ 2014-03-19 Pedro Alves <palves@redhat.com> * gdb.base/async.exp: Remove early return.
2014-03-19 14:05:43 +01:00
2014-03-19 Pedro Alves <palves@redhat.com>
* gdb.base/async.exp: Remove early return.
gdb.base/async.exp: Make test messages unique. $ cat gdb.sum| grep PASS| sort | uniq -c |sort -n 1 PASS: gdb.base/async.exp: finish& 1 PASS: gdb.base/async.exp: jump& 1 PASS: gdb.base/async.exp: next& 1 PASS: gdb.base/async.exp: nexti& 1 PASS: gdb.base/async.exp: set exec-done-display off 1 PASS: gdb.base/async.exp: set exec-done-display on 1 PASS: gdb.base/async.exp: set target-async on 1 PASS: gdb.base/async.exp: stepi& 1 PASS: gdb.base/async.exp: until& 2 PASS: gdb.base/async.exp: step& gdb/testsuite/ 2014-03-19 Pedro Alves <palves@redhat.com> * gdb.base/async.exp (step& tests): Pass explicit test messages.
2014-03-19 16:22:45 +01:00
2014-03-19 Pedro Alves <palves@redhat.com>
* gdb.base/async.exp (step& tests): Pass explicit test messages.
gdb.base/async.exp: Fix races. This test is currently racy: PASS: gdb.base/async.exp: step& stepi& (gdb) 0x0000000000400547 14 x = 5; x = 5; completed. PASS: gdb.base/async.exp: stepi& nexti& (gdb) 15 y = 3; completed.FAIL: gdb.base/async.exp: nexti& The problem is here: -re "^$command\r\n${before_prompt}${gdb_prompt}${after_prompt}completed\.\r\n" { pass "$command" } -re "$gdb_prompt.*completed\.$" { fail "$command" } Note how the fail pattern is a subset of the pass pattern. If the expect buffer happens to end up with: "^$command\r\n${before_prompt}${gdb_prompt}${after_prompt}completed\." that is, the final "\r\n" has't reached the expect buffer yet, but "completed." has, then the fail pattern matches... gdb/testsuite/ 2014-03-19 Pedro Alves <palves@redhat.com> * gdb.base/async.exp (test_background): Expect \r\n after "completed." in the fail pattern.
2014-03-19 16:22:45 +01:00
2014-03-19 Pedro Alves <palves@redhat.com>
* gdb.base/async.exp (test_background): Expect \r\n after
"completed." in the fail pattern.
gdb.base/async.exp: Factor out test pattern to a procedure. All the tests here follow the same pattern (and they all have the same problem, not fixed here yet). Add a new procedure, factoring out the pattern to a simple place. gdb/testsuite/ 2014-03-19 Pedro Alves <palves@redhat.com> * gdb.base/async.exp (test_background): New procedure. Use it for all background execution command tests.
2014-03-19 16:22:45 +01:00
2014-03-19 Pedro Alves <palves@redhat.com>
* gdb.base/async.exp (test_background): New procedure.
Use it for all background execution command tests.
gdb.base/async.exp: Use prepare_for_testing. gdb/testsuite/ 2014-03-19 Pedro Alves <palves@redhat.com> * gdb.base/async.exp: Use prepare_for_testing.
2014-03-19 16:22:44 +01:00
2014-03-19 Pedro Alves <palves@redhat.com>
* gdb.base/async.exp: Use prepare_for_testing.
gdb.base/async.exp: Fix stepi& test. Currently the test assumes that "stepi" over: 13 x = 5; end up somewhere midline. But, (at least) on x86, that assignment ends up compiled as just one movl instruction, so a stepi stops at the next line already: completed. PASS: gdb.base/async.exp: step & step& (gdb) foo () at ../../../src/gdb/testsuite/gdb.base/async.c:13 13 x = 5; completed. PASS: gdb.base/async.exp: step & stepi& (gdb) 14 y = 3; completed. FAIL: gdb.base/async.exp: (timeout) stepi & nexti& (gdb) 16 return x + y; completed. FAIL: gdb.base/async.exp: (timeout) nexti & finish& Run till exit from #0 foo () at ../../../src/gdb/testsuite/gdb.base/async.c:16 This patch fixes it, by making sure there's more than one instruction in that line. gdb/testsuite/ 2014-03-19 Pedro Alves <palves@redhat.com> * gdb.base/async.c (foo): Make 'x' volatile. Write to it twice in the same line.
2014-03-19 16:22:44 +01:00
2014-03-19 Pedro Alves <palves@redhat.com>
* gdb.base/async.c (foo): Make 'x' volatile. Write to it twice in
the same line.
gdb.base/async.exp: Don't hardcode line numbers. gdb/testsuite/ 2014-03-19 Pedro Alves <palves@redhat.com> * gdb.base/async.c (main): Add "jump here" and "until here" line marker comments. * gdb.base/async.exp (jump_here): New global. (jump& test): Use it. (until_here): New global. (until& test): Use it.
2014-03-19 16:22:44 +01:00
2014-03-19 Pedro Alves <palves@redhat.com>
* gdb.base/async.c (main): Add "jump here" and "until here" line
marker comments.
* gdb.base/async.exp (jump_here): New global.
(jump& test): Use it.
(until_here): New global.
(until& test): Use it.
gdb.base/async.exp: Leave gdb_protocol alone. Many eons ago, async was only implemented in the remote target, and you'd activate it by doing "target async" rather than "target remote". That's long gone now, replaced by "set target-async on". gdb/testsuite/ 2014-03-19 Pedro Alves <palves@redhat.com> * gdb.base/async.exp: Don't frob gdb_protocol.
2014-03-19 16:22:44 +01:00
2014-03-19 Pedro Alves <palves@redhat.com>
* gdb.base/async.exp: Don't frob gdb_protocol.
* gdb.base/async.exp: Whitespace fixes. Turn on target-async. Fix spelling of exec-done-display.
2014-03-19 00:19:51 +01:00
2014-03-18 Doug Evans <xdje42@gmail.com>
* gdb.base/async.exp: Whitespace fixes. Turn on target-async.
Fix spelling of exec-done-display.
Fix SIGTERM signal safety (PR gdb/15358). gdb/ 2014-03-18 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/15358 * defs.h (sync_quit_force_run): New declaration. (QUIT): Check also SYNC_QUIT_FORCE_RUN. * event-top.c (async_sigterm_handler): New declaration. (async_sigterm_token): New variable. (async_init_signals): Create also async_sigterm_token. (async_sigterm_handler): New function. (sync_quit_force_run): New variable. (handle_sigterm): Replace quit_force call by other calls. * utils.c (quit): Call quit_force if SYNC_QUIT_FORCE_RUN. gdb/testsuite/ 2014-03-18 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/15358 * gdb.base/gdb-sigterm.c: New file. * gdb.base/gdb-sigterm.exp: New file. Message-ID: <20140316135334.GA30698@host2.jankratochvil.net>
2014-03-18 22:48:06 +01:00
2014-03-18 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/15358
* gdb.base/gdb-sigterm.c: New file.
* gdb.base/gdb-sigterm.exp: New file.
PR gdb/13860: make "-exec-foo"'s MI output equal to "foo"'s MI output. Part of PR gdb/13860 is about the mi-solib.exp test's output being different in sync vs async modes. sync: >./gdb -nx -q ./testsuite/gdb.mi/solib-main -ex "set stop-on-solib-events 1" -ex "set target-async off" -i=mi =thread-group-added,id="i1" ~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main..." ~"done.\n" (gdb) &"start\n" ~"Temporary breakpoint 1 at 0x400608: file ../../../src/gdb/testsuite/gdb.mi/solib-main.c, line 21.\n" =breakpoint-created,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000000400608",func="main",file="../../../src/gdb/testsuite/gdb.mi/solib-main.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/solib-main.c",line="21",times="0",original-location="main"} ~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n" =thread-group-started,id="i1",pid="17724" =thread-created,id="1",group-id="i1" ^running *running,thread-id="all" (gdb) =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1" ~"Stopped due to shared library event (no libraries added or removed)\n" *stopped,reason="solib-event",frame={addr="0x000000379180f990",func="_dl_debug_state",args=[],from="/lib64/ld-linux-x86-64.so.2"},thread-id="1",stopped-threads="all",core="3" (gdb) async: >./gdb -nx -q ./testsuite/gdb.mi/solib-main -ex "set stop-on-solib-events 1" -ex "set target-async on" -i=mi =thread-group-added,id="i1" ~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main..." ~"done.\n" (gdb) start &"start\n" ~"Temporary breakpoint 1 at 0x400608: file ../../../src/gdb/testsuite/gdb.mi/solib-main.c, line 21.\n" =breakpoint-created,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000000400608",func="main",file="../../../src/gdb/testsuite/gdb.mi/solib-main.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/solib-main.c",line="21",times="0",original-location="main"} ~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n" =thread-group-started,id="i1",pid="17729" =thread-created,id="1",group-id="i1" ^running *running,thread-id="all" =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1" (gdb) *stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="1" For now, let's focus only on the *stopped event. We see that the async output is missing frame info. And this causes a test failure in async mode, as "mi_expect_stop solib-event" wants to see the frame info. However, if we compare the event output when a real MI execution command is used, compared to a CLI command (e.g., run vs -exec-run, next vs -exec-next, etc.), we see: >./gdb -nx -q ./testsuite/gdb.mi/solib-main -ex "set stop-on-solib-events 1" -ex "set target-async off" -i=mi =thread-group-added,id="i1" ~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main..." ~"done.\n" (gdb) r &"r\n" ~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n" =thread-group-started,id="i1",pid="17751" =thread-created,id="1",group-id="i1" ^running *running,thread-id="all" (gdb) =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1" ~"Stopped due to shared library event (no libraries added or removed)\n" *stopped,reason="solib-event",frame={addr="0x000000379180f990",func="_dl_debug_state",args=[],from="/lib64/ld-linux-x86-64.so.2"},thread-id="1",stopped-threads="all",core="3" (gdb) -exec-run =thread-exited,id="1",group-id="i1" =thread-group-exited,id="i1" =library-unloaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",thread-group="i1" =thread-group-started,id="i1",pid="17754" =thread-created,id="1",group-id="i1" ^running *running,thread-id="all" (gdb) =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1" *stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="1" =thread-selected,id="1" (gdb) As seen above, with MI commands, the *stopped event _doesn't_ have frame info. This is because normal_stop, as commanded by the result of bpstat_print, skips printing frame info in this case (it's an "event", not a "breakpoint"), and when the interpreter is MI, mi_on_normal_stop skips calling print_stack_frame, as the normal_stop call was already done with the MI uiout. This explains why the async output is different even with a CLI command. Its because in async mode, the mi_on_normal_stop path is always taken; it is always reached with the MI uiout, because the stop is handled from the event loop, instead of from within `proceed -> wait_for_inferior -> normal_stop' with the interpreter overridden, as in sync mode. This patch fixes the issue by making all cases output the same *stopped event, by factoring out the print code from normal_stop, and using it from mi_on_normal_stop as well. I chose the *stopped output without a frame, mainly because that is what you already get if you use MI execution commands, the commands frontends are supposed to use (except when implementing a console). This patch makes it simpler to tweak the MI output differently if desired, as we only have to change the centralized print_stop_event (taking into account whether the uiout is MI-like), and all different modes will change accordingly. Tested on x86_64 Fedora 17, no regressions. The mi-solib.exp test no longer fails in async mode with this patch, so the patch removes the kfail. 2014-03-18 Pedro Alves <palves@redhat.com> PR gdb/13860 * inferior.h (print_stop_event): Declare. * infrun.c (print_stop_event): New, factored out from ... (normal_stop): ... this. * mi/mi-interp.c (mi_on_normal_stop): Use print_stop_event instead of bpstat_print/print_stack_frame. 2014-03-18 Pedro Alves <palves@redhat.com> PR gdb/13860 * gdb.mi/mi-solib.exp: Remove gdb/13860 kfail. * lib/mi-support.exp (mi_expect_stop): Add special handling for solib-event.
2014-03-18 18:50:28 +01:00
2014-03-18 Pedro Alves <palves@redhat.com>
PR gdb/13860
* gdb.mi/mi-solib.exp: Remove gdb/13860 kfail.
* lib/mi-support.exp (mi_expect_stop): Add special handling for
solib-event.
[testsuite/Ada] New testcase for packed array renaming. gdb/testsuite/ChangeLog: * gdb.ada/pckd_arr_ren: New testcase.
2014-03-17 16:41:48 +01:00
2014-03-17 Joel Brobecker <brobecker@adacore.com>
* gdb.ada/pckd_arr_ren: New testcase.
Fix pr 16612. * guile/scm-type.c (tyscm_copy_type_recursive): Move type to its new eq?-hashtab. testsuite/ * gdb.guile/scm-value.ep (test_value_after_death): Do a garbage collect after discarding symbols.
2014-03-13 17:55:12 +01:00
2014-03-13 Doug Evans <xdje42@gmail.com>
PR guile/16612
* gdb.guile/scm-value.ep (test_value_after_death): Do a garbage
collect after discarding symbols.
Fix segv when referencing a value added to history after a Guile garbage collect. * value.c (record_latest_value): Call release_value_or_incref instead of release_value. testsuite/ * gdb.guile/scm-value.exp (test_value_in_inferior): Verify value added to history survives a gc.
2014-03-13 17:24:19 +01:00
2014-03-13 Ludovic Courtès <ludo@gnu.org>
Doug Evans <xdje42@gmail.com>
* gdb.guile/scm-value.exp (test_value_in_inferior): Verify value added
to history survives a gc.
Rename Solaris's target to "target child" like most other ports. Note that "target procfs" is used by QNX, but the test must be failing there, as nto-procfs.c overrides to_open with a method that doesn't throw the error being tested. So I'm just removing the test completely. gdb/ 2014-03-13 Pedro Alves <palves@redhat.com> * procfs.c (procfs_target): Don't override to_shortname, to_longname or to_doc. gdb/testsuite/ 2014-03-13 Pedro Alves <palves@redhat.com> * gdb.base/default.exp: Don't test "target procfs".
2014-03-12 13:40:40 +01:00
2014-03-13 Pedro Alves <palves@redhat.com>
* gdb.base/default.exp: Don't test "target procfs".
Don't mention "Unix" in native target name. I find the mention of "Unix" unnecessary (and really slightly a lie) on GNU/Linux in a couple of places: (gdb) maint print target-stack The current target stack is: - multi-thread (multi-threaded child process.) - child (Unix child process) - exec (Local exec file) - None (None) (gdb) help target child Unix child process (started by the "run" command). (gdb) target child Use the "run" command to start a Unix child process. It's also odd that e.g., the Windows port says "Unix" in reaction to "target child" (it was already that way before Windows used inf-child.c): (gdb) target child Use the "run" command to start a Unix child process. (gdb) So drop "Unix", going in the direction of saying mostly the same on all native targets: (gdb) maint print target-stack The current target stack is: - multi-thread (multi-threaded child process.) - - child (Unix child process) + - child (Child process) - exec (Local exec file) - None (None) (gdb) help target child - Unix child process (started by the "run" command). + Child process (started by the "run" command). (gdb) target child -Use the "run" command to start a Unix child process. +Use the "run" command to start a child process. gdb/ 2014-03-13 Pedro Alves <palves@redhat.com> * inf-child.c (inf_child_open, inf_child_target): Don't mention Unix in user visible strings. gdb/testsuite/ 2014-03-13 Pedro Alves <palves@redhat.com> * gdb.base/default.exp: Update "target child" and "target procfs" tests to not expect "Unix".
2014-03-13 13:02:24 +01:00
2014-03-13 Pedro Alves <palves@redhat.com>
* gdb.base/default.exp: Update "target child" and "target procfs"
tests to not expect "Unix".
fix regressions with target-async A patch in the target cleanup series caused a regression when using record with target-async. Version 4 of the patch is here: https://sourceware.org/ml/gdb-patches/2014-03/msg00159.html The immediate problem is that record supplies to_can_async_p and to_is_async_p methods, but does not supply a to_async method. So, when target-async is set, record claims to support async -- but if the underlying target does not support async, then the to_async method call will end up in that method's default implementation, namely tcomplain. This worked previously because the record target used to provide a to_async method; one that (erroneously, only at push time) checked the other members of the target stack, and then simply dropped to_async calls in the "does not implement async" case. My first thought was to simply drop tcomplain as the default for to_async. This works, but Pedro pointed out that the only reason record has to supply to_can_async_p and to_is_async_p is that these default to using the find_default_run_target machinery -- and these defaults are only needed by "run" and "attach". So, a nicer solution presents itself: change run and attach to explicitly call into the default run target when needed; and change to_is_async_p and to_can_async_p to default to "return 0". This makes the target stack simpler to use and lets us remove the method implementations from record. This is also in harmony with other plans for the target stack; namely trying to reduce the impact of find_default_run_target. This approach makes it clear that find_default_is_async_p is not needed -- it is asking whether a target that may not even be pushed is actually async, which seems like a nonsensical question. While an improvement, this approach proved to introduce the same bug when using the core target. Looking a bit deeper, the issue is that code in "attach" and "run" may need to use either the current target stack or the default run target -- but different calls into the target API in those functions could wind up querying different targets. This new patch makes the target to use more explicit in "run" and "attach". Then these commands explicitly make the needed calls against that target. This ensures that a single target is used for all relevant operations. This lets us remove a couple find_default_* functions from various targets, including the dummy target. I think this is a decent understandability improvement. One issue I see with this patch is that the new calls in "run" and "attach" are not very much like the rest of the target API. I think fundamentally this is due to bad factoring in the target API, which may need to be fixed for multi-target. Tackling that seemed ambitious for a regression fix. While working on this I noticed that there don't seem to be any test cases that involve both target-async and record, so this patch changes break-precsave.exp to add some. It also changes corefile.exp to add some target-async tests; these pass with current trunk and with this patch applied, but fail with the v1 patch. This patch differs from v4 in that it moves initialization of to_can_async_p and to_supports_non_stop into inf-child, adds some assertions to complete_target_initialization, and adds some comments to target.h. Built and regtested on x86-64 Fedora 20. 2014-03-12 Tom Tromey <tromey@redhat.com> * inf-child.c (return_zero): New function. (inf_child_target): Set to_can_async_p, to_supports_non_stop. * aix-thread.c (aix_thread_inferior_created): New function. (aix_thread_attach): Remove. (init_aix_thread_ops): Don't set to_attach. (_initialize_aix_thread): Register inferior_created observer. * corelow.c (init_core_ops): Don't set to_attach or to_create_inferior. * exec.c (init_exec_ops): Don't set to_attach or to_create_inferior. * infcmd.c (run_command_1): Use find_run_target. Make direct target calls. (attach_command): Use find_attach_target. Make direct target calls. * record-btrace.c (init_record_btrace_ops): Don't set to_create_inferior. * record-full.c (record_full_can_async_p, record_full_is_async_p): Remove. (init_record_full_ops, init_record_full_core_ops): Update. Don't set to_create_inferior. * target.c (complete_target_initialization): Add assertion. (target_create_inferior): Remove. (find_default_attach, find_default_create_inferior): Remove. (find_attach_target, find_run_target): New functions. (find_default_is_async_p, find_default_can_async_p) (target_supports_non_stop, target_attach): Remove. (init_dummy_target): Don't set to_create_inferior or to_supports_non_stop. * target.h (struct target_ops) <to_attach>: Add comment. Remove TARGET_DEFAULT_FUNC. <to_create_inferior>: Add comment. <to_can_async_p, to_is_async_p, to_supports_non_stop>: Use TARGET_DEFAULT_RETURN. <to_can_async_p, to_supports_non_stop, to_can_run>: Add comments. (find_attach_target, find_run_target): Declare. (target_create_inferior): Remove. (target_has_execution_1): Update comment. (target_supports_non_stop): Remove. * target-delegates.c: Rebuild. 2014-03-12 Tom Tromey <tromey@redhat.com> * gdb.base/corefile.exp (corefile_test_run, corefile_test_attach): New procs. Add target-async tests. * gdb.reverse/break-precsave.exp (precsave_tests): New proc. Add target-async tests.
2014-02-28 17:47:34 +01:00
2014-03-12 Tom Tromey <tromey@redhat.com>
* gdb.base/corefile.exp (corefile_test_run, corefile_test_attach):
New procs. Add target-async tests.
* gdb.reverse/break-precsave.exp (precsave_tests): New proc.
Add target-async tests.
Fix dw2-ifort-parameter.exp on PPC64 On PPC64, 'func' and 'main' are function descriptors and don't point to the actual code. Thus the usage of these symbols in the DWARF assembler source was broken. The patch introduces new labels func_start and func_end for this purpose.
2014-03-07 13:23:47 +01:00
2014-03-12 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.dwarf2/dw2-ifort-parameter.c (func): Define labels
'func_start' and 'func_end' for the beginning and end of the
function code, respectively.
* gdb.dwarf2/dw2-ifort-parameter.exp: Use 'func_start' and
'func_end' instead of 'func' and 'main'.
Migrate dw2-ifort-parameter.exp to Dwarf::assemble A "side effect" of the migration to Dwarf::assemble is that the DWARF address size is now automatically adjusted to the target architecture. The original assembler source hard-coded the DWARF address size to 4, even on 64-bit architectures. This address size mismatch caused a test case failure on s390x due to a wrong result from DW_OP_deref.
2014-03-07 12:52:54 +01:00
2014-03-12 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.dwarf2/dw2-ifort-parameter-debug.S: Remove.
* gdb.dwarf2/dw2-ifort-parameter.exp: Use Dwarf::assemble to
generate the debug info assembler source.
Exploit 'prepare_for_testing' etc. for 'Dwarf::assemble'-generated files Now that prepare_for_testing etc. can cope with absolute path names, this can be exploited for test cases with generated source files. This is just to simplify the code and shouldn't cause any functional change.
2014-03-07 12:45:49 +01:00
2014-03-12 Andreas Arnez <arnez@linux.vnet.ibm.com>
* gdb.dwarf2/arr-stride.exp: Exploit 'prepare_for_testing'.
* gdb.dwarf2/arr-subrange.exp: Likewise.
* gdb.dwarf2/dwz.exp: Likewise.
* gdb.dwarf2/method-ptr.exp: Likewise.
* gdb.dwarf2/missing-sig-type.exp: Likewise.
* gdb.dwarf2/subrange.exp: Likewise.
* gdb.dwarf2/implptrconst.exp: Exploit 'build_executable'.
* gdb.dwarf2/implptrpiece.exp: Likewise.
* gdb.dwarf2/nostaticblock.exp: Likewise.
gdb.exp: Support absolute path name args in 'prepare_for_testing' etc. Test cases that produce source files in the build directory have not been able to use prepare_for_testing and friends. This was because build_executable_from_specs unconditionally prepended the source directory path name to its arguments.
2014-03-07 11:23:42 +01:00
2014-03-12 Andreas Arnez <arnez@linux.vnet.ibm.com>
* lib/gdb.exp (build_executable_from_specs): Don't prepend source
directory to absolute path name arguments.
[Ada] Full view of tagged type with ptype When evaluating an expression, if it is of a tagged type, GDB reads the tag in memory and deduces the full view. At parsing time, however, this operation is done only in the case of OP_VAR_VALUE. ptype does not go through a full evaluation of expressions so it may return some odd results: (gdb) print c.menu_name $1 = 0x0 (gdb) ptype $ type = system.strings.string_access (gdb) ptype c.menu_name type = <void> This change removes this peculiarity by extending the tag resolution to UNOP_IND and STRUCTOP_STRUCT. As in the case of OP_VAR_VALUE, this implies switching from EVAL_AVOID_SIDE_EFFECTS to EVAL_NORMAL when a tagged type is dereferenced. gdb/ * ada-lang.c (ada_evaluate_subexp): Resolve tagged types to full view in the case of UNOP_IND and STRUCTOP_STRUCT. gdb/testsuite/ * gdb.ada/tagged_access: New testcase.
2014-02-12 12:08:23 +01:00
2014-03-10 Joel Brobecker <brobecker@adacore.com>
* gdb.ada/tagged_access: New testcase.
btrace, test: fix gdb.btrace/data test The format of the output changed. Fix the test. testsuite/ * gdb.btrace/data.exp: Update expected output.
2014-03-05 11:17:35 +01:00
2014-03-07 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/data.exp: Update expected output.
Fix PR16508 This patch fixes PR16508, which is about MI "-trace-find frame-number 0" behaves differently from CLI "tfind 0". In CLI, we check both status->running and status->filename, but in MI, we only check status->running, which looks wrong to me. This patch moves the code of checking to a new function check_trace_running, and use it in both CLI and MI. This patch also adds a test case pr16508.exp, which fails without this fix, and passes with the fix applied. FAIL: gdb.trace/pr16508.exp: interpreter-exec mi "-trace-find frame-number 0" gdb: 2014-03-06 Yao Qi <yao@codesourcery.com> PR breakpoints/16508 * tracepoint.c (check_trace_running): New function. (trace_find_command): Move code to check_trace_running and call check_trace_running. (trace_find_pc_command): Likewise. (trace_find_tracepoint_command): Likewise. (trace_find_line_command): Likewise. (trace_find_range_command): Likewise. * tracepoint.h (check_trace_running): Likewise. * mi/mi-main.c (mi_cmd_trace_find): Call check_trace_running. gdb/testsuite: 2014-03-06 Yao Qi <yao@codesourcery.com> * gdb.trace/pr16508.exp: New file.
2014-02-15 01:48:53 +01:00
2014-03-06 Yao Qi <yao@codesourcery.com>
* gdb.trace/pr16508.exp: New file.
PR gdb/16575: stale breakpoint instructions in the code cache In non-stop mode, or rather, breakpoints always-inserted mode, the code cache can easily end up with stale breakpoint instructions: All it takes is filling a cache line when breakpoints already exist in that memory region, and then delete the breakpoint. Vis. (from the new test): (gdb) set breakpoint always-inserted on (gdb) b 23 Breakpoint 2 at 0x400540: file ../../../src/gdb/testsuite/gdb.base/breakpoint-shadow.c, line 23. (gdb) b 24 Breakpoint 3 at 0x400547: file ../../../src/gdb/testsuite/gdb.base/breakpoint-shadow.c, line 24. disass main Dump of assembler code for function main: 0x000000000040053c <+0>: push %rbp 0x000000000040053d <+1>: mov %rsp,%rbp => 0x0000000000400540 <+4>: movl $0x1,-0x4(%rbp) 0x0000000000400547 <+11>: movl $0x2,-0x4(%rbp) 0x000000000040054e <+18>: mov $0x0,%eax 0x0000000000400553 <+23>: pop %rbp 0x0000000000400554 <+24>: retq End of assembler dump. So far so good. Now flush the code cache: (gdb) set code-cache off (gdb) set code-cache on Requesting a disassembly works as expected, breakpoint shadowing is applied: (gdb) disass main Dump of assembler code for function main: 0x000000000040053c <+0>: push %rbp 0x000000000040053d <+1>: mov %rsp,%rbp => 0x0000000000400540 <+4>: movl $0x1,-0x4(%rbp) 0x0000000000400547 <+11>: movl $0x2,-0x4(%rbp) 0x000000000040054e <+18>: mov $0x0,%eax 0x0000000000400553 <+23>: pop %rbp 0x0000000000400554 <+24>: retq End of assembler dump. However, now delete the breakpoints: (gdb) delete Delete all breakpoints? (y or n) y And disassembly shows the old breakpoint instructions: (gdb) disass main Dump of assembler code for function main: 0x000000000040053c <+0>: push %rbp 0x000000000040053d <+1>: mov %rsp,%rbp => 0x0000000000400540 <+4>: int3 0x0000000000400541 <+5>: rex.RB cld 0x0000000000400543 <+7>: add %eax,(%rax) 0x0000000000400545 <+9>: add %al,(%rax) 0x0000000000400547 <+11>: int3 0x0000000000400548 <+12>: rex.RB cld 0x000000000040054a <+14>: add (%rax),%al 0x000000000040054c <+16>: add %al,(%rax) 0x000000000040054e <+18>: mov $0x0,%eax 0x0000000000400553 <+23>: pop %rbp 0x0000000000400554 <+24>: retq End of assembler dump. Those breakpoint instructions are no longer installed in target memory they're stale in the code cache. Easily confirmed by just disabling the code cache: (gdb) set code-cache off (gdb) disass main Dump of assembler code for function main: 0x000000000040053c <+0>: push %rbp 0x000000000040053d <+1>: mov %rsp,%rbp => 0x0000000000400540 <+4>: movl $0x1,-0x4(%rbp) 0x0000000000400547 <+11>: movl $0x2,-0x4(%rbp) 0x000000000040054e <+18>: mov $0x0,%eax 0x0000000000400553 <+23>: pop %rbp 0x0000000000400554 <+24>: retq End of assembler dump. I stumbled upon this when writing a patch to infrun.c, that made handle_inferior_event & co fill in the cache before breakpoints were removed from the target. Recall that wait_for_inferior flushes the dcache for every event. So in that case, always-inserted mode was not necessary to trigger this. It's just a convenient way to expose the issue. The dcache works at the raw memory level. We need to update it whenever memory is written, no matter what kind of target memory object was originally passed down by the caller. The issue is that the dcache update code isn't reached when a caller explicitly writes raw memory. Breakpoint insertion/removal is one such case -- mem-break.c uses target_write_read_memory/target_write_raw_memory. The fix is to move the dcache update code from memory_xfer_partial_1 to raw_memory_xfer_partial so that it's always reachable. When we do that, we can actually simplify a series of things. memory_xfer_partial_1 no longer needs to handle writes for any kind of memory object, and therefore dcache_xfer_memory no longer needs to handle writes either. So the latter (dcache_xfer_memory) and its callees can be simplified to only care about reads. While we're touching dcache_xfer_memory's prototype, might as well rename it to reflect that fact that it only handles reads, and make it follow the new target_xfer_status/xfered_len style. This made me notice that dcache_xfer_memory loses the real error status if a memory read fails: we could have failed to read due to TARGET_XFER_E_UNAVAILABLE, for instance, but we always return TARGET_XFER_E_IO, hence the FIXME note. I felt that fixing that fell out of the scope of this patch. Currently dcache_xfer_memory handles the case of a write failing. The whole cache line is invalidated when that happens. However, dcache_update, the sole mechanism for handling writes that will remain after the patch, does not presently handle that scenario. That's a bug. The patch makes it handle that, by passing down the target_xfer_status status from the caller, so that it can better decide what to do itself. While I was changing the function's prototype, I constified the myaddr parameter, getting rid of the need for the cast as seen in its existing caller. Tested on x86_64 Fedora 17, native and gdbserver. gdb/ 2014-03-05 Pedro Alves <palves@redhat.com> PR gdb/16575 * dcache.c (dcache_poke_byte): Constify ptr parameter. Return void. Update comment. (dcache_xfer_memory): Delete. (dcache_read_memory_partial): New, based on the read bits of dcache_xfer_memory. (dcache_update): Add status parameter. Use ULONGEST for len, and adjust. Discard cache lines if the reason for the update was error. * dcache.h (dcache_xfer_memory): Delete declaration. (dcache_read_memory_partial): New declaration. (dcache_update): Update prototype. * target.c (raw_memory_xfer_partial): Update the dcache here. (memory_xfer_partial_1): Don't handle dcache writes here. gdb/testsuite/ 2014-03-05 Pedro Alves <palves@redhat.com> PR gdb/16575 * gdb.base/breakpoint-shadow.exp (compare_disassembly): New procedure. (top level): Adjust to use it. Add tests that exercise breakpoint interaction with the code-cache.
2014-03-05 15:18:28 +01:00
2014-03-05 Pedro Alves <palves@redhat.com>
PR gdb/16575
* gdb.base/breakpoint-shadow.exp (compare_disassembly): New
procedure.
(top level): Adjust to use it. Add tests that exercise breakpoint
interaction with the code-cache.
guile: Add 'history-append!' procedure. gdb/ 2014-02-26 Ludovic Courtès <ludo@gnu.org> * guile/scm-value.c (gdbscm_history_append_x): New function. (value_functions): Add it. gdb/testsuite/ 2014-02-26 Ludovic Courtès <ludo@gnu.org> * gdb.guile/scm-value.exp (test_value_in_inferior): Add test for 'history-append!'. gdb/doc/ 2014-02-26 Ludovic Courtès <ludo@gnu.org> * gdb/doc/guile.texi (Basic Guile): Document 'history-append!'.
2014-02-18 23:35:46 +01:00
2014-02-26 Ludovic Courtès <ludo@gnu.org>
* gdb.guile/scm-value.exp (test_value_in_inferior): Add
test for 'history-append!'.
DWARF: Read constant-class addresses correctly Starting with DWARF version 4, the description of the DW_AT_high_pc attribute was amended to say: if it is of class constant, the value is an unsigned integer offset which when added to the low PC gives the address of the first location past the last instruction associated with the entity. A change was made in Apr 27th, 2012 to reflect that change: | commit 91da14142c0171e58a91ad58a32fd010b700e761 | Author: Mark Wielaard <mjw@redhat.com> | Date: Fri Apr 27 18:55:19 2012 +0000 | | * dwarf2read.c (dwarf2_get_pc_bounds): Check DW_AT_high_pc form to | see whether it is an address or a constant offset from DW_AT_low_pc. | (dwarf2_record_block_ranges): Likewise. | (read_partial_die): Likewise. Unfortunately, this new interpretation is now used regardless of the CU's DWARF version. It turns out that one of WindRiver's compilers (FTR: Diabdata 4.4) is generating DWARF version 2 info with DW_AT_high_pc attributes improperly using the data4 form. Because of that, we miscompute all high PCs incorrectly. This leads to a lot of symtabs having overlapping ranges, which in turn causes havoc in pc-to-symtab-and-line translations. One visible effect is when inserting a breakpoint on a given function: (gdb) b world Breakpoint 1 at 0x4005c4 The source location of the breakpoint is missing. The output should be: (gdb) b world Breakpoint 1 at 0x4005c8: file dw2-rel-hi-pc-world.c, line 24. What happens in this case is that the pc-to-SAL translation first starts be trying to find the symtab associated to our PC using each symtab's ranges. Because of the high_pc miscomputation, many symtabs end up matching, and the heuristic trying to select the most probable one unfortunately returns one that is unrelated (it really had no change in this case to do any better). Once we have the wrong symtab, the start searching the associated linetable, where the addresses are correct, thus finding no match, and therefore no SAL. This patch is an attempt at handling the situation as gracefully as we can, without guarantees. It introduces a new function "attr_value_as_address" which uses the correct accessor for getting the value of a given attribute. It then adjust the code throughout this unit to use this function instead of assuming that addresses always have the DW_FORM_addr format. It also fixes the original issue of miscomputing the high_pc by limiting the new interpretation of constant form DW_AT_high_pc attributes to units using DWARF version 4 or later. gdb/ChangeLog: * dwarf2read.c (attr_value_as_address): New function. (dwarf2_find_base_address, read_call_site_scope): Use attr_value_as_address in place of DW_ADDR. (dwarf2_get_pc_bounds): Use attr_value_as_address to get the low and high addresses. Slight rework of the handling of the high pc being a constant form, and limit it to DWARF verson 4 or higher. (dwarf2_record_block_ranges): Likewise. (read_partial_die): Likewise. (new_symbol_full): Use attr_value_as_address in place of DW_ADDR. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-abs-hi-pc-hello-dbg.S: New file. * gdb.dwarf2/dw2-abs-hi-pc-hello.c: New file. * gdb.dwarf2/dw2-abs-hi-pc-world-dbg.S: New file. * gdb.dwarf2/dw2-abs-hi-pc-world.c: New file. * gdb.dwarf2/dw2-abs-hi-pc.c: New file. * gdb.dwarf2/dw2-abs-hi-pc.exp: New file. Tested on x86_64-linux.
2014-02-15 16:09:58 +01:00
2014-02-26 Joel Brobecker <brobecker@adacore.com>
* gdb.dwarf2/dw2-abs-hi-pc-hello-dbg.S: New file.
* gdb.dwarf2/dw2-abs-hi-pc-hello.c: New file.
* gdb.dwarf2/dw2-abs-hi-pc-world-dbg.S: New file.
* gdb.dwarf2/dw2-abs-hi-pc-world.c: New file.
* gdb.dwarf2/dw2-abs-hi-pc.c: New file.
* gdb.dwarf2/dw2-abs-hi-pc.exp: New file.
[Python] Make regexp collection printers work with typedefs as well. Consider the following type for which we would like to provide a pretty-printer and manage it via RegexpCollectionPrettyPrinter: typedef long time_t; Currently, this does not work because this framework only considers the type's tag name: typename = gdb.types.get_basic_type(val.type).tag if not typename: return None This patch extends it to use the type's name if the basic type does not have a tag name, thus allowing the framework to also work with typedefs like the above. gdb/ChangeLog: * python/lib/gdb/printing.py (RegexpCollectionPrettyPrinter): Use the type's name if its basic type does not have a tag. gdb/testsuite/ChangeLog: * testsuite/gdb.python/py-pp-re-notag.c: New file. * testsuite/gdb.python/py-pp-re-notag.ex: New file. * testsuite/gdb.python/py-pp-re-notag.p: New file.
2014-01-30 04:37:08 +01:00
2014-02-26 Joel Brobecker <brobecker@adacore.com>
* testsuite/gdb.python/py-pp-re-notag.c: New file.
* testsuite/gdb.python/py-pp-re-notag.ex: New file.
* testsuite/gdb.python/py-pp-re-notag.p: New file.
DWARF: Set enum type "flag_enum" and "unsigned" flags at type creation. Consider the following Ada code: -- An array whose index is an enumeration type with 128 enumerators. type Enum_T is (Enum_000, Enum_001, [...], Enum_128); type Table is array (Enum_T) of Boolean; When the compiler is configured to generate pure DWARF debugging info, trying to print type Table's description yields: ptype pck.table type = array (enum_000 .. -128) of boolean The expected output was: ptype pck.table type = array (enum_000 .. enum_128) of boolean The DWARF debugging info for our array looks like this: <1><44>: Abbrev Number: 5 (DW_TAG_array_type) <45> DW_AT_name : pck__table <50> DW_AT_type : <0x28> <2><54>: Abbrev Number: 6 (DW_TAG_subrange_type) <55> DW_AT_type : <0x5c> <59> DW_AT_lower_bound : 0 <5a> DW_AT_upper_bound : 128 The array index type is, by construction with the DWARF standard, a subrange of our enumeration type, defined as follow: <2><5b>: Abbrev Number: 0 <1><5c>: Abbrev Number: 7 (DW_TAG_enumeration_type) <5d> DW_AT_name : pck__enum_t <69> DW_AT_byte_size : 1 <2><6b>: Abbrev Number: 8 (DW_TAG_enumerator) <6c> DW_AT_name : pck__enum_000 <7a> DW_AT_const_value : 0 [etc] Therefore, while processing these DIEs, the array index type ends up being a TYPE_CODE_RANGE whose target type is our enumeration type. But the problem is that we read the upper bound as a negative value (-128), which is then used as is by the type printer to print the array upper bound. This negative value explains the "-128" in the output. To understand why the range type's upper bound is read as a negative value, one needs to look at how it is determined, in read_subrange_type: orig_base_type = die_type (die, cu); base_type = check_typedef (orig_base_type); [... high is first correctly read as 128, but then ...] if (!TYPE_UNSIGNED (base_type) && (high & negative_mask)) high |= negative_mask; The negative_mask is applied, here, because BASE_TYPE->FLAG_UNSIGNED is not set. And the reason for that is because the base_type was only partially constructed during the call to die_type. While the enum is constructed on the fly by read_enumeration_type, its flag_unsigned flag is only set later on, while creating the symbols corresponding to the enum type's enumerators (see process_enumeration_scope), after we've already finished creating our range type - and therefore too late. My first naive attempt at fixing this problem consisted in extracting the part in process_enumeration_scope which processes all enumerators, to generate the associated symbols, but more importantly set the type's various flags when necessary. However, this does not always work well, because we're still in the subrange_type's scope, and it might be different from the scope where the enumeration type is defined. So, instead, what this patch does to fix the issue is to extract from process_enumeration_scope the part that determines whether the enumeration type should have the flag_unsigned and/or the flag_flag_enum flags set. It turns out that, aside from the code implementing the loop, this part is fairly independent of the symbol creation. With that part extracted, we can then use it at the end of our enumeration type creation, to produce a type which should now no longer need any adjustment. Once the enumeration type produced is correctly marked as unsigned, the subrange type's upper bound is then correctly read as an unsigned value, therefore giving us an upper bound of 128 instead of -128. gdb/ChangeLog: * dwarf2read.c (update_enumeration_type_from_children): New function, mostly extracted from process_structure_scope. (read_enumeration_type): Call update_enumeration_type_from_children. (process_enumeration_scope): Do not set THIS_TYPE's flag_unsigned and flag_flag_enum fields. gdb/testsuite/ChangeLog: * gdb.dwarf2/arr-subrange.c, gdb.dwarf2/arr-subrange.exp: New files.
2014-01-22 15:40:20 +01:00
2014-02-26 Joel Brobecker <brobecker@adacore.com>
* gdb.dwarf2/arr-subrange.c, gdb.dwarf2/arr-subrange.exp: New files.
DWARF: Add array DW_AT_bit_stride and DW_AT_byte_stride support Consider the following declarations in Ada... type Item is range -32 .. 31; for Item'Size use 6; type Table is array (Natural range 0 .. 4) of Item; pragma Pack (Table); ... which declare a packed array whose elements are 6 bits long. The debugger currently does not notice that the array is packed, and thus prints values of this type incorrectly. This can be seen in the "ptype" output: (gdb) ptype table type = array (0 .. 4) of foo.item Normally, the debugger should print: (gdb) ptype table type = array (0 .. 4) of foo.item <packed: 6-bit elements> The debugging information for this array looks like this: .uleb128 0xf # (DIE (0x15c) DW_TAG_array_type) .long .LASF9 # DW_AT_name: "pck__table" .byte 0x6 # DW_AT_bit_stride .long 0x1a9 # DW_AT_type .uleb128 0x10 # (DIE (0x16a) DW_TAG_subrange_type) .long 0x3b # DW_AT_type .byte 0 # DW_AT_lower_bound .byte 0x4 # DW_AT_upper_bound .byte 0 # end of children of DIE 0x15c The interesting part is the DW_AT_bit_stride attribute, which tells the size of the array elements is 6 bits, rather than the normal element type's size. This patch adds support for this attribute by first creating gdbtypes.c::create_array_type_with_stride, which is an enhanced version of create_array_type taking an extra parameter as the stride. The old create_array_type can then be re-implemented very simply by calling the new create_array_type_with_stride. We can then use this new function from dwarf2read, to create arrays with or without stride. gdb/ChangeLog: * gdbtypes.h (create_array_type_with_stride): Add declaration. * gdbtypes.c (create_array_type_with_stride): New function, renaming create_array_type, but with an added parameter called "bit_stride". (create_array_type): Re-implement using create_array_type_with_stride. * dwarf2read.c (read_array_type): Add support for DW_AT_byte_stride and DW_AT_bit_stride attributes. gdb/testsuite/ChangeLog: * gdb.dwarf2/arr-stride.c: New file. * gdb.dwarf2/arr-stride.exp: New file. The test, relying purely on generating an assembly file, only verifies the type description of our array. But I was also able to verify manually that the debugger print values of these types correctly as well (which was not the case prior to this patch).
2014-01-29 14:39:56 +01:00
2014-02-26 Joel Brobecker <brobecker@adacore.com>
* gdb.dwarf2/arr-stride.c: New file.
* gdb.dwarf2/arr-stride.exp: New file.
Multiple Ada task-specific breakpoints at the same address. With the test changed as in the patch, against current mainline, we get: (gdb) PASS: gdb.ada/tasks.exp: info tasks before inserting breakpoint break break_me task 1 Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27. (gdb) PASS: gdb.ada/tasks.exp: break break_me task 1 break break_me task 3 Note: breakpoint 2 also set at pc 0x4030b0. Breakpoint 3 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27. (gdb) PASS: gdb.ada/tasks.exp: break break_me task 3 continue Continuing. [Switching to Thread 0x7ffff7dc7700 (LWP 27133)] Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27 27 null; (gdb) FAIL: gdb.ada/tasks.exp: continue to breakpoint info tasks ID TID P-ID Pri State Name 1 63b010 48 Waiting on RV with 3 main_task 2 63bd80 1 48 Accept or Select Term task_list(1) * 3 63f510 1 48 Accepting RV with 1 task_list(2) 4 642ca0 1 48 Accept or Select Term task_list(3) (gdb) PASS: gdb.ada/tasks.exp: info tasks after hitting breakpoint The breakpoint that caused a stop is breakpoint 3, but GDB end up reporting (and running breakpoint commands of) "Breakpoint 2" instead. The issue is that the bpstat_check_breakpoint_conditions logic of "wrong thread" is missing the "wrong task" check. This is usually harmless, because the thread hop code in infrun.c code that handles wrong-task-hitting-breakpoint does check for task-specific breakpoints (within breakpoint_thread_match): /* Check if a regular breakpoint has been hit before checking for a potential single step breakpoint. Otherwise, GDB will not see this breakpoint hit when stepping onto breakpoints. */ if (regular_breakpoint_inserted_here_p (aspace, stop_pc)) { if (!breakpoint_thread_match (aspace, stop_pc, ecs->ptid)) thread_hop_needed = 1; } IOW, usually, when one only has a task specific breakpoint at a given address, things work correctly. Put another task-specific or non-task-specific breakpoint there, and things break. A patch that eliminates the special thread hop code in infrun.c is what exposed this, as after that GDB solely relies on bpstat_check_breakpoint_conditions to know whether the right or wrong task hit a breakpoint. IOW, given the latent bug, Ada task-specific breakpoints become non-task-specific, and that is caught by the testsuite, as: break break_me task 3 Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27. (gdb) PASS: gdb.ada/tasks.exp: break break_me task 3 continue Continuing. [Switching to Thread 0x7ffff7fcb700 (LWP 17122)] Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27 27 null; (gdb) PASS: gdb.ada/tasks.exp: continue to breakpoint info tasks ID TID P-ID Pri State Name 1 63b010 48 Waiting on RV with 2 main_task * 2 63bd80 1 48 Accepting RV with 1 task_list(1) 3 63f510 1 48 Accept or Select Term task_list(2) 4 642ca0 1 48 Accept or Select Term task_list(3) (gdb) FAIL: gdb.ada/tasks.exp: info tasks after hitting breakpoint It was after seeing this that I thought of how to expose the bug with current mainline. Tested on x86_64 Fedora 17. gdb/ 2014-02-26 Pedro Alves <palves@redhat.com> * breakpoint.c (bpstat_check_breakpoint_conditions): Handle task-specific breakpoints. gdb/testsuite/ 2014-02-26 Pedro Alves <palves@redhat.com> * gdb.ada/tasks.exp: Set a task-specific breakpoint at break_me that won't ever trigger. Make sure that GDB reports the correct breakpoint that caused the stop.
2014-02-26 15:22:33 +01:00
2014-02-26 Pedro Alves <palves@redhat.com>
* gdb.ada/tasks.exp: Set a task-specific breakpoint at break_me
that won't ever trigger. Make sure that GDB reports the correct
breakpoint that caused the stop.
PR gdb/16626 Fix auto-load 7.7 regression, the regression affects any loading from /usr/share/gdb/auto-load . 5b2bf9471f1499bee578fcd60c05afe85794e280 is the first bad commit commit 5b2bf9471f1499bee578fcd60c05afe85794e280 Author: Doug Evans <xdje42@gmail.com> Date: Fri Nov 29 21:29:26 2013 -0800 Move .debug_gdb_script processing to auto-load.c. Simplify handling of auto-loaded objfile scripts. Fedora 20 x86_64 $ gdb -q /usr/lib64/libgobject-2.0.so Reading symbols from /usr/lib64/libglib-2.0.so.0.3800.2...Reading symbols from /usr/lib/debug/usr/lib64/libglib-2.0.so.0.3800.2.debug...done. done. (gdb) _ Fedora Rawhide x86_64 $ gdb -q /usr/lib64/libgobject-2.0.so Reading symbols from /usr/lib64/libglib-2.0.so...Reading symbols from /usr/lib/debug/usr/lib64/libglib-2.0.so.0.3990.0.debug...done. done. warning: File "/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py". To enable execution of this file add add-auto-load-safe-path /usr/lib64/libglib-2.0.so.0.3990.0-gdb.py line to your configuration file "/home/jkratoch/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/jkratoch/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" (gdb) _ That is it tries to load "forbidden" /usr/lib64/libglib-2.0.so.0.3990.0-gdb.py but it should load instead /usr/share/gdb/auto-load/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py* Although that is also not exactly this way, there does not exist any /usr/lib64/libglib-2.0.so.0.3990.0-gdb.py despite regressed GDB says so. gdb/ 2014-02-24 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/16626 * auto-load.c (auto_load_objfile_script_1): Change filename to debugfile. gdb/testsuite/ 2014-02-24 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/16626 * gdb.base/auto-load-script: New file. * gdb.base/auto-load.c: New file. * gdb.base/auto-load.exp: New file. Message-ID: <20140223212400.GA8831@host2.jankratochvil.net>
2014-02-25 18:32:32 +01:00
2014-02-25 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/16626
* gdb.base/auto-load-script: New file.
* gdb.base/auto-load.c: New file.
* gdb.base/auto-load.exp: New file.
PR gdb/16626 gdb/testsuite/ 2014-02-25 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/16626 * gdb.base/auto-load.exp: Fix out-of-srctree run. Message-ID: <87k3cjt3jl.fsf@fleche.redhat.com>
2014-02-25 20:47:09 +01:00
PR gdb/16626
* gdb.base/auto-load.exp: Fix out-of-srctree run.
Fix dw2-icycle.exp -fsanitize=address GDB crash. binutils readelf -wi: <4><a2>: Abbrev Number: 26 (DW_TAG_inlined_subroutine) <a3> DW_AT_abstract_origin: <0x5a> <a7> DW_AT_low_pc : 0x400590 <ab> DW_AT_high_pc : 0x4 <af> DW_AT_call_file : 1 <b0> DW_AT_call_line : 20 <b1> DW_AT_sibling : <0xb8> <2><b8>: Abbrev Number: 35 (DW_TAG_inlined_subroutine) <b9> DW_AT_abstract_origin: <0x5a> <bd> DW_AT_low_pc : 0x400590 <c1> DW_AT_high_pc : 0x4 <c5> DW_AT_call_file : 1 <c6> DW_AT_call_line : 29 <b1> DW_AT_sibling points to the next DIE - but that DIE is 2 levels upwards - definitely not a sibling. This confuses GDB up to a crash: ==32143== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6024000198ac at pc 0xb4d104 bp 0x7fff63e96e70 sp 0x7fff63e96e60 READ of size 1 at 0x6024000198ac thread T0 #0 0xb4d103 in read_unsigned_leb128 (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb4d103) #1 0xb15f3c in peek_die_abbrev (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb15f3c) #2 0xb46185 in load_partial_dies (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb46185) #3 0xb103fb in process_psymtab_comp_unit_reader (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb103fb) #4 0xb0d2a9 in init_cutu_and_read_dies (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb0d2a9) #5 0xb1115f in process_psymtab_comp_unit (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb1115f) #6 0xb1235f in dwarf2_build_psymtabs_hard (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb1235f) #7 0xb05536 in dwarf2_build_psymtabs (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb05536) #8 0x86d5a5 in read_psyms (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x86d5a5) #9 0x9b1c37 in require_partial_symbols (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x9b1c37) #10 0x9bf2d0 in read_symbols (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x9bf2d0) #11 0x9c014c in syms_from_objfile_1 (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x9c014c) gdb/testsuite/ 2014-02-25 Jan Kratochvil <jan.kratochvil@redhat.com> Fix dw2-icycle.exp -fsanitize=address GDB crash. * gdb.dwarf2/dw2-icycle.S: Remove all DW_AT_sibling. Message-ID: <20140224201011.GA28926@host2.jankratochvil.net>
2014-02-25 18:28:38 +01:00
2014-02-25 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix dw2-icycle.exp -fsanitize=address GDB crash.
* gdb.dwarf2/dw2-icycle.S: Remove all DW_AT_sibling.
lib/gdb.exp (run_on_host): Log error output if program fails.
2014-02-24 22:39:14 +01:00
2014-02-24 Doug Evans <dje@google.com>
* lib/gdb.exp (run_on_host): Log error output if program fails.
Rename test. I realized that the name of this test only made sense when considering the old (never committed) implementation of the fix that came along with the test originally, that forced a schedlock while a step-resume (to get over the signal handler) was inserted. The final solution that went into the tree does not force that locking. So this renames it to something more descriptive. gdb/testsuite/ 2014-02-21 Pedro Alves <palves@redhat.com> * gdb.threads/step-after-sr-lock.c: Rename to ... * gdb.threads/signal-while-stepping-over-bp-other-thread.c: ... this. * gdb.threads/step-after-sr-lock.exp: Rename to ... * gdb.threads/signal-while-stepping-over-bp-other-thread.exp: ... this.
2014-02-21 14:30:12 +01:00
2014-02-21 Pedro Alves <palves@redhat.com>
* gdb.threads/step-after-sr-lock.c: Rename to ...
* gdb.threads/signal-while-stepping-over-bp-other-thread.c: ... this.
* gdb.threads/step-after-sr-lock.exp: Rename to ...
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp:
... this.
Fix for PR tdep/16397: SystemTap SDT probe support for x86 doesn't work with "triplet operands" This is the continuation of what Joel proposed on: <https://sourceware.org/ml/gdb-patches/2013-12/msg00977.html> Now that I have already submitted and pushed the patch to split i386_stap_parse_special_token into two smaller functions, it is indeed simpler to understand this patch. It occurs because, on x86, triplet displacement operands are allowed (like "-4+8-20(%rbp)"), and the current parser for this expression is buggy. It does not correctly extract the register name from the expression, which leads to incorrect evaluation. The parser was also being very "generous" with the expression, so I included a few more checks to ensure that we're indeed dealing with a triplet displacement operand. This patch also includes testcases for the two different kind of expressions that can be encountered on x86: the triplet displacement (explained above) and the three-argument displacement (as in "(%rbx,%ebx,-8)"). The tests are obviously arch-dependent and are placed under gdb.arch/. Message-ID: <m3mwj1j12v.fsf@redhat.com> URL: <https://sourceware.org/ml/gdb-patches/2014-01/msg00310.html> gdb/ 2014-02-20 Sergio Durigan Junior <sergiodj@redhat.com> PR tdep/16397 * i386-tdep.c (i386_stap_parse_special_token_triplet): Check if a number comes after the + or - signs. Adjust length of register name to be extracted. gdb/testsuite/ 2014-02-20 Sergio Durigan Junior <sergiodj@redhat.com> PR tdep/16397 * gdb.arch/amd64-stap-special-operands.exp: New file. * gdb.arch/amd64-stap-three-arg-disp.S: Likewise. * gdb.arch/amd64-stap-three-arg-disp.c: Likewise. * gdb.arch/amd64-stap-triplet.S: Likewise. * gdb.arch/amd64-stap-triplet.c: Likewise.
2014-02-20 22:49:09 +01:00
2014-02-20 Sergio Durigan Junior <sergiodj@redhat.com>
PR tdep/16397
* gdb.arch/amd64-stap-special-operands.exp: New file.
* gdb.arch/amd64-stap-three-arg-disp.S: Likewise.
* gdb.arch/amd64-stap-three-arg-disp.c: Likewise.
* gdb.arch/amd64-stap-triplet.S: Likewise.
* gdb.arch/amd64-stap-triplet.c: Likewise.
Simplify .section in dw2-icycle.S The arm-elf assembler chokes on the extra parameters in the .section pseudo-op, so this patch removes them. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-icycle.S: Remove second and third parameters in .section pseudo-op.
2014-02-20 18:34:45 +01:00
2014-02-20 Joel Brobecker <brobecker@adacore.com>
* gdb.dwarf2/dw2-icycle.S: Remove second and third parameters
in .section pseudo-op.
Fix PR symtab/16581 * dwarf2read.c (struct die_info): New member in_process. (reset_die_in_process): New function. (process_die): Set it at the start, reset when returning. (inherit_abstract_dies): Only call process_die if origin_child_die not already being processed. testsuite/ * gdb.dwarf2/dw2-icycle.S: New file. * gdb.dwarf2/dw2-icycle.c: New file. * gdb.dwarf2/dw2-icycle.exp: New file.
2014-02-20 18:13:53 +01:00
2014-02-20 lin zuojian <manjian2006@gmail.com>
Joel Brobecker <brobecker@adacore.com>
Doug Evans <xdje42@gmail.com>
PR symtab/16581
* gdb.dwarf2/dw2-icycle.S: New file.
* gdb.dwarf2/dw2-icycle.c: New file.
* gdb.dwarf2/dw2-icycle.exp: New file.
Call overloaded operators to perform operations on gdb.Value objects. * NEWS: Add entry for the new feature * python/py-value.c (valpy_binop): Call value_x_binop for struct and class values. testsuite/ * gdb.python/py-value-cc.cc: Improve test case to enable testing operations on gdb.Value objects. * gdb.python/py-value-cc.exp: Add new test to test operations on gdb.Value objects. doc/ * python.texi (Values From Inferior): Add description about the new feature.
2013-12-02 15:45:09 +01:00
2014-02-19 Siva Chandra Reddy <sivachandra@google.com>
* gdb.python/py-value-cc.cc: Improve test case to enable testing
operations on gdb.Value objects.
* gdb.python/py-value-cc.exp: Add new test to test operations on
gdb.Value objects.
New TESTS variable to run a subset of tests in parallel. * Makefile.in (TESTS): New variable. (expanded_tests, expanded_tests_or_none): New variables (check-single): Pass $(expanded_tests_or_none) to runtest. (check-parallel): Only run tests in $(TESTS) if non-empty. (check/no-matching-tests-found): New rule. * README: Document TESTS makefile variable.
2014-02-19 01:11:02 +01:00
2014-02-18 Doug Evans <dje@google.com>
* Makefile.in (TESTS): New variable.
(expanded_tests, expanded_tests_or_none): New variables
(check-single): Pass $(expanded_tests_or_none) to runtest.
(check-parallel): Only run tests in $(TESTS) if non-empty.
(check/no-matching-tests-found): New rule.
* README: Document TESTS makefile variable.
* Makefile.in (check-parallel): rm -rf outputs temp.
2014-02-19 01:01:34 +01:00
2014-02-18 Doug Evans <dje@google.com>
* Makefile.in (check-parallel): rm -rf outputs temp.
Fix "ERROR: no fileid for" in the testsuite. If GDB has crashed then gdb_spawn_id still exists (although it does not work). So my patch does not change anything. And also currently it will leave the stale gdbserver running anyway. In general if gdb_spawn_id does not exist then send_gdb + gdb_expect just do not make sense anyway. So this patch just prevents the error in such case. The killing of stale gdbserver could be improved multiple ways (also as suggested by Pedro in the original thread) but that is IMO outside of the scope of this patch. Apparently if there is no good response from GDB then gdb_finish() should try to call gdb_start just to kill that gdbserver, IIUC. gdb/testsuite/ 2014-02-16 Jan Kratochvil <jan.kratochvil@redhat.com> Fix "ERROR: no fileid for" in the testsuite. * lib/gdb.exp (gdb_finish): Check gdb_spawn_id. Message-ID: <20140206205814.GA18495@host2.jankratochvil.net>
2014-02-16 21:49:40 +01:00
2014-02-16 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix "ERROR: no fileid for" in the testsuite.
* lib/gdb.exp (gdb_finish): Check gdb_spawn_id.
Test for binary,dwp symlinks into different directories. * gdb.dwarf2/Makefile.in (EXECUTABLES): Add dwp-symlink. (MISCELLANEOUS): New variable. (clean): rm -rf $(MISCELLANEOUS). * gdb.dwarf2/dwp-symlink.exp: Test the case where the executable and dwp live in the same directory as symlinks, with each symlink pointed to a differently named file in a different directory.
2014-02-12 20:38:48 +01:00
2014-02-12 Doug Evans <dje@google.com>
* gdb.dwarf2/Makefile.in (EXECUTABLES): Add dwp-symlink.
(MISCELLANEOUS): New variable.
(clean): rm -rf $(MISCELLANEOUS).
* gdb.dwarf2/dwp-symlink.exp: Test the case where the executable and
dwp live in the same directory as symlinks, with each symlink pointed
to a differently named file in a different directory.
* gdb.dwarf2/dwp-symlink.exp: Rewrite to use remote_* commands instead of Tcl file commands.
2014-02-12 00:47:50 +01:00
2014-02-11 Doug Evans <dje@google.com>
* gdb.dwarf2/dwp-symlink.exp: Rewrite to use remote_* commands instead
of Tcl file commands.
Avoid killing all processes. gdb/ChangeLog: * gdb.threads/step-after-sr-lock.exp: Avoid executing "kill -SIGUSR1 -1".
2014-02-10 17:58:03 +01:00
2014-02-10 Mark Kettenis <kettenis@gnu.org>
* gdb.threads/step-after-sr-lock.exp: Avoid executing
"kill -SIGUSR1 -1".
Wrong type for 'Length result. Consider the following code: type Color is (Black, Red, Green, Blue, White); type Primary_Table is array (Color range Red .. Blue) of Boolean; Prim : Primary_Table := (True, False, False); GDB prints the length of arrays in a fairly odd way: (gdb) p prim'length $2 = blue The length returned should be an integer, not the array index type, and this patch fixes this. gdb/ChangeLog: * ada-lang.c (ada_evaluate_subexp): Set the type of the value returned by the 'Length attribute to integer. testsuite/ChangeLog: * gdb.ada/tick_length_array_enum_idx: New testcase.
2014-02-07 05:44:20 +01:00
2014-02-10 Joel Brobecker <brobecker@adacore.com>
* gdb.ada/tick_length_array_enum_idx: New testcase.
Add Guile as an extension language. * NEWS: Mention Guile scripting. * Makefile.in (SUBDIR_GUILE_OBS): New variable. (SUBDIR_GUILE_SRCS, SUBDIR_GUILE_DEPS): New variables (SUBDIR_GUILE_LDFLAGS, SUBDIR_GUILE_CFLAGS): New variables. (INTERNAL_CPPFLAGS): Add GUILE_CPPFLAGS. (CLIBS): Add GUILE_LIBS. (install-guile): New rule. (guile.o): New rule. (scm-arch.o, scm-auto-load.o, scm-block.o): New rules. (scm-breakpoint.o, scm-disasm.o, scm-exception.o): New rules. (scm-frame.o, scm-iterator.o, scm-lazy-string.o): New rules. (scm-math.o, scm-objfile.o, scm-ports.o): New rules. (scm-pretty-print.o, scm-safe-call.o, scm-gsmob.o): New rules. (scm-string.o, scm-symbol.o, scm-symtab.o): New rules. (scm-type.o, scm-utils.o, scm-value.o): New rules. * configure.ac: New option --with-guile. * configure: Regenerate. * config.in: Regenerate. * auto-load.c: Remove #include "python/python.h". Add #include "gdb/section-scripts.h". (source_section_scripts): Handle Guile scripts. (_initialize_auto_load): Add name of Guile objfile script to scripts-directory help text. * breakpoint.c (condition_command): Tweak comment to include Scheme. * breakpoint.h (gdbscm_breakpoint_object): Add forward decl. (struct breakpoint): New member scm_bp_object. * defs.h (enum command_control_type): New value guile_control. * cli/cli-cmds.c: Remove #include "python/python.h". Add #include "extension.h". (show_user): Update comment. (_initialize_cli_cmds): Update help text for "show user". Update help text for max-user-call-depth. * cli/cli-script.c: Remove #include "python/python.h". Add #include "extension.h". (multi_line_command_p): Add guile_control. (print_command_lines): Handle guile_control. (execute_control_command, recurse_read_control_structure): Ditto. (process_next_line): Recognize "guile" commands. * disasm.c (gdb_disassemble_info): Make non-static. * disasm.h: #include "dis-asm.h". (struct gdbarch): Add forward decl. (gdb_disassemble_info): Declare. * extension.c: #include "guile/guile.h". (extension_languages): Add guile. (get_ext_lang_defn): Handle EXT_LANG_GDB. * extension.h (enum extension_language): New value EXT_LANG_GUILE. * gdbtypes.c (get_unsigned_type_max): New function. (get_signed_type_minmax): New function. * gdbtypes.h (get_unsigned_type_max): Declare. (get_signed_type_minmax): Declare. * guile/README: New file. * guile/guile-internal.h: New file. * guile/guile.c: New file. * guile/guile.h: New file. * guile/scm-arch.c: New file. * guile/scm-auto-load.c: New file. * guile/scm-block.c: New file. * guile/scm-breakpoint.c: New file. * guile/scm-disasm.c: New file. * guile/scm-exception.c: New file. * guile/scm-frame.c: New file. * guile/scm-gsmob.c: New file. * guile/scm-iterator.c: New file. * guile/scm-lazy-string.c: New file. * guile/scm-math.c: New file. * guile/scm-objfile.c: New file. * guile/scm-ports.c: New file. * guile/scm-pretty-print.c: New file. * guile/scm-safe-call.c: New file. * guile/scm-string.c: New file. * guile/scm-symbol.c: New file. * guile/scm-symtab.c: New file. * guile/scm-type.c: New file. * guile/scm-utils.c: New file. * guile/scm-value.c: New file. * guile/lib/gdb.scm: New file. * guile/lib/gdb/boot.scm: New file. * guile/lib/gdb/experimental.scm: New file. * guile/lib/gdb/init.scm: New file. * guile/lib/gdb/iterator.scm: New file. * guile/lib/gdb/printing.scm: New file. * guile/lib/gdb/types.scm: New file. * data-directory/Makefile.in (GUILE_SRCDIR): New variable. (VPATH): Add $(GUILE_SRCDIR). (GUILE_DIR): New variable. (GUILE_INSTALL_DIR, GUILE_FILES): New variables. (all): Add stamp-guile dependency. (stamp-guile): New rule. (clean-guile, install-guile, uninstall-guile): New rules. (install-only): Add install-guile dependency. (uninstall): Add uninstall-guile dependency. (clean): Add clean-guile dependency. doc/ * Makefile.in (GDB_DOC_FILES): Add guile.texi. * gdb.texinfo (Auto-loading): Add set/show auto-load guile-scripts. (Extending GDB): New menu entries Guile, Multiple Extension Languages. (Guile docs): Include guile.texi. (objfile-gdbdotext file): Add objfile-gdb.scm. (dotdebug_gdb_scripts section): Mention Guile scripts. (Multiple Extension Languages): New node. * guile.texi: New file. testsuite/ * configure.ac (AC_OUTPUT): Add gdb.guile. * configure: Regenerate. * lib/gdb-guile.exp: New file. * lib/gdb.exp (get_target_charset): New function. * gdb.base/help.exp: Update expected output from "apropos apropos". * gdb.guile/Makefile.in: New file. * gdb.guile/guile.exp: New file. * gdb.guile/scm-arch.c: New file. * gdb.guile/scm-arch.exp: New file. * gdb.guile/scm-block.c: New file. * gdb.guile/scm-block.exp: New file. * gdb.guile/scm-breakpoint.c: New file. * gdb.guile/scm-breakpoint.exp: New file. * gdb.guile/scm-disasm.c: New file. * gdb.guile/scm-disasm.exp: New file. * gdb.guile/scm-equal.c: New file. * gdb.guile/scm-equal.exp: New file. * gdb.guile/scm-error.exp: New file. * gdb.guile/scm-error.scm: New file. * gdb.guile/scm-frame-args.c: New file. * gdb.guile/scm-frame-args.exp: New file. * gdb.guile/scm-frame-args.scm: New file. * gdb.guile/scm-frame-inline.c: New file. * gdb.guile/scm-frame-inline.exp: New file. * gdb.guile/scm-frame.c: New file. * gdb.guile/scm-frame.exp: New file. * gdb.guile/scm-generics.exp: New file. * gdb.guile/scm-gsmob.exp: New file. * gdb.guile/scm-iterator.c: New file. * gdb.guile/scm-iterator.exp: New file. * gdb.guile/scm-math.c: New file. * gdb.guile/scm-math.exp: New file. * gdb.guile/scm-objfile-script-gdb.in: New file. * gdb.guile/scm-objfile-script.c: New file. * gdb.guile/scm-objfile-script.exp: New file. * gdb.guile/scm-objfile.c: New file. * gdb.guile/scm-objfile.exp: New file. * gdb.guile/scm-ports.exp: New file. * gdb.guile/scm-pretty-print.c: New file. * gdb.guile/scm-pretty-print.exp: New file. * gdb.guile/scm-pretty-print.scm: New file. * gdb.guile/scm-section-script.c: New file. * gdb.guile/scm-section-script.exp: New file. * gdb.guile/scm-section-script.scm: New file. * gdb.guile/scm-symbol.c: New file. * gdb.guile/scm-symbol.exp: New file. * gdb.guile/scm-symtab-2.c: New file. * gdb.guile/scm-symtab.c: New file. * gdb.guile/scm-symtab.exp: New file. * gdb.guile/scm-type.c: New file. * gdb.guile/scm-type.exp: New file. * gdb.guile/scm-value-cc.cc: New file. * gdb.guile/scm-value-cc.exp: New file. * gdb.guile/scm-value.c: New file. * gdb.guile/scm-value.exp: New file. * gdb.guile/source2.scm: New file. * gdb.guile/types-module.cc: New file. * gdb.guile/types-module.exp: New file.
2014-02-10 04:40:01 +01:00
2014-02-10 Doug Evans <xdje42@gmail.com>
* configure.ac (AC_OUTPUT): Add gdb.guile.
* configure: Regenerate.
* lib/gdb-guile.exp: New file.
* lib/gdb.exp (get_target_charset): New function.
* gdb.base/help.exp: Update expected output from "apropos apropos".
* gdb.guile/Makefile.in: New file.
* gdb.guile/guile.exp: New file.
* gdb.guile/scm-arch.c: New file.
* gdb.guile/scm-arch.exp: New file.
* gdb.guile/scm-block.c: New file.
* gdb.guile/scm-block.exp: New file.
* gdb.guile/scm-breakpoint.c: New file.
* gdb.guile/scm-breakpoint.exp: New file.
* gdb.guile/scm-disasm.c: New file.
* gdb.guile/scm-disasm.exp: New file.
* gdb.guile/scm-equal.c: New file.
* gdb.guile/scm-equal.exp: New file.
* gdb.guile/scm-error.exp: New file.
* gdb.guile/scm-error.scm: New file.
* gdb.guile/scm-frame-args.c: New file.
* gdb.guile/scm-frame-args.exp: New file.
* gdb.guile/scm-frame-args.scm: New file.
* gdb.guile/scm-frame-inline.c: New file.
* gdb.guile/scm-frame-inline.exp: New file.
* gdb.guile/scm-frame.c: New file.
* gdb.guile/scm-frame.exp: New file.
* gdb.guile/scm-generics.exp: New file.
* gdb.guile/scm-gsmob.exp: New file.
* gdb.guile/scm-iterator.c: New file.
* gdb.guile/scm-iterator.exp: New file.
* gdb.guile/scm-math.c: New file.
* gdb.guile/scm-math.exp: New file.
* gdb.guile/scm-objfile-script-gdb.in: New file.
* gdb.guile/scm-objfile-script.c: New file.
* gdb.guile/scm-objfile-script.exp: New file.
* gdb.guile/scm-objfile.c: New file.
* gdb.guile/scm-objfile.exp: New file.
* gdb.guile/scm-ports.exp: New file.
* gdb.guile/scm-pretty-print.c: New file.
* gdb.guile/scm-pretty-print.exp: New file.
* gdb.guile/scm-pretty-print.scm: New file.
* gdb.guile/scm-section-script.c: New file.
* gdb.guile/scm-section-script.exp: New file.
* gdb.guile/scm-section-script.scm: New file.
* gdb.guile/scm-symbol.c: New file.
* gdb.guile/scm-symbol.exp: New file.
* gdb.guile/scm-symtab-2.c: New file.
* gdb.guile/scm-symtab.c: New file.
* gdb.guile/scm-symtab.exp: New file.
* gdb.guile/scm-type.c: New file.
* gdb.guile/scm-type.exp: New file.
* gdb.guile/scm-value-cc.cc: New file.
* gdb.guile/scm-value-cc.exp: New file.
* gdb.guile/scm-value.c: New file.
* gdb.guile/scm-value.exp: New file.
* gdb.guile/source2.scm: New file.
* gdb.guile/types-module.cc: New file.
* gdb.guile/types-module.exp: New file.
Fix PR16543 Tests in gdb.gdb fail because directory gdb/testsuite/gdb.gdb doesn't exist in build tree. This patch appends gdb.gdb/Makefile in AC_OUTPUT, and adds new Makefile.in in gdb.gdb, so that directory gdb.gdb can be created during configure. With this patch applied, tests under gdb.gdb can be run, $ make check RUNTESTFLAGS='--directory=gdb.gdb' Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using ../../../../git/gdb/testsuite/config/unix.exp as tool-and-target-specific interface file. Running ../../../../git/gdb/testsuite/gdb.gdb/complaints.exp ... Running ../../../../git/gdb/testsuite/gdb.gdb/observer.exp ... Running ../../../../git/gdb/testsuite/gdb.gdb/python-interrupts.exp ... FAIL: gdb.gdb/python-interrupts.exp: signal SIGINT Running ../../../../git/gdb/testsuite/gdb.gdb/python-selftest.exp ... FAIL: gdb.gdb/python-selftest.exp: call catch_command_errors(execute_command, "python print 5", 0, RETURN_MASK_ALL) Running ../../../../git/gdb/testsuite/gdb.gdb/selftest.exp ... Running ../../../../git/gdb/testsuite/gdb.gdb/xfullpath.exp ... === gdb Summary === gdb/testsuite: 2014-02-10 Yao Qi <yao@codesourcery.com> PR testsuite/16543 * configure.ac: Append gdb.gdb/Makefile in AC_OUTPUT. * configure: Regenerated. * Makefile.in: New file.
2014-02-08 13:54:57 +01:00
2014-02-10 Yao Qi <yao@codesourcery.com>
PR testsuite/16543
* configure.ac: Append gdb.gdb/Makefile in AC_OUTPUT.
* configure: Regenerated.
* Makefile.in: New file.
Fix typo in test name * gdb.python/py-framefilter.exp: Fix typo.
2014-02-08 10:43:24 +01:00
2014-02-08 Andreas Schwab <schwab@linux-m68k.org>
* gdb.python/py-framefilter.exp: Fix typo.
Test no =breakpoint-modified is emitted for modifications from MI commands As design, =breakpoint-modified isn't emitted when breakpoints are modified by MI commands. This patch is to add tests for this. gdb/testsuite: 2014-02-08 Yao Qi <yao@codesourcery.com> * gdb.mi/mi-breakpoint-changed.exp (test_insert_delete_modify): Test that no =breakpoint-modified is emitted when breakpoints are modified through MI commands.
2014-01-24 04:05:06 +01:00
2014-02-08 Yao Qi <yao@codesourcery.com>
* gdb.mi/mi-breakpoint-changed.exp (test_insert_delete_modify): Test
that no =breakpoint-modified is emitted when breakpoints are
modified through MI commands.
Make sure we don't resume the stepped thread by accident. Say: <stopped at a breakpoint in thread 2> (gdb) thread 3 (gdb) step The above triggers the prepare_to_proceed/deferred_step_ptid process, which switches back to thread 2, to step over its breakpoint before getting back to thread 3 and "step" it. If while stepping over the breakpoint in thread 2, a signal arrives, and it is set to pass/nostop, we'll set a step-resume breakpoint at the supposed signal-handler resume address, and call keep_going. The problem is that we were supposedly stepping thread 3, and that keep_going delivers a signal to thread 2, and due to scheduler-locking off, resumes everything else, _including_ thread 3, the thread we want stepping. This means that we lose control of thread 3 until the next event, when we stop everything. The end result for the user, is that GDB lost control of the "step". Here's the current infrun debug output of the above, with the testcase in the patch below: infrun: clear_proceed_status_thread (Thread 0x2aaaab8f5700 (LWP 11663)) infrun: clear_proceed_status_thread (Thread 0x2aaaab6f4700 (LWP 11662)) infrun: clear_proceed_status_thread (Thread 0x2aaaab4f2b20 (LWP 11659)) infrun: proceed (addr=0xffffffffffffffff, signal=144, step=1) infrun: prepare_to_proceed (step=1), switched to [Thread 0x2aaaab6f4700 (LWP 11662)] infrun: resume (step=1, signal=0), trap_expected=1, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f infrun: wait_for_inferior () infrun: target_wait (-1, status) = infrun: 11659 [Thread 0x2aaaab6f4700 (LWP 11662)], infrun: status->kind = stopped, signal = SIGUSR1 infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x40098f infrun: random signal 30 Program received signal SIGUSR1, User defined signal 1. infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x40098f infrun: resume (step=0, signal=30), trap_expected=0, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f ^^^ this is a wildcard resume. infrun: prepare_to_wait infrun: target_wait (-1, status) = infrun: 11659 [Thread 0x2aaaab6f4700 (LWP 11662)], infrun: status->kind = stopped, signal = SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x40098f infrun: BPSTAT_WHAT_STEP_RESUME infrun: resume (step=1, signal=0), trap_expected=1, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f ^^^ step-resume hit, meaning the handler returned, so we go back to stepping thread 3. infrun: prepare_to_wait infrun: target_wait (-1, status) = infrun: 11659 [Thread 0x2aaaab6f4700 (LWP 11662)], infrun: status->kind = stopped, signal = SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x40088b infrun: switching back to stepped thread infrun: Switching context from Thread 0x2aaaab6f4700 (LWP 11662) to Thread 0x2aaaab8f5700 (LWP 11663) infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x2aaaab8f5700 (LWP 11663)] at 0x400938 infrun: prepare_to_wait infrun: target_wait (-1, status) = infrun: 11659 [Thread 0x2aaaab8f5700 (LWP 11663)], infrun: status->kind = stopped, signal = SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x40093a infrun: keep going infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x2aaaab8f5700 (LWP 11663)] at 0x40093a infrun: prepare_to_wait infrun: target_wait (-1, status) = infrun: 11659 [Thread 0x2aaaab8f5700 (LWP 11663)], infrun: status->kind = stopped, signal = SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x40091e infrun: stepped to a different line infrun: stop_stepping [Switching to Thread 0x2aaaab8f5700 (LWP 11663)] 69 (*myp) ++; /* set breakpoint child_two here */ ^^^ we stopped at the wrong line. We still stepped a bit because the test is running in a loop, and when we got back to stepping thread 3, it happened to be in the stepping range. (The loop increments a counter, and the test makes sure it increments exactly once. Without the fix, the counter increments a bunch, since the user-stepped thread runs free without GDB noticing.) The fix is to switch to the stepping thread before continuing for the step-resume breakpoint. gdb/ 2014-02-07 Pedro Alves <palves@redhat.com> * infrun.c (handle_signal_stop) <signal arrives while stepping over a breakpoint>: Switch back to the stepping thread. gdb/testsuite/ 2014-02-07 Pedro Alves <pedro@codesourcery.com> Pedro Alves <palves@redhat.com> * gdb.threads/step-after-sr-lock.c: New file. * gdb.threads/step-after-sr-lock.exp: New file.
2014-02-07 20:11:25 +01:00
2014-02-07 Pedro Alves <pedro@codesourcery.com>
Pedro Alves <palves@redhat.com>
* gdb.threads/step-after-sr-lock.c: New file.
* gdb.threads/step-after-sr-lock.exp: New file.
Fix gdb.threads/stepi-random-signal.exp on software single-step targets. Currently on software single-step Linux targets we get: (gdb) PASS: gdb.threads/stepi-random-signal.exp: before stepi: get hexadecimal valueof "$pc" stepi infrun: clear_proceed_status_thread (Thread 0x7ffff7fca700 (LWP 7073)) infrun: clear_proceed_status_thread (Thread 0x7ffff7fcb740 (LWP 7069)) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 7069)] at 0x400700 infrun: wait_for_inferior () infrun: target_wait (-1, status) = infrun: 7069 [Thread 0x7ffff7fcb740 (LWP 7069)], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400704 infrun: software single step trap for Thread 0x7ffff7fcb740 (LWP 7069) infrun: stepi/nexti infrun: stop_stepping 44 while (counter != 0) (gdb) FAIL: gdb.threads/stepi-random-signal.exp: stepi (no random signal) Vs hardware-step targets: (gdb) PASS: gdb.threads/stepi-random-signal.exp: before stepi: get hexadecimal valueof "$pc" stepi infrun: clear_proceed_status_thread (Thread 0x7ffff7fca700 (LWP 9565)) infrun: clear_proceed_status_thread (Thread 0x7ffff7fcb740 (LWP 9561)) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 9561)] at 0x400700 infrun: wait_for_inferior () infrun: target_wait (-1, status) = infrun: 9561 [Thread 0x7ffff7fcb740 (LWP 9561)], infrun: status->kind = stopped, signal = GDB_SIGNAL_CHLD infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400700 infrun: random signal (GDB_SIGNAL_CHLD) infrun: random signal, keep going infrun: resume (step=1, signal=GDB_SIGNAL_CHLD), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 9561)] at 0x400700 infrun: prepare_to_wait infrun: target_wait (-1, status) = infrun: 9561 [Thread 0x7ffff7fcb740 (LWP 9561)], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400704 infrun: stepi/nexti infrun: stop_stepping 44 while (counter != 0) (gdb) PASS: gdb.threads/stepi-random-signal.exp: stepi The test turns on infrun debug, does a stepi while a SIGCHLD is pending, and checks whether the "random signal" paths in infrun.c are taken. On the software single-step variant above, those paths were not taken. This is a test bug. The Linux backend short-circuits reporting signals that are set to pass/nostop/noprint. But _only_ if the thread is _not_ single-stepping. So on hardware-step targets, even though the signal is set to pass/nostop/noprint by default, the thread is indeed told to single-step, and so the core sees the signal. On the other hand, on software single-step architectures, the backend never actually gets a single-step request (steps are emulated by setting a breakpoint at the next pc, and then the target told to continue, not step). So the short-circuiting code triggers and the core doesn't see the signal. The fix is to make the test be sure the target doesn't bypass reporting the signal to the core. Tested on x86_64 Fedora 17, both with and without a series that implements software single-step for x86_64. gdb/testsuite/ 2014-02-07 Pedro Alves <palves@redhat.com> * gdb.threads/stepi-random-signal.exp: Set SIGCHLD to print.
2013-10-30 16:07:07 +01:00
2014-02-07 Pedro Alves <palves@redhat.com>
* gdb.threads/stepi-random-signal.exp: Set SIGCHLD to print.
Fix i386-sse-stack-align.exp regression since GDB_PARALLEL. gdb/testsuite/ 2014-02-06 Jan Kratochvil <jan.kratochvil@redhat.com> Fix i386-sse-stack-align.exp regression since GDB_PARALLEL. * gdb.arch/i386-sse-stack-align.exp: Use standard_output_file.
2014-02-06 23:14:20 +01:00
2014-02-06 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix i386-sse-stack-align.exp regression since GDB_PARALLEL.
* gdb.arch/i386-sse-stack-align.exp: Use standard_output_file.
Extension Language API * configure.ac (libpython checking): Remove all but python.o from CONFIG_OBS. Remove all but python.c from CONFIG_SRCS. * configure: Regenerate. * Makefile.in (SFILES): Add extension.c. (HFILES_NO_SRCDIR): Add extension.h, extension-priv.h (COMMON_OBS): Add extension.o. * extension.h: New file. * extension-priv.h: New file. * extension.c: New file. * python/python-internal.h: #include "extension.h". (gdbpy_auto_load_enabled): Declare. (gdbpy_apply_val_pretty_printer): Declare. (gdbpy_apply_frame_filter): Declare. (gdbpy_preserve_values): Declare. (gdbpy_breakpoint_cond_says_stop): Declare. (gdbpy_breakpoint_has_cond): Declare. (void source_python_script_for_objfile): Delete. * python/python.c: #include "extension-priv.h". Delete inclusion of "observer.h". (extension_language_python): Moved here and renamed from script_language_python in py-auto-load.c. Redefined to be of type extension_language_defn. (python_extension_script_ops): New global. (python_extension_ops): New global. (struct python_env): New member previous_active. (restore_python_env): Call restore_active_ext_lang. (ensure_python_env): Call set_active_ext_lang. (gdbpy_clear_quit_flag): Renamed from clear_quit_flag, made static. New arg extlang. (gdbpy_set_quit_flag): Renamed from set_quit_flag, made static. New arg extlang. (gdbpy_check_quit_flag): Renamed from check_quit_flag, made static. New arg extlang. (gdbpy_eval_from_control_command): Renamed from eval_python_from_control_command, made static. New arg extlang. (gdbpy_source_script) Renamed from source_python_script, made static. New arg extlang. (gdbpy_before_prompt_hook): Renamed from before_prompt_hook. Change result to int. New arg extlang. (gdbpy_source_objfile_script): Renamed from source_python_script_for_objfile, made static. New arg extlang. (gdbpy_start_type_printers): Renamed from start_type_printers, made static. New args extlang, extlang_printers. Change result type to "void". (gdbpy_apply_type_printers): Renamed from apply_type_printers, made static. New arg extlang. Rename arg printers to extlang_printers and change type to ext_lang_type_printers *. (gdbpy_free_type_printers): Renamed from free_type_printers, made static. Replace argument arg with extlang, extlang_printers. (!HAVE_PYTHON, eval_python_from_control_command): Delete. (!HAVE_PYTHON, source_python_script): Delete. (!HAVE_PYTHON, gdbpy_should_stop): Delete. (!HAVE_PYTHON, gdbpy_breakpoint_has_py_cond): Delete. (!HAVE_PYTHON, start_type_printers): Delete. (!HAVE_PYTHON, apply_type_printers): Delete. (!HAVE_PYTHON, free_type_printers): Delete. (_initialize_python): Delete call to observer_attach_before_prompt. (finalize_python): Set/restore active extension language. (gdbpy_finish_initialization) Renamed from finish_python_initialization, made static. New arg extlang. (gdbpy_initialized): New function. * python/python.h: #include "extension.h". Delete #include "value.h", "mi/mi-cmds.h". (extension_language_python): Declare. (GDBPY_AUTO_FILE_NAME): Delete. (enum py_bt_status): Moved to extension.h and renamed to ext_lang_bt_status. (enum frame_filter_flags): Moved to extension.h. (enum py_frame_args): Moved to extension.h and renamed to ext_lang_frame_args. (finish_python_initialization): Delete. (eval_python_from_control_command): Delete. (source_python_script): Delete. (apply_val_pretty_printer): Delete. (apply_frame_filter): Delete. (preserve_python_values): Delete. (gdbpy_script_language_defn): Delete. (gdbpy_should_stop, gdbpy_breakpoint_has_py_cond): Delete. (start_type_printers, apply_type_printers, free_type_printers): Delete. * auto-load.c: #include "extension.h". (GDB_AUTO_FILE_NAME): Delete. (auto_load_gdb_scripts_enabled): Make public. New arg extlang. (script_language_gdb): Delete, moved to extension.c and renamed to extension_language_gdb. (source_gdb_script_for_objfile): Delete. (auto_load_pspace_info): New member unsupported_script_warning_printed. (loaded_script): Change type of language member to struct extension_language_defn *. (init_loaded_scripts_info): Initialize unsupported_script_warning_printed. (maybe_add_script): Make static. Change type of language arg to struct extension_language_defn *. (clear_section_scripts): Reset unsupported_script_warning_printed. (auto_load_objfile_script_1): Rewrite to use extension language API. (auto_load_objfile_script): Make public. Remove support-compiled-in and auto-load-enabled checks, moved to auto_load_scripts_for_objfile. (source_section_scripts): Rewrite to use extension language API. (load_auto_scripts_for_objfile): Rewrite to use auto_load_scripts_for_objfile. (collect_matching_scripts_data): Change type of language member to struct extension_language_defn *. (auto_load_info_scripts): Change type of language arg to struct extension_language_defn *. (unsupported_script_warning_print): New function. (script_not_found_warning_print): Make static. (_initialize_auto_load): Rewrite construction of scripts-directory help. * auto-load.h (struct objfile): Add forward decl. (struct script_language): Delete. (struct auto_load_pspace_info): Add forward decl. (struct extension_language_defn): Add forward decl. (maybe_add_script): Delete. (auto_load_objfile_script): Declare. (script_not_found_warning_print): Delete. (auto_load_info_scripts): Update prototype. (auto_load_gdb_scripts_enabled): Declare. * python/py-auto-load.c (gdbpy_auto_load_enabled): Renamed from auto_load_python_scripts_enabled and made public. (script_language_python): Delete, moved to python.c. (gdbpy_script_language_defn): Delete. (info_auto_load_python_scripts): Update to use extension_language_python. * breakpoint.c (condition_command): Replace call to gdbpy_breakpoint_has_py_cond with call to get_breakpoint_cond_ext_lang. (bpstat_check_breakpoint_conditions): Replace call to gdbpy_should_stop with call to breakpoint_ext_lang_cond_says_stop. * python/py-breakpoint.c (gdbpy_breakpoint_cond_says_stop): Renamed from gdbpy_should_stop. Change result type to enum scr_bp_stop. New arg slang. Return SCR_BP_STOP_UNSET if py_bp_object is NULL. (gdbpy_breakpoint_has_cond): Renamed from gdbpy_breakpoint_has_py_cond. New arg slang. (local_setattro): Print name of extension language with existing stop condition. * valprint.c (val_print, value_print): Update to call apply_ext_lang_val_pretty_printer. * cp-valprint.c (cp_print_value): Update call to apply_ext_lang_val_pretty_printer. * python/py-prettyprint.c: Remove #ifdef HAVE_PYTHON. (gdbpy_apply_val_pretty_printer): Renamed from apply_val_pretty_printer. New arg extlang. (!HAVE_PYTHON, apply_val_pretty_printer): Delete. * cli/cli-cmds.c (source_script_from_stream): Rewrite to use extension language API. * cli/cli-script.c (execute_control_command): Update to call eval_ext_lang_from_control_command. * mi/mi-cmd-stack.c (mi_cmd_stack_list_frames): Update to use enum ext_lang_bt_status values. Update call to apply_ext_lang_frame_filter. (mi_cmd_stack_list_locals): Ditto. (mi_cmd_stack_list_args): Ditto. (mi_cmd_stack_list_variables): Ditto. * mi/mi-main.c: Delete #include "python/python-internal.h". Add #include "extension.h". (mi_cmd_list_features): Replace reference to python internal variable gdb_python_initialized with call to ext_lang_initialized_p. * stack.c (backtrace_command_1): Update to use enum ext_lang_bt_status. Update to use enum ext_lang_frame_args. Update to call apply_ext_lang_frame_filter. * python/py-framefilter.c (extract_sym): Update to use enum ext_lang_bt_status. (extract_value, py_print_type, py_print_value): Ditto. (py_print_single_arg, enumerate_args, enumerate_locals): Ditto. (py_mi_print_variables, py_print_locals, py_print_args): Ditto. (py_print_frame): Ditto. (gdbpy_apply_frame_filter): Renamed from apply_frame_filter. New arg extlang. Update to use enum ext_lang_bt_status. * top.c (gdb_init): Delete #ifdef HAVE_PYTHON call to finish_python_initialization. Replace with call to finish_ext_lang_initialization. * typeprint.c (do_free_global_table): Update to call free_ext_lang_type_printers. (create_global_typedef_table): Update to call start_ext_lang_type_printers. (find_global_typedef): Update to call apply_ext_lang_type_printers. * typeprint.h (struct ext_lang_type_printers): Add forward decl. (type_print_options): Change type of global_printers from "void *" to "struct ext_lang_type_printers *". * value.c (preserve_values): Update to call preserve_ext_lang_values. * python/py-value.c: Remove #ifdef HAVE_PYTHON. (gdbpy_preserve_values): Renamed from preserve_python_values. New arg extlang. (!HAVE_PYTHON, preserve_python_values): Delete. * utils.c (quit_flag): Delete, moved to extension.c. (clear_quit_flag, set_quit_flag, check_quit_flag): Delete, moved to extension.c. * eval.c: Delete #include "python/python.h". * main.c: Delete #include "python/python.h". * defs.h: Update comment. testsuite/ * gdb.python/py-breakpoint.exp (test_bkpt_eval_funcs): Update expected output. * gdb.gdb/python-interrupts.exp: New file.
2014-02-06 04:27:58 +01:00
2014-02-06 Doug Evans <xdje42@gmail.com>
* gdb.python/py-breakpoint.exp (test_bkpt_eval_funcs): Update expected
output.
* gdb.gdb/python-interrupts.exp: New file.
Create inferior for ctf target. This patch creates inferior when GDB opens a ctf trace data, to be consistent with tfile target. A test case is added to test for live target, tfile and ctf target. gdb: 2014-02-05 Yao Qi <yao@codesourcery.com> * ctf.c: Include "inferior.h" and "gdbthread.h". (CTF_PID): A new macro. (ctf_open): Call inferior_appeared and add_thread_silent. (ctf_close): Call exit_inferior_silent and set inferior_ptid. (ctf_thread_alive): New function. (init_ctf_ops): Install ctf_thread_alive to to_thread_alive. gdb/testsuite: 2014-02-05 Yao Qi <yao@codesourcery.com> * gdb.trace/report.exp (use_collected_data): Test the output of "info threads" and "info inferiors".
2014-01-30 03:09:11 +01:00
2014-02-05 Yao Qi <yao@codesourcery.com>
* gdb.trace/report.exp (use_collected_data): Test the output
of "info threads" and "info inferiors".
Create inferior for tfile target When a trace file is loaded in Eclipse, it is expected to see thread and process (=thread-group-started and =thread-created). Create an inferior and add a thread for this purpose. This patch just reverts my previous patch. gdb/testsuite: 2014-02-05 Yao Qi <yao@codesourcery.com> Revert this patch: 2013-05-24 Yao Qi <yao@codesourcery.com> * gdb.trace/tfile.exp: Test inferior and thread. gdb: 2014-02-05 Yao Qi <yao@codesourcery.com> Revert this patch: 2013-05-24 Yao Qi <yao@codesourcery.com> * tracepoint.c (TFILE_PID): Remove. (tfile_open): Don't add thread and inferior. (tfile_close): Don't set 'inferior_ptid'. Don't call exit_inferior_silent. (tfile_thread_alive): Remove. (init_tfile_ops): Don't set field 'to_thread_alive' of tfile_ops.
2014-01-30 01:37:05 +01:00
2014-02-05 Yao Qi <yao@codesourcery.com>
Revert this patch:
2013-05-24 Yao Qi <yao@codesourcery.com>
* gdb.trace/tfile.exp: Test inferior and thread.
PowerPC64 ELFv2 ABI: skip global entry point code This patch handles another aspect of the ELFv2 ABI, which unfortunately requires common code changes. In ELFv2, functions may provide both a global and a local entry point. The global entry point (where the function symbol points to) is intended to be used for function-pointer or cross-module (PLT) calls, and requires r12 to be set up to the entry point address itself. The local entry point (which is found at a fixed offset after the global entry point, as defined by bits in the symbol table entries' st_other field), instead expects r2 to be set up to the current TOC. Now, when setting a breakpoint on a function by name, you really want that breakpoint to trigger either way, no matter whether the function is called via its local or global entry point. Since the global entry point will always fall through into the local entry point, the way to achieve that is to simply set the breakpoint at the local entry point. One way to do that would be to have prologue parsing skip the code sequence that makes up the global entry point. Unfortunately, this does not work reliably, since -for optimized code- GDB these days will not actuall invoke the prologue parsing code but instead just set the breakpoint at the symbol address and rely on DWARF being correct at any point throughout the function ... Unfortunately, I don't really see any way to express the notion of local entry points with the current set of gdbarch callbacks. Thus this patch adds a new callback, skip_entrypoint, that is somewhat analogous to skip_prologue, but is called every time GDB needs to determine a function start address, even in those cases where GDB decides to not call skip_prologue. As a side effect, the skip_entrypoint implementation on ppc64 does not need to perform any instruction parsing; it can simply rely on the local entry point flags in the symbol table entry. With this implemented, two test cases would still fail to set the breakpoint correctly, but that's because they use the construct: gdb_test "break *hello" Now, using "*hello" explicitly instructs GDB to set the breakpoint at the numerical value of "hello" treated as function pointer, so it will by definition only hit the global entry point. I think this behaviour is unavoidable, but acceptable -- most people do not use this construct, and if they do, they get what they asked for ... In one of those two test cases, use of this construct is really not appropriate. I think this was added way back when as a means to work around prologue skipping problems on some platforms. These days that shouldn't really be necessary any more ... For the other (step-bt), we really want to make sure backtracing works on the very first instruction of the routine. To enable that test also on powerpc64le-linux, we can modify the code to call the test function via function pointer (which makes it use the global entry point in the ELFv2 ABI). gdb/ChangeLog: * gdbarch.sh (skip_entrypoint): New callback. * gdbarch.c, gdbarch.h: Regenerate. * symtab.c (skip_prologue_sal): Call gdbarch_skip_entrypoint. * infrun.c (fill_in_stop_func): Likewise. * ppc-linux-tdep.c: Include "elf/ppc64.h". (ppc_elfv2_elf_make_msymbol_special): New function. (ppc_elfv2_skip_entrypoint): Likewise. (ppc_linux_init_abi): Install them for ELFv2. gdb/testsuite/ChangeLog: * gdb.base/sigbpt.exp: Do not use "*" when setting breakpoint on a function. * gdb.base/step-bt.c: Call hello via function pointer to make sure its first instruction is executed on powerpc64le-linux.
2014-02-04 18:44:14 +01:00
2014-02-04 Ulrich Weigand <uweigand@de.ibm.com>
* gdb.base/sigbpt.exp: Do not use "*" when setting breakpoint
on a function.
* gdb.base/step-bt.c: Call hello via function pointer to make
sure its first instruction is executed on powerpc64le-linux.
PowerPC64 little-endian fixes: 128-bit DFP parameters / registers The powerpc64le-linux ABI specifies that when a 128-bit DFP value is passed in a pair of floating-point registers, the first register holds the most-significant part of the value. This is as opposed to the usual rule on little-endian systems, where the first register would hold the least-significant part. This affects two places in GDB, the read/write routines for the 128-bit DFP pseudo-registers, and the function call / return sequence. For the former, current code already distinguishes between big- and little-endian targets, but gets the latter wrong. This is presumably because *GCC* also got it wrong, and GDB matches the old GCC behavior. But GCC is now fixed: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02145.html so GDB needs to be fixed too. (Old code shouldn't really be an issue since there is no code "out there" so far that uses dfp128 on little-endian ...) gdb/ChangeLog: * ppc-sysv-tdep.c (ppc64_sysv_abi_push_freg): Use correct order within a register pair holding a DFP 128-bit value on little-endian. (ppc64_sysv_abi_return_value_base): Likewise. * rs6000-tdep.c (dfp_pseudo_register_read): Likewise. (dfp_pseudo_register_write): Likewise. gdb/testsuite/ChangeLog: * gdb.arch/powerpc-d128-regs.exp: Enable on powerpc64*-*.
2014-02-04 18:34:19 +01:00
2014-02-04 Ulrich Weigand <uweigand@de.ibm.com>
* gdb.arch/powerpc-d128-regs.exp: Enable on powerpc64*-*.
PowerPC64 little-endian fixes: VSX tests and pseudo-regs Many VSX test were failing on powerpc64le-linux, since -as opposed to the AltiVec tests- there never were little-endian versions of the test patterns. This patch adds such patterns, along the lines of altivec-regs.exp. In addition, there is an actual code change required: For those VSX registers that overlap a floating-point register, the FP register overlaps the most-significant half of the VSX register both on big- and little-endian systems. However, on little-endian systems, that half is stored at an offset of 8 bytes (not 0). This works already for the "real" FP registers, but current code gets it wrong for the "extended" pseudo FP register GDB generates for the second half of the VSX register bank. This patch updates the corresponding pseudo read/write routines to take the appropriate offset into consideration. gdb/ChangeLog: * rs6000-tdep.c (efpr_pseudo_register_read): Use correct offset of the overlapped FP register within the VSX register on little- endian platforms. (efpr_pseudo_register_write): Likewise. gdb/testsuite/ChangeLog: * gdb.arch/vsx-regs.exp: Check target endianness. Provide variants of the test patterns for use on little-endian systems.
2014-02-04 18:31:38 +01:00
2014-02-04 Ulrich Weigand <uweigand@de.ibm.com>
* gdb.arch/vsx-regs.exp: Check target endianness. Provide variants
of the test patterns for use on little-endian systems.
PowerPC64 little-endian fixes: AltiVec tests A couple of AltiVec tests fail spuriously on powerpc64le-linux, because they compare against an incorrect pattern. Note that those tests already contain little-endian variants of the patterns, but those seem to have bit-rotted a bit: when outputting a vector, GDB no longer omits trailing zero elements (as it used to do in the past). This patch updates the pattern to the new GDB output behavior. In addition, the patch updates the endian test to use the new gdb_test_multiple logic instead of gdb_expect. gdb/testsuite/ChangeLog: * gdb.arch/altivec-regs.exp: Use gdb_test_multiple for endian test. (decimal_vector): Fix for little-endian.
2014-02-04 18:28:24 +01:00
2014-02-04 Ulrich Weigand <uweigand@de.ibm.com>
* gdb.arch/altivec-regs.exp: Use gdb_test_multiple for endian test.
(decimal_vector): Fix for little-endian.
This changeset makes sparc64_linux_step_trap to return 0 when a breakpoint is set in a `ta 0x6d´ which is not a sigreturn syscall. In these cases no rt_frame exists in the stack and thus the read PC is wrong. ChangeLog 2014-01-29 Jose E. Marchesi <jose.marchesi@oracle.com> * sparc64-linux-tdep.c (sparc64_linux_step_trap): Get PC from the sigreturn register save area only if the syscall is sigreturn. testsuite/ChangeLog 2014-01-29 Jose E. Marchesi <jose.marchesi@oracle.com> * gdb.arch/sparc-sysstep.exp: New file. * gdb.arch/sparc-sysstep.c: Likewise. * gdb.arch/Makefile.in (EXECUTABLES): Add sparc-sysstep.
2014-01-29 16:15:05 +01:00
2014-01-29 Jose E. Marchesi <jose.marchesi@oracle.com>
* gdb.arch/sparc-sysstep.exp: New file.
* gdb.arch/sparc-sysstep.c: Likewise.
* gdb.arch/Makefile.in (EXECUTABLES): Add sparc-sysstep.
Fix info-shared.exp testcase to expect the leading `.' found on ppc64's symbols. gdb/testsuite/ 2014-01-28 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com> * gdb.base/info-shared.exp: Expect leading `.' on ppc64's symbols.
2014-01-28 18:31:23 +01:00
2014-01-28 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
* gdb.base/info-shared.exp: Expect leading `.' on ppc64's symbols.
Try printing array range using the name of its index type type Char_Table is array (Character range Character'First .. Character'Last) of Natural; Trying to print the type description of this type currently yields: (gdb) ptype char_table type = array ('["00"]' .. '["ff"]') of natural Although technically correct, it seemed more useful to print the array range as: (gdb) ptype char_table type = array (character) of natural This patch implements this suggestion. gdb/ChangeLog: * ada-typeprint (type_is_full_subrange_of_target_type): New function. (print_range): Add parameter bounds_prefered_p. If not set, try printing range types using the name of their base type. (print_range_type): Add parameter bounds_prefered_p. Use it in call to print_range. (print_array_type, ada_print_type): Update calls to print_range and print_range_type. gdb/testsuite/ChangeLog: * gdb.ada/array_char_idx: New testcase.
2014-01-15 17:00:05 +01:00
2014-01-23 Tom Tromey <tromey@redhat.com>
* gdb.ada/array_char_idx: New testcase.
fix erroneous error-handling in frame filter code This fixes PR python/16487. The bug here is that the function-name-handling code in py_print_frame had a small logic error (really a misplaced closing brace). This error could lead to a Py_DECREF(NULL), which crashes. This patch fixes the bug in the obvious way. Built and regtested on x86-64 Fedora 18. New test case included. 2014-01-23 Tom Tromey <tromey@redhat.com> PR python/16487: * python/py-framefilter.c (py_print_frame): Don't call Py_DECREF on a NULL pointer. Move "goto error" to correct place. 2014-01-23 Tom Tromey <tromey@redhat.com> PR python/16487: * gdb.python/py-framefilter.exp: Add test using "Error" filter. * gdb.python/py-framefilter.py (ErrorInName, ErrorFilter): New classes.
2014-01-22 16:44:41 +01:00
2014-01-23 Tom Tromey <tromey@redhat.com>
PR python/16487:
* gdb.python/py-framefilter.exp: Add test using "Error" filter.
* gdb.python/py-framefilter.py (ErrorInName, ErrorFilter): New
classes.
fix crash in frame filters apply_frame_filter calls ensure_python_env before computing the gdbarch to use. This means that python_gdbarch can be NULL while in Python code, and if a frame filter depends on this somehow (easy to do), gdb will crash. The fix is to compute the gdbarch first. Built and regtested on x86-64 Fedora 18. New test case included. 2014-01-23 Tom Tromey <tromey@redhat.com> PR python/16491: * python/py-framefilter.c (apply_frame_filter): Call ensure_python_env after computing gdbarch. 2014-01-23 Tom Tromey <tromey@redhat.com> PR python/16491: * gdb.python/py-framefilter.py (Reverse_Function.function): Read a string from an inferior frame. * gdb.python/py-framefilter-mi.exp: Update.
2014-01-22 16:10:01 +01:00
2014-01-23 Tom Tromey <tromey@redhat.com>
PR python/16491:
* gdb.python/py-framefilter.py (Reverse_Function.function): Read a
string from an inferior frame.
* gdb.python/py-framefilter-mi.exp: Update.
New gdbserver option --debug-format=timestamp. * NEWS: Mention it. gdbserver/ * configure.ac (AC_CHECK_FUNCS): Add test for gettimeofday. * configure: Regenerate. * config.in: Regenerate. * Makefile.in (SFILES): Add debug.c. (OBS): Add debug.o. * debug.c: New file. * debug.h: New file. * linux-aarch64-low.c (*): Update all debugging printfs to use debug_printf instead of fprintf. * linux-arm-low.c (*): Ditto. * linux-cris-low.c (*): Ditto. * linux-crisv32-low.c (*): Ditto. * linux-m32r-low.c (*): Ditto. * linux-sparc-low.c (*): Ditto. * linux-x86.c (*): Ditto. * linux-low.c (*): Ditto. (linux_wait_1): Add calls to debug_enter, debug_exit. (linux_wait): Remove redundant debugging printf. (stop_all_lwps): Add calls to debug_enter, debug_exit. (linux_resume, unstop_all_lwps): Ditto. * mem-break.c (*): Update all debugging printfs to use debug_printf instead of fprintf. * remote-utils.c (*): Ditto. * thread-db.c (*): Ditto. * server.c #include <ctype.h>, "gdb_vecs.h". (debug_threads): Moved to debug.c. (*): Update all debugging printfs to use debug_printf instead of fprintf. (start_inferior): Replace call to fflush with call to debug_flush. (monitor_show_help): Mention set debug-format. (parse_debug_format_options): New function. (handle_monitor_command): Handle "monitor set debug-format". (gdbserver_usage): Mention --debug-format. (main): Parse --debug-format. * server.h (debug_threads): Declaration moved to debug.h. #include "debug.h". * tracepoint.c (trace_debug_1) [!IN_PROCESS_AGENT]: Add version of trace_debug_1 that uses debug_printf. (tracepoint_look_up_symbols): Update all debugging printfs to use debug_printf instead of fprintf. doc/ * gdb.texinfo (Server): Mention --debug-format=all|none|timestamp. (gdbserver man): Ditto. testsuite/ * gdb.server/server-mon.exp: Add tests for "set debug-format".
2014-01-22 23:17:39 +01:00
2014-01-22 Doug Evans <dje@google.com>
* gdb.server/server-mon.exp: Add tests for "set debug-format".
gdb/ChangeLog: * syscalls/s390x-linux.xml: New file. * syscalls/s390-linux.xml: New file. * s390-linux-tdep.c (XML_SYSCALL_FILENAME_S390): New macro. (XML_SYSCALL_FILENAME_S390X): Likewise. (op_svc): New enum value for SVC opcode. (s390_sigtramp_frame_sniffer): Replace literal by 'op_svc'. (s390_linux_get_syscall_number): New function. (s390_gdbarch_init): Register '*get_syscall_number' and the syscall xml file name. * data-directory/Makefile.in (SYSCALLS_FILES): Add "s390-linux.xml" and "s390x-linux.xml". * NEWS: Announce new feature. gdb/testsuite/ChangeLog: * gdb.base/catch-syscall.exp: Activate test on s390*-linux.
2014-01-22 18:54:43 +01:00
2014-01-22 Andreas Arnez <arnez@vnet.linux.ibm.com>
* gdb.base/catch-syscall.exp: Activate test on s390*-linux.
Fix regression on s390x with entry-values.exp. The trace-specific test case 'entry-values' concludes fairly late in the process that this platform doesn't support trace. Before that, there are some platform specifics that don't work on s390x. The fix addresses two aspects: (1) Removal of an excess space character in the regex for the disassembly. This is needed when there is a function alignment gap, because then the hex address is immediately followed by a colon, like in the first 'nopr' line below: (gdb) disassemble foo+50,+10 Dump of assembler code from 0x32 to 0x3c: 0x0000000000000032 <foo+50>: br %r4 0x0000000000000034: nopr %r7 0x0000000000000036: nopr %r7 0x0000000000000038 <bar+0>: stmg %r11,%r15,88(%r15) End of assembler dump. (2) Handling for the s390-specific call instruction. gdb/testsuite/ChangeLog: * gdb.trace/entry-values.exp: Remove excess space character from regex patterns. Handle s390 call instruction.
2014-01-22 16:37:41 +01:00
2014-01-22 Andreas Arnez <arnez@vnet.linux.ibm.com>
* gdb.trace/entry-values.exp: Remove excess space character from
regex patterns. Handle s390 call instruction.
Re-introduce '_start' labels and add alignment in dw2-dir-file-name test case. On ppc64-linux a function symbol does not point to code, but to the function descriptor. Thus the previous change for this test case broke it: https://sourceware.org/ml/gdb-patches/2014-01/msg00275.html This patch reverts to the original method, re-introducing '_start' symbols. In addition, it adds sufficient alignment before the label, such that the label never points into an alignment gap. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-dir-file-name.c (FUNC): Insert alignment and define "*_start" label. Make "name" static. * gdb.dwarf2/dw2-dir-file-name.exp: Replace references to ${name} by references to ${name}_start.
2014-01-22 16:33:00 +01:00
2014-01-22 Andreas Arnez <arnez@vnet.linux.ibm.com>
* gdb.dwarf2/dw2-dir-file-name.c (FUNC): Insert alignment and
define "*_start" label. Make "name" static.
* gdb.dwarf2/dw2-dir-file-name.exp: Replace references to
${name} by references to ${name}_start.
Prevent appending "-g" after "-g3" to compile options in info-macros.exp. When upstream gcc is given a command line with the "-g" option after "-g3", it doesn't generate a ".debug_macro" section. This is because the last option wins, thus downgrading the debug level again. Without any macro debug information in the executable, info-macros.exp obviously produces many failures. Since the "-g" option is appended by DejaGnu's target_compile whenever the "debug" option is set, the fix just removes that option. gdb/testsuite/ChangeLog: * gdb.base/info-macros.exp: Remove "debug" from the compile options.
2014-01-22 16:31:10 +01:00
2014-01-22 Andreas Arnez <arnez@vnet.linux.ibm.com>
* gdb.base/info-macros.exp: Remove "debug" from the compile
options.
Fix and update D demangling support in gdb to the current mangling ABI. gdb/ChangeLog: 2014-01-17 Iain Buclaw <ibuclaw@gdcproject.org> * d-lang.h (d_parse_symbol): Add declaration. * d-lang.c (extract_identifiers) (extract_type_info): Remove functions. (parse_call_convention, parse_attributes) (parse_function_types, parse_function_args) (parse_type, parse_identifier, call_convention_p) (d_parse_symbol): New functions. (d_demangle): Use d_parse_symbol to demangle D symbols. gdb/testsuite/ChangeLog: 2014-01-17 Iain Buclaw <ibuclaw@gdcproject.org> * gdb.dlang/demangle.exp: New file.
2014-01-18 18:22:00 +01:00
2014-01-17 Iain Buclaw <ibuclaw@gdcproject.org>
* gdb.dlang/demangle.exp: New file.
Define all basic data types of D and add them to the primitive type language vector. gdb/ChangeLog: 2014-01-17 Iain Buclaw <ibuclaw@gdcproject.org> * d-lang.h (struct builtin_d_type): New data type. (builtin_d_type): Add declaration. * d-lang.c (d_language_arch_info, build_d_types) (builtin_d_type): New functions. (enum d_primitive_types): New data type. (d_language_defn): Change c_language_arch_info to d_language_arch_info. (d_type_data): New static variable. (_initialize_d_language): Initialize d_type_data. gdb/testsuite/ChangeLog: 2014-01-17 Iain Buclaw <ibuclaw@gdcproject.org> * gdb.dlang/primitive-types.exp: New file.
2014-01-18 18:18:23 +01:00
2014-01-17 Iain Buclaw <ibuclaw@gdcproject.org>
* gdb.dlang/primitive-types.exp: New file.
Add gdb.dlang to the gdb testsuite for the purpose of creating D specific tests. gdb/testsuite/ChangeLog: 2014-01-17 Iain Buclaw <ibuclaw@gdcproject.org> * configure.ac: Create gdb.dlang/Makefile. * configure: Regenerate. * Makefile.in (ALL_SUBDIRS): Add gdb.dlang. * gdb.dlang/Makefile.in: New file. * lib/d-support.exp: New file. * lib/gdb.exp (skip_d_tests): New proc.
2014-01-18 17:04:36 +01:00
2014-01-17 Iain Buclaw <ibuclaw@gdcproject.org>
* configure.ac: Create gdb.dlang/Makefile.
* configure: Regenerate.
* Makefile.in (ALL_SUBDIRS): Add gdb.dlang.
* gdb.dlang/Makefile.in: New file.
* lib/d-support.exp: New file.
* lib/gdb.exp (skip_d_tests): New proc.
record-btrace: add (reverse-)stepping support Provide to_resume and to_wait target methods for the btrace record target to allow reverse stepping and replay support. Replay is limited in the sense that only stepping and source correlation are supported. We do not record data and thus can not show variables. Non-stop mode is not working. Do not allow record-btrace in non-stop mode. 2014-01-16 Markus Metzger <markus.t.metzger@intel.com> * btrace.h (btrace_thread_flag): New. (struct btrace_thread_info) <flags>: New. * record-btrace.c (record_btrace_resume_thread) (record_btrace_find_thread_to_move, btrace_step_no_history) (btrace_step_stopped, record_btrace_start_replaying) (record_btrace_step_thread, record_btrace_decr_pc_after_break) (record_btrace_find_resume_thread): New. (record_btrace_resume, record_btrace_wait): Extend. (record_btrace_can_execute_reverse): New. (record_btrace_open): Fail in non-stop mode. (record_btrace_set_replay): Split into this, ... (record_btrace_stop_replaying): ... this, ... (record_btrace_clear_histories): ... and this. (init_record_btrace_ops): Init to_can_execute_reverse. * NEWS: Announce it. testsuite/ * gdb.btrace/delta.exp: Check reverse stepi. * gdb.btrace/tailcall.exp: Update. Add stepping tests. * gdb.btrace/finish.exp: New. * gdb.btrace/next.exp: New. * gdb.btrace/nexti.exp: New. * gdb.btrace/record_goto.c: Add comments. * gdb.btrace/step.exp: New. * gdb.btrace/stepi.exp: New. * gdb.btrace/multi-thread-step.c: New. * gdb.btrace/multi-thread-step.exp: New. * gdb.btrace/rn-dl-bind.c: New. * gdb.btrace/rn-dl-bind.exp: New. * gdb.btrace/data.c: New. * gdb.btrace/data.exp: New. * gdb.btrace/Makefile.in (EXECUTABLES): Add new. doc/ * gdb.texinfo: Document limited reverse/replay support for target record-btrace.
2013-05-06 16:04:46 +02:00
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/delta.exp: Check reverse stepi.
* gdb.btrace/tailcall.exp: Update. Add stepping tests.
* gdb.btrace/finish.exp: New.
* gdb.btrace/next.exp: New.
* gdb.btrace/nexti.exp: New.
* gdb.btrace/record_goto.c: Add comments.
* gdb.btrace/step.exp: New.
* gdb.btrace/stepi.exp: New.
* gdb.btrace/multi-thread-step.c: New.
* gdb.btrace/multi-thread-step.exp: New.
* gdb.btrace/rn-dl-bind.c: New.
* gdb.btrace/rn-dl-bind.exp: New.
* gdb.btrace/data.c: New.
* gdb.btrace/data.exp: New.
* gdb.btrace/Makefile.in (EXECUTABLES): Add new.
record-btrace: show trace from enable location The btrace record target shows the branch trace from the location of the first branch destination. This is the first BTS records. After adding incremental updates, we can now add a dummy record for the current PC when we enable tracing so we show the trace from the location where branch tracing has been enabled. 2014-01-16 Markus Metzger <markus.t.metzger@intel.com> * btrace.c: Include regcache.h. (btrace_add_pc): New. (btrace_enable): Call btrace_add_pc. (btrace_is_empty): New. * btrace.h (btrace_is_empty): New. * record-btrace.c (require_btrace, record_btrace_info): Call btrace_is_empty. testsuite/ * gdb.btrace/Makefile.in (EXECUTABLES): Add delta. * gdb.btrace/exception.exp: Update. * gdb.btrace/instruction_history.exp: Update. * gdb.btrace/record_goto.exp: Update. * gdb.btrace/tailcall.exp: Update. * gdb.btrace/unknown_functions.exp: Update. * gdb.btrace/delta.exp: New.
2013-09-10 12:27:14 +02:00
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/Makefile.in (EXECUTABLES): Add delta.
* gdb.btrace/exception.exp: Update.
* gdb.btrace/instruction_history.exp: Update.
* gdb.btrace/record_goto.exp: Update.
* gdb.btrace/tailcall.exp: Update.
* gdb.btrace/unknown_functions.exp: Update.
* gdb.btrace/delta.exp: New.
record-btrace: extend unwinder Extend the always failing unwinder to provide the PC based on the call structure detected in the branch trace. The unwinder supports normal frames and tailcall frames. Inline frames are not supported. 2014-01-16 Markus Metzger <markus.t.metzger@intel.com> * record.h (record_btrace_frame_unwind) (record_btrace_tailcall_frame_unwind): New declarations. * dwarf2-frame: Include record.h (dwarf2_frame_cfa): Throw an error for btrace frames. * record-btrace.c: Include hashtab.h. (btrace_get_bfun_name): New. (btrace_call_history): Call btrace_get_bfun_name. (struct btrace_frame_cache): New. (bfcache): New. (bfcache_hash, bfcache_eq, bfcache_new): New. (btrace_get_frame_function): New. (record_btrace_frame_unwind_stop_reason): Allow unwinding. (record_btrace_frame_this_id): Compute own id. (record_btrace_frame_prev_register): Provide PC, throw_error for all other registers. (record_btrace_frame_sniffer): Detect btrace frames. (record_btrace_tailcall_frame_sniffer): New. (record_btrace_frame_dealloc_cache): New. (record_btrace_frame_unwind): Add new functions. (record_btrace_tailcall_frame_unwind): New. (_initialize_record_btrace): Allocate cache. * btrace.c (btrace_clear): Call reinit_frame_cache. * NEWS: Announce it. testsuite/ * gdb.btrace/record_goto.exp: Add backtrace test. * gdb.btrace/tailcall.exp: Add backtrace test.
2013-03-27 09:49:47 +01:00
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/record_goto.exp: Add backtrace test.
* gdb.btrace/tailcall.exp: Add backtrace test.
record-btrace: add record goto target methods 2014-01-16 Markus Metzger <markus.t.metzger@intel.com> * record-btrace.c (record_btrace_set_replay) (record_btrace_goto_begin, record_btrace_goto_end) (record_btrace_goto): New. (init_record_btrace_ops): Initialize them. * NEWS: Announce it. testsuite/ * gdb.btrace/Makefile.in (EXECUTABLES): Add record_goto. * gdb.btrace/record_goto.c: New. * gdb.btrace/record_goto.exp: New. * gdb.btrace/x86-record_goto.S: New.
2013-03-25 16:01:33 +01:00
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/Makefile.in (EXECUTABLES): Add record_goto.
* gdb.btrace/record_goto.c: New.
* gdb.btrace/record_goto.exp: New.
* gdb.btrace/x86-record_goto.S: New.
record-btrace: make ranges include begin and end The "record function-call-history" and "record instruction-history" commands accept a range "begin, end". End is not included in both cases. Include it. 2014-01-16 Markus Metzger <markus.t.metzger@intel.com> * record-btrace.c (record_btrace_insn_history_range): Include end. (record_btrace_insn_history_from): Adjust range. (record_btrace_call_history_range): Include end. (record_btrace_call_history_from): Adjust range. * NEWS: Announce changes. testsuite/ * gdb.btrace/function_call_history.exp: Update tests. * gdb.btrace/instruction_history.exp: Update tests. doc/ * gdb.texinfo (Process Record and Replay): Update documentation.
2013-04-17 09:39:43 +02:00
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/function_call_history.exp: Update tests.
* gdb.btrace/instruction_history.exp: Update tests.
record-btrace: optionally indent function call history Add a new modifier /c to the "record function-call-history" command to indent the function name based on its depth in the call stack. Also reorder the optional fields to have the indentation at the very beginning. Prefix the insn range (/i modifier) with "inst ". Prefix the source line (/l modifier) with "at ". Change the range syntax from "begin-end" to "begin,end" to allow copy&paste to the "record instruction-history" and "list" commands. Adjust the respective tests and add new tests for the /c modifier. 2014-01-16 Markus Metzger <markus.t.metzger@intel.com> * record.h (enum record_print_flag) <record_print_indent_calls>: New. * record.c (get_call_history_modifiers): Recognize /c modifier. (_initialize_record): Document /c modifier. * record-btrace.c (btrace_call_history): Add btinfo parameter. Reorder fields. Optionally indent the function name. Update all users. * NEWS: Announce changes. testsuite/ * gdb.btrace/function_call_history.exp: Fix expected field order for "record function-call-history". Add new tests for "record function-call-history /c". * gdb.btrace/exception.cc: New. * gdb.btrace/exception.exp: New. * gdb.btrace/tailcall.exp: New. * gdb.btrace/x86-tailcall.S: New. * gdb.btrace/x86-tailcall.c: New. * gdb.btrace/unknown_functions.c: New. * gdb.btrace/unknown_functions.exp: New. * gdb.btrace/Makefile.in (EXECUTABLES): Add new. doc/ * gdb.texinfo (Process Record and Replay): Document new /c modifier accepted by "record function-call-history". Add /i modifier to "record function-call-history" example.
2013-04-18 10:58:05 +02:00
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/function_call_history.exp: Fix expected field
order for "record function-call-history".
Add new tests for "record function-call-history /c".
* gdb.btrace/exception.cc: New.
* gdb.btrace/exception.exp: New.
* gdb.btrace/tailcall.exp: New.
* gdb.btrace/x86-tailcall.S: New.
* gdb.btrace/x86-tailcall.c: New.
* gdb.btrace/unknown_functions.c: New.
* gdb.btrace/unknown_functions.exp: New.
* gdb.btrace/Makefile.in (EXECUTABLES): Add new.
record-btrace: start counting at one The record instruction-history and record-function-call-history commands start counting instructions at zero. This is somewhat unintuitive when we start navigating in the recorded instruction history. Start at one, instead. 2014-01-16 Markus Metzger <markus.t.metzger@intel.com> * btrace.c (ftrace_new_function): Start counting at one. * record-btrace.c (record_btrace_info): Adjust number of calls and insns. * NEWS: Announce it. testsuite/ * gdb.btrace/instruction_history.exp: Update. * gdb.btrace/function_call_history.exp: Update.
2013-05-13 14:57:42 +02:00
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/instruction_history.exp: Update.
* gdb.btrace/function_call_history.exp: Update.
btrace: change branch trace data structure The branch trace is represented as 3 vectors: - a block vector - a instruction vector - a function vector Each vector (except for the first) is computed from the one above. Change this into a graph where a node represents a sequence of instructions belonging to the same function and where we have three types of edges to connect the function segments: - control flow - same function (instance) - call stack This allows us to navigate in the branch trace. We will need this for "record goto" and reverse execution. This patch introduces the data structure and computes the control flow edges. It also introduces iterator structs to simplify iterating over the branch trace in control-flow order. It also fixes PR gdb/15240 since now recursive calls are handled correctly. Fix the test that got the number of expected fib instances and also the function numbers wrong. The current instruction had been part of the branch trace. This will look odd once we start support for reverse execution. Remove it. We still keep it in the trace itself to allow extending the branch trace more easily in the future. 2014-01-16 Markus Metzger <markus.t.metzger@intel.com> * btrace.h (struct btrace_func_link): New. (enum btrace_function_flag): New. (struct btrace_inst): Rename to ... (struct btrace_insn): ...this. Update all users. (struct btrace_func) <ibegin, iend>: Remove. (struct btrace_func_link): New. (struct btrace_func): Rename to ... (struct btrace_function): ...this. Update all users. (struct btrace_function) <segment, flow, up, insn, insn_offset) (number, level, flags>: New. (struct btrace_insn_iterator): Rename to ... (struct btrace_insn_history): ...this. Update all users. (struct btrace_insn_iterator, btrace_call_iterator): New. (struct btrace_target_info) <btrace, itrace, ftrace>: Remove. (struct btrace_target_info) <begin, end, level> <insn_history, call_history>: New. (btrace_insn_get, btrace_insn_number, btrace_insn_begin) (btrace_insn_end, btrace_insn_prev, btrace_insn_next) (btrace_insn_cmp, btrace_find_insn_by_number, btrace_call_get) (btrace_call_number, btrace_call_begin, btrace_call_end) (btrace_call_prev, btrace_call_next, btrace_call_cmp) (btrace_find_function_by_number, btrace_set_insn_history) (btrace_set_call_history): New. * btrace.c (btrace_init_insn_iterator) (btrace_init_func_iterator, compute_itrace): Remove. (ftrace_print_function_name, ftrace_print_filename) (ftrace_skip_file): Change parameter to const. (ftrace_init_func): Remove. (ftrace_debug): Use new btrace_function fields. (ftrace_function_switched): Also consider gaining and losing symbol information). (ftrace_print_insn_addr, ftrace_new_call, ftrace_new_return) (ftrace_new_switch, ftrace_find_caller, ftrace_new_function) (ftrace_update_caller, ftrace_fixup_caller, ftrace_new_tailcall): New. (ftrace_new_function): Move. Remove debug print. (ftrace_update_lines, ftrace_update_insns): New. (ftrace_update_function): Check for call, ret, and jump. (compute_ftrace): Renamed to ... (btrace_compute_ftrace): ...this. Rewritten to compute call stack. (btrace_fetch, btrace_clear): Updated. (btrace_insn_get, btrace_insn_number, btrace_insn_begin) (btrace_insn_end, btrace_insn_prev, btrace_insn_next) (btrace_insn_cmp, btrace_find_insn_by_number, btrace_call_get) (btrace_call_number, btrace_call_begin, btrace_call_end) (btrace_call_prev, btrace_call_next, btrace_call_cmp) (btrace_find_function_by_number, btrace_set_insn_history) (btrace_set_call_history): New. * record-btrace.c (require_btrace): Use new btrace thread info fields. (record_btrace_info, btrace_insn_history) (record_btrace_insn_history, record_btrace_insn_history_range): Use new btrace thread info fields and new iterator. (btrace_func_history_src_line): Rename to ... (btrace_call_history_src_line): ...this. Use new btrace thread info fields. (btrace_func_history): Rename to ... (btrace_call_history): ...this. Use new btrace thread info fields and new iterator. (record_btrace_call_history, record_btrace_call_history_range): Use new btrace thread info fields and new iterator. testsuite/ * gdb.btrace/function_call_history.exp: Fix expected function trace. * gdb.btrace/instruction_history.exp: Initialize traced. Remove traced_functions.
2013-03-22 14:32:47 +01:00
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/function_call_history.exp: Fix expected function
trace.
* gdb.btrace/instruction_history.exp: Initialize traced.
Remove traced_functions.
btrace, test: fix multi-line btrace tests For testing multi-line test output, gdb.btrace tests used the following pattern: gdb_test "..." " ...\r ..." Change this to: gdb_test "..." [join [list \ "..." \ "..."] "\r\n"] Also extract repeated tests into a test function and shorten or remove test messages. 2014-01-16 Markus Metzger <markus.t.metzger@intel.com> testsuite/ * gdb.btrace/function_call_history.exp: Update * gdb.btrace/instruction_history.exp: Update.
2013-12-18 14:47:17 +01:00
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/function_call_history.exp: Update
* gdb.btrace/instruction_history.exp: Update.
test, btrace: update expected text The error message for starting recording twice changed. Update the expected text to fix resulting regressions. 2014-01-16 Markus Metzger <markus.t.metzger@intel.com> * gdb.btrace/enable.exp: Update expected text.
2014-01-16 09:47:51 +01:00
2014-01-16 Markus Metzger <markus.t.metzger@intel.com>
* gdb.btrace/enable.exp: Update expected text.
Fix testsuite/gdb.dwarf2/dw2-dos-drive.exp on ARM. This test currently fails on ARM: (gdb) PASS: gdb.dwarf2/dw2-dos-drive.exp: set breakpoint pending off break 'z:file.c':func Cannot access memory at address 0x0 The error is GDB trying to read the prologue at the breakpoint's address, and failing: 38 throw_error() exceptions.c:444 0x0016728c 37 memory_error() corefile.c:204 0x001d1fcc 36 read_memory() corefile.c:223 0x001d201a 35 read_memory_unsigned_integer() corefile.c:312 0x001d2166 34 arm_skip_prologue() arm-tdep.c:1452 0x00054270 static CORE_ADDR arm_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR pc) { ... for (skip_pc = pc; skip_pc < limit_pc; skip_pc += 4) { inst = read_memory_unsigned_integer (skip_pc, 4, byte_order_for_code); The test doesn't execute the compiled object's code, so GDB will try to read memory from the binary's sections. Instructions on ARM are 4-byte wide, and thus ARM's prologue scanner reads in 4-byte chunks. As the section 'func' is put at is only 1 byte long, and no other section is allocated contiguously: ... Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000001 00000000 00000000 00000034 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE ... ... the exec target fails the read the 4 bytes. Fix this by increasing the function's size. gdb/testsuite/ChangeLog: 2014-01-16 Omair Javaid <Omair.Javaid@linaro.org> * gdb.dwarf2/dw2-dos-drive.S: Increase text section size to 4 bytes.
2014-01-16 12:00:00 +01:00
2014-01-16 Omair Javaid <Omair.Javaid@linaro.org>
* gdb.dwarf2/dw2-dos-drive.S: Increase text section size to 4
bytes.
AArch64: gdb.base/float.exp: Fix `info float' test * gdb.base/float.exp: Handle "aarch64*-*-*" targets.
2014-01-15 23:17:53 +01:00
2014-01-15 Maciej W. Rozycki <macro@codesourcery.com>
* gdb.base/float.exp: Handle "aarch64*-*-*" targets.
gdb: ARM: Update configure.tgt and enable gdb.reverse testsuite gdb/testsuite/ChangeLog: 2014-01-15 Omair Javaid <omair.javaid@linaro.org> * lib/gdb.exp (supports_process_record): Return true for arm*-linux*. (supports_reverse): Likewise.
2014-01-09 11:59:55 +01:00
2014-01-15 Omair Javaid <omair.javaid@linaro.org>
* lib/gdb.exp (supports_process_record): Return true for
arm*-linux*. (supports_reverse): Likewise.
Use bitpos and type to lookup a gdb.Field object when its name is 'None'. PR python/15464 PR python/16113 * valops.c (value_struct_elt_bitpos): New function * py-type.c (convert_field): Set 'name' attribute of a gdb.Field object to 'None' if the field name is an empty string (""). * python/py-value.c (valpy_getitem): Use 'bitpos' and 'type' attribute to look for a field when 'name' is 'None'. (get_field_type): New function testsuite/ * gdb.python/py-type.c: Enhance test case. * gdb.python/py-value-cc.cc: Likewise * gdb.python/py-type.exp: Add new tests. * gdb.python/py-value-cc.exp: Likewise
2013-12-27 21:20:59 +01:00
2014-01-13 Siva Chandra Reddy <sivachandra@google.com>
PR python/15464
PR python/16113
* gdb.python/py-type.c: Enhance test case.
* gdb.python/py-value-cc.cc: Likewise
* gdb.python/py-type.exp: Add new tests.
* gdb.python/py-value-cc.exp: Likewise
Since upstream gcc has recently increased the function alignment on S390, the dw2-dir-file-name test case fails in the first gdb_continue_to_breakpoint. Indeed, the breakpoint is now placed into the alignment gap *before* the actual function. This happens because the test case declares the respective "*_start" symbol as a "loose" label before the function definition, and the compiler inserts the alignment between that label and the function itself. The "*_start" symbols were only necessary because FUNC made the function static. The fix makes the functions extern instead, thus making the "*_start" labels unnecessary. testsuite/ 2014-01-10 Andreas Arnez <arnez@linux.vnet.ibm.com> Pedro Alves <palves@redhat.com> * gdb.dwarf2/dw2-dir-file-name.c (FUNC): Remove "*_start" symbol. Make "name" extern. * gdb.dwarf2/dw2-dir-file-name.exp (out_cu, out_line): Replace references to ${name}_start by references to ${name}.
2014-01-10 16:37:36 +01:00
2014-01-10 Andreas Arnez <arnez@linux.vnet.ibm.com>
Pedro Alves <palves@redhat.com>
* gdb.dwarf2/dw2-dir-file-name.c (FUNC): Remove "*_start" symbol.
Make "name" extern.
* gdb.dwarf2/dw2-dir-file-name.exp (out_cu, out_line): Replace
references to ${name}_start by references to ${name}.
Remove path from gdb.ada/pp-rec-component.exp "source" test gdb/testsuite/ChangeLog: * gdb.ada/pp-rec-component.exp: Remove path from "source" test.
2014-01-10 04:54:23 +01:00
2014-01-10 Joel Brobecker <brobecker@adacore.com>
* gdb.ada/pp-rec-component.exp: Remove path from "source" test.
Remove path from gdb.python/py-pp-integral.exp "source" test. gdb/testsuite/ChangeLog: * gdb.python/py-pp-integral.exp: Remove path from "source" test.
2014-01-10 04:50:29 +01:00
2014-01-10 Joel Brobecker <brobecker@adacore.com>
* gdb.python/py-pp-integral.exp: Remove path from "source" test.
gdb.mi/mi-info-os.exp: Fix cross-debugger testing A live target is required for `-info-os' to work in non-native configurations. (gdb) Expecting: ^(-info-os[ ]+)?(.*\^done,OSDataTable=.*[ ]+[(]gdb[)] [ ]*) -info-os ^error,msg="Don't know how to get OS data. Try \"help target\"." (gdb) FAIL: gdb.mi/mi-info-os.exp: -info-os If GDB does have a native configuration included, but we're testing remote, it'll be worse, as if we're not connected yet, -info-os will run against the default run target, and pass, falsely giving the impression the remote bits were exercised. gdb/testsuite/ 2014-01-09 Maciej W. Rozycki <macro@codesourcery.com> Pedro Alves <palves@redhat.com> * gdb.mi/mi-info-os.exp: Connect to the target with mi_gdb_target_load.
2014-01-09 20:57:13 +01:00
2014-01-09 Maciej W. Rozycki <macro@codesourcery.com>
Pedro Alves <palves@redhat.com>
* gdb.mi/mi-info-os.exp: Connect to the target with
mi_gdb_target_load.
[remote/gdbserver] Don't lose signals when reconnecting. Currently, when GDB connects in all-stop mode, GDBserver always responds to the status packet with a GDB_SIGNAL_TRAP, even if the program is actually stopped for some other signal. (gdb) tar rem ... ... (gdb) c Program received signal SIGUSR1, User defined signal 1. (gdb) disconnect (gdb) tar rem ... (gdb) c (Or a GDB crash instead of an explicit disconnect.) This results in the program losing that signal on that last continue, because gdb will tell the target to resume with no signal (to suppress the GDB_SIGNAL_TRAP, due to 'handle SISGTRAP nopass'), and that will actually suppress the real signal the program had stopped for (SIGUSR1). To fix that, I think we should make GDBserver report the real signal the thread had stopped for in response to the status packet: @item ? @cindex @samp{?} packet Indicate the reason the target halted. The reply is the same as for step and continue. But, that raises the question -- which thread are we reporting the status for? Due to how the RSP in all-stop works, we can only report one status. The status packet's response is a stop reply packet, so it includes the thread identifier, so it's not a problem packet-wise. However, GDBserver is currently always reporting the status for first thread in the thread list, even though that may well not be the thread that got the signal that caused the program to stop. So the next logical step would be to report the status for the last_ptid/last_status thread (the last event reported to gdb), if it's still around; and if not, fallback to some other thread. There's an issue on the GDB side with that, though... GDB currently always adds the thread reported in response to the status query as the first thread in its list. That means that if we start with e.g., (gdb) info threads 3 Thread 1003 ... * 2 Thread 1002 ... 1 Thread 1001 ... And reconnect: (gdb) disconnect (gdb) tar rem ... We end up with: (gdb) info threads 3 Thread 1003 ... 2 Thread 1001 ... * 1 Thread 1002 ... Not a real big issue, but it's reasonably fixable, by having GDB fetch/sync the thread list before fetching the status/'?', and then using the status to select the right thread as current on the GDB side. Holes in the thread numbers are squashed before/after reconnection (e.g., 2,3,5 becomes 1,2,3), but the order is preserved, which I think is both good, and good enough. However (yes, there's more...), the previous GDB that was connected might have had gdbserver running in non-stop mode, or could have left gdbserver doing disconnected tracing (which also forces non-stop), and if the new gdb/connection is in all-stop mode, we can end up with more than one thread with a signal to report back to gdb. As we can only report one thread/status (in the all-stop RSP variant; the non-stop variant doesn't have this issue), we get to do what we do at every other place we have this situation -- leave events we can't report right now as pending, so that the next resume picks them up. Note all this ammounts to a QoI change, within the existing framework. There's really no RSP change here. The only user visible change (other than that the signal is program is stopped at isn't lost / is passed to the program), is in "info program", that now can show the signal the program stopped for. Of course, the next resume will respect the pass/nopass setting for the signal in question. It'd be reasonable to have the initial connection tell the user the program was stopped with a signal, similar to when we load a core to debug, but I'm leaving that out for a future change. I think we'll need to either change how handle_inferior_event & co handle stop_soon, or maybe bypass them completely (like fork-child.c:startup_inferior) for that. Tested on x86_64 Fedora 17. gdb/gdbserver/ 2014-01-08 Pedro Alves <palves@redhat.com> * gdbthread.h (struct thread_info) <status_pending_p>: New field. * server.c (visit_actioned_threads, handle_pending_status): New function. (handle_v_cont): Factor out parts to ... (resume): ... this new function. If in all-stop, and a thread being resumed has a pending status, report it without actually resuming. (myresume): Adjust to use the new 'resume' function. (clear_pending_status_callback, set_pending_status_callback) (find_status_pending_thread_callback): New functions. (handle_status): Handle the case of multiple threads having interesting statuses to report. Report threads' real last signal instead of always reporting GDB_SIGNAL_TRAP. Look for a thread with an interesting thread to report the status for, instead of always reporting the status of the first thread. gdb/ 2014-01-08 Pedro Alves <palves@redhat.com> * remote.c (remote_add_thread): Add threads silently if starting up. (remote_notice_new_inferior): If in all-stop, and starting up, don't call notice_new_inferior. (get_current_thread): New function, factored out from ... (add_current_inferior_and_thread): ... this. Adjust. (remote_start_remote) <all-stop>: Fetch the thread list. If we found any thread, then select the remote's current thread as GDB's current thread too. gdb/testsuite/ 2014-01-08 Pedro Alves <palves@redhat.com> * gdb.threads/reconnect-signal.c: New file. * gdb.threads/reconnect-signal.exp: New file.
2014-01-08 19:55:51 +01:00
2014-01-08 Pedro Alves <palves@redhat.com>
* gdb.threads/reconnect-signal.c: New file.
* gdb.threads/reconnect-signal.exp: New file.
Fix dir command for duplicated paths and add a new testcase. gdb/ChangeLog: 2014-01-07 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com> * source.c (add_path): Fix check for duplicated paths in the previously included paths. gdb/testsuite/ChangeLog: 2014-01-07 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.base/source-dir.exp: New file.
2014-01-07 20:03:06 +01:00
2014-01-07 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/source-dir.exp: New file.
Add missing ChangeLog entries.
2014-01-08 10:16:32 +01:00
2014-01-07 Joel Brobecker <brobecker@adacore.com>
* gdb.ada/mi_interface: New testcase.
Ada: Fix missing call to pretty-printer for fields of records. Consider the following types: type Time_T is record Secs : Integer; end record; Before : Time_T := (Secs => 1384395743); In this example, we assume that type Time_T is the number of seconds since Epoch, and so added a Python pretty-printer, to print this type in a more human-friendly way. For instance: (gdb) print before $1 = Thu Nov 14 02:22:23 2013 (1384395743) However, we've noticed that things stop working when this type is embedded inside another record, and we try to print that record. For instance, with the following declarations: type Composite is record Id : Integer; T : Time_T; end record; Afternoon : Composite := (Id => 1, T => (Secs => 1384395865)); (gdb) print afternoon $2 = (id => 1, t => (secs => 1384395865)) We expected instead: (gdb) print afternoon $2 = (id => 1, t => Thu Nov 14 02:24:25 2013 (1384395865)) This patch fixes the problem by making sure that we try to print each field via a call to val_print, rather than calling ada_val_print directly. We need to go through val_print, as the val_print handles all language-independent features such as calling the pretty-printer, knowing that ada_val_print will get called eventually if actual Ada-specific printing is required (which should be the most common scenario). And because val_print takes the language as parameter, we enhanced the print_field_values and print_variant_part to also take a language. As a bonus, this allows us to remove a couple of references to current_language. gdb/ChangeLog: * ada-valprint.c (print_field_values): Add "language" parameter. Update calls to print_field_values and print_variant_part. Pass new parameter "language" in call to val_print instead of "current_language". Replace call to ada_val_print by call to val_print. (print_variant_part): Add "language" parameter. (ada_val_print_struct_union): Update call to print_field_values. gdb/testsuite/ChangeLog: * gdb.ada/pp-rec-component.exp, gdb.ada/pp-rec-component.py, gdb.ada/pp-rec-component/foo.adb, gdb.ada/pp-rec-component/pck.adb, gdb.ada/pp-rec-component/pck.ads: New files.
2013-12-19 18:26:55 +01:00
2014-01-07 Joel Brobecker <brobecker@adacore.com>
* gdb.ada/pp-rec-component.exp, gdb.ada/pp-rec-component.py,
gdb.ada/pp-rec-component/foo.adb, gdb.ada/pp-rec-component/pck.adb,
gdb.ada/pp-rec-component/pck.ads: New files.
[python] Add gdb.Type.name attribute. Consider the following declarations: typedef long our_time_t; our_time_t current_time = 1384395743; The purpose of this patch is to allow the use of a pretty-printer for variables of type our_time_t. Normally, pretty-printing sniffers use the tag name in order to determine which, if any, pretty-printer should be used. But in the case above, the tag name is not set, since it does not apply to integral types. This patch extends the gdb.Type list of attributes to also include the name of the type, thus allowing the sniffer to match against that name. With that change, I was able to write a pretty-printer which displays our variable as follow: (gdb) print current_time $1 = Thu Nov 14 02:22:23 2013 (1384395743) gdb/ChangeLog: * python/py-type.c (typy_get_name): New function. (type_object_getset): Add entry for attribute "name". * NEWS: Add entry mentioning this new attribute. gdb/doc/ChangeLog: * gdb.texinfo (Types In Python): Document new attribute Types.name. gdb/testsuite: * gdb.python/py-pp-integral.c: New file. * gdb.python/py-pp-integral.py: New file. * gdb.python/py-pp-integral.exp: New file. Tested on x86_64-linux.
2013-12-23 04:18:51 +01:00
2014-01-07 Joel Brobecker <brobecker@adacore.com>
* gdb.python/py-pp-integral.c: New file.
* gdb.python/py-pp-integral.py: New file.
* gdb.python/py-pp-integral.exp: New file.
Add link to older changes in ChangeLog-1993-2013.
2014-05-13 00:16:13 +02:00
For older changes see ChangeLog-1993-2013.
Initial creation of sourceware repository
1999-04-16 03:35:26 +02:00
* ChangeLog: Prefix Local Variables with semi-colons and indent the reference to older ChangeLog files, to fix fontification in Emacs.
2004-08-14 15:23:24 +02:00
;; Local Variables:
;; mode: change-log
;; left-margin: 8
;; fill-column: 74
;; version-control: never
;; End:
2004-08-10 Michael Chastain <mec.gnu@mindspring.com> * ChangeLog: Add copyright notice. The notice is copied from emacs 21.3 top level ChangeLog.
2004-08-10 21:13:35 +02:00
Update year range in copyright notice of all files owned by the GDB project. gdb/ChangeLog: Update year range in copyright notice of all files.
2015-01-01 10:32:14 +01:00
Copyright 2014-2015 Free Software Foundation, Inc.
2004-08-10 Michael Chastain <mec.gnu@mindspring.com> * ChangeLog: Add copyright notice. The notice is copied from emacs 21.3 top level ChangeLog.
2004-08-10 21:13:35 +02:00
Copying and distribution of this file, with or without modification,
are permitted provided the copyright notice and this notice are preserved.