aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite
AgeCommit message (Collapse)AuthorFilesLines
2016-09-06Remove obsolete TYPE_FLAG_... valuesUlrich Weigand2-2/+6
Now that init_type no longer takes a FLAGS argument, there is no user of the TYPE_FLAGS_... enum values left. This commit removes them (and all references to them in comments as well). This is mostly a no-op, except for a change to the Python type printer, which attempted to use them before. (As best as I can tell, this wasn't really needed anyway, since it was only used to pretty-print type *instance* flags, which only use the instance flags.) gdb/ChangeLog: * gdbtypes.h (enum type_flag_value): Remove. Remove references to TYPE_FLAG_... in comments throughout. * gdbtypes.c (recursive_dump_type): Do not print TYPE_FLAG_... flags, print the corresponding TYPE_... access macro names. Remove references to TYPE_FLAG_... in comments throughout. * infcall.c: Remove references to TYPE_FLAG_... in comments. * valprint.c: Likewise. * gdb-gdb.py (class TypeFlag): No longer consider TYPE_FLAG_... values, only TYPE_INSTANCE_FLAG_... values. (class TypeFlagsPrinter): Likewise. gdb/testsuite/ChangeLog: * gdb.cp/hang.exp: Remove reference to TYPE_FLAG_STUB in comment. Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
2016-09-05Fix PR19927: Avoid unwinder recursion if sniffer uses calls parse_and_evalPedro Alves3-5/+13
This fixes the problem exercised by Kevin's test at: https://sourceware.org/ml/gdb-patches/2016-08/msg00216.html This was originally exposed by the OpenJDK Python-based unwinder. If an unwinder attempts to call parse_and_eval from within its sniffing method, GDB's unwinding machinery enters infinite recursion. However, parse_and_eval is a pretty reasonable thing to call, because Python/Scheme-based unwinders will often need to read globals out of inferior memory. The recursion happens because: - get_current_frame() is called soon after the target stops. - current_frame is NULL, and so we unwind it from the sentinel frame (which is special and has level == -1). - We reach get_prev_frame_if_no_cycle, which does cycle detection based on frame id, and thus tries to compute the frame id of the new frame. - Frame id computation requires an unwinder, so we go through all unwinder sniffers trying to see if one accepts the new frame (the current frame). - the unwinder's sniffer calls parse_and_eval(). - parse_and_eval depends on the selected frame/block, and if not set yet, the selected frame is set to the current frame. - get_current_frame () is called again. current_frame is still NULL, so ... - recurse forever. In Kevin's test at: https://sourceware.org/ml/gdb-patches/2016-08/msg00216.html gdb doesn't recurse forever simply because the Python unwinder contains code to detect and stop the recursion itself. However, GDB goes downhill from here, e.g., by showing the sentinel frame as current frame (note the -1): Breakpoint 1, ccc (arg=<unavailable>) at py-recurse-unwind.c:23 23 } (gdb) bt #-1 ccc (arg=<unavailable>) at py-recurse-unwind.c:23 Backtrace stopped: previous frame identical to this frame (corrupt stack?) That "-1" frame level comes from this: if (catch_exceptions (current_uiout, unwind_to_current_frame, sentinel_frame, RETURN_MASK_ERROR) != 0) { /* Oops! Fake a current frame? Is this useful? It has a PC of zero, for instance. */ current_frame = sentinel_frame; } which is bogus. It's never correct to set the current frame to the sentinel frame. The only reason this has survived so long is that getting here normally indicates something wrong has already happened before and we fix that. And this case is no exception -- it doesn't really matter how precisely we managed to get to that bogus code (it has to do with the the stash), because anything after recursion happens is going to be invalid. So the fix is to avoid the recursion in the first place. Observations: #1 - The recursion happens because we try to do cycle detection from within get_prev_frame_if_no_cycle. That requires computing the frame id of the frame being unwound, and that itself requires calling into the unwinders. #2 - But, the first time we're unwinding from the sentinel frame, when we reach get_prev_frame_if_no_cycle, there's no frame chain at all yet: - current_frame is NULL. - the frame stash is empty. Thus, there's really no need to do cycle detection the first time we reach get_prev_frame_if_no_cycle, when building the current frame. So we can break the recursion by making get_current_frame call a simplified version of get_prev_frame_if_no_cycle that results in setting the current_frame global _before_ computing the current frame's id. But, we can go a little bit further. As there's really no reason anymore to compute the current frame's frame id immediately, we can defer computing it to when some caller of get_current_frame might need it. This was actually how the frame id was computed for all frames before the stash-based cycle detection was added. So in a way, this patch reintroduces the lazy frame id computation, but unlike before, only for the case of the current frame, which turns out to be special. This lazyness, however, requires adjusting gdb.python/py-unwind-maint.exp, because that assumes unwinders are immediately called as side effect of some commands. I didn't see a need to preserve the behavior expected by that test (all it would take is call get_frame_id inside get_current_frame), so I adjusted the test. gdb/ChangeLog: 2016-09-05 Pedro Alves <palves@redhat.com> PR backtrace/19927 * frame.c (get_frame_id): Compute the frame id if not computed yet. (unwind_to_current_frame): Delete. (get_current_frame): Use get_prev_frame_always_1 to get the current frame and assert that that always succeeds. (get_prev_frame_if_no_cycle): Skip cycle detection if returning the current frame. gdb/testsuite/ChangeLog: 2016-09-05 Pedro Alves <palves@redhat.com> PR backtrace/19927 * gdb.python/py-unwind-maint.exp: Adjust tests to not expect that unwinders are immediately called as side effect of "source" or "disable unwinder" commands. * gdb.python/py-recurse-unwind.exp: Remove setup_kfail calls.
2016-09-02Skip floating point tests in return-nodebug.exp if gdb_skip_float_test is trueYao Qi2-0/+10
return-nodebug.exp does the test for various types, but we shouldn't test with floating point type if gdb_skip_float_test returns true. gdb/testsuite: 2016-09-02 Yao Qi <yao.qi@linaro.org> * gdb.base/return-nodebug.exp: Skip the test if skip_float_test is true and $type is "float" or "double".
2016-09-02Detect broken ptrace in gdb_skip_float_testYao Qi12-28/+156
We recently found a ARM kernel ptrace bug http://lists.infradead.org/pipermail/linux-arm-kernel/2016-May/431962.html Details can be found in the comment in gdb_skip_float_test. We can skip floating point tests if the kernel bug is detected. This patch adds more code in gdb_skip_float_test to detect the broken ptrace on arm-linux. Such detection should be done at the beginning of the test, because it starts a fresh GDB, so change the test cases to invoke gdb_skip_float_test at the beginning of test, and use its return value afterwards. Since gdb_skip_float_test becomes a gdb_caching_proc, so it can't have an argument, this patch also removes argument "msg", which isn't useful. gdb/testsuite: 2016-09-02 Yao Qi <yao.qi@linaro.org> * gdb.arch/arm-neon.exp: Skip it if gdb_skip_float_test returns true. * gdb.base/call-ar-st.exp: Invoke gdb_skip_float_test. * gdb.base/call-rt-st.exp: Likewise. * gdb.base/call-sc.exp: Invoke gdb_skip_float_test and use its return value instead of gdb,skip_float_test. * gdb.base/callfuncs.exp: Invoke gdb_skip_float_test. (do_function_calls): Use its return value instead of gdb,skip_float_test. * gdb.base/finish.exp: Likewise. * gdb.base/funcargs.exp: Likewise. * gdb.base/return.exp: Likewise. * gdb.base/return2.exp: Likewise. * gdb.base/varargs.exp: Likewise. * lib/gdb.exp (gdb_skip_float_test): Change it to gdb_caching_proc. Detect the broken ptrace on arm-linux.
2016-08-30Fix order of inferiors in "thread apply all"Andreas Arnez2-0/+10
This inserts missing parentheses in the calculation of the comparison result between two different inferior numbers. The problem was found by Philipp Rudo. gdb/ChangeLog: * thread.c (tp_array_compar): Insert missing parentheses. gdb/testsuite/ChangeLog: * gdb.multi/tids.exp: Test "thread apply all".
2016-08-29gdb.base/default.exp regressionJan Kratochvil2-2/+4
tty^M (gdb) FAIL: gdb.base/default.exp: tty gdb/testsuite/ChangeLog 2016-08-29 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.base/default.exp (tty): Remove.
2016-08-24Test case to detect recursive unwinding in Python-based unwinders.Kevin Buettner4-0/+191
This test case verifies that GDB will not attempt to invoke a python unwinder recursively. At the moment, the behavior exhibited by GDB looks like this: (gdb) source py-recurse-unwind.py Python script imported (gdb) b ccc Breakpoint 1 at 0x4004bd: file py-recurse-unwind.c, line 23. (gdb) run Starting program: py-recurse-unwind TestUnwinder: Recursion detected - returning early. TestUnwinder: Recursion detected - returning early. TestUnwinder: Recursion detected - returning early. TestUnwinder: Recursion detected - returning early. Breakpoint 1, ccc (arg=<unavailable>) at py-recurse-unwind.c:23 23 } (gdb) bt #-1 ccc (arg=<unavailable>) at py-recurse-unwind.c:23 Backtrace stopped: previous frame identical to this frame (corrupt stack?) [I've shortened pathnames for easier reading.] The desired / expected behavior looks like this: (gdb) source py-recurse-unwind.py Python script imported (gdb) b ccc Breakpoint 1 at 0x4004bd: file py-recurse-unwind.c, line 23. (gdb) run Starting program: py-recurse-unwind Breakpoint 1, ccc (arg=789) at py-recurse-unwind.c:23 23 } (gdb) bt #0 ccc (arg=789) at py-recurse-unwind.c:23 #1 0x00000000004004d5 in bbb (arg=456) at py-recurse-unwind.c:28 #2 0x00000000004004ed in aaa (arg=123) at py-recurse-unwind.c:34 #3 0x00000000004004fe in main () at py-recurse-unwind.c:40 Note that GDB's problems go well beyond the fact that it invokes the unwinder recursively. In the process it messes up some internal state (the frame stash) leading to display of (only) the sentinel frame in the backtrace. gdb/testsuite/ChangeLog: * gdb.python/py-recurse-unwind.c: New file. * gdb.python/py-recurse-unwind.py: New file. * gdb.python/py-recurse-unwind.exp: New file.
2016-08-24Allow resetting an empty inferior-ttySimon Marchi3-0/+69
This patch allows the user to set the inferior-tty to "empty", in order to come back to the default behaviour of using the same tty as gdb is using. This is already supported in MI (and tested in gdb.mi/mi-basics.exp). I added a new test, set-inferior-tty.exp, where I test only the setting and unsetting of the parameter. It would be nice to actually test that the inferior output properly goes to the separate tty, but that will be for another day. gdb/ChangeLog: * infcmd.c (set_inferior_io_terminal): Set inferior terminal to NULL if terminal_name is an empty string. (_initialize_infcmd): Make the argument of "set inferior-tty" optional, mention it in the help doc. gdb/doc/ChangeLog: * gdb.texinfo (Input/Output): Mention possibility to unset inferior-tty. gdb/testsuite/ChangeLog: * gdb.base/set-inferior-tty.exp: New file. * gdb.base/set-inferior-tty.c: New file.
2016-08-23Fix PR20494 - User input stops being echoed in CLIPedro Alves3-0/+163
This patch fixes a problem that problem triggers if you start an inferior, e.g., with the "start" command, in a UI created with the new-ui command, and then run a foreground execution command in the main UI. Once the program stops for the latter command, typing in the main UI no longer echoes back to the user. The problem revolves around this: - gdb_has_a_terminal computes its result lazily, on first call. that is what saves gdb's initial main UI terminal state (the UI associated with stdin): our_terminal_info.ttystate = serial_get_tty_state (stdin_serial); This is the state that target_terminal_ours() restores. - In this scenario, the gdb_has_a_terminal function happens to be first ever called from within the target_terminal_init call in startup_inferior: (top-gdb) bt #0 gdb_has_a_terminal () at src/gdb/inflow.c:157 #1 0x000000000079db22 in child_terminal_init_with_pgrp () at src/gdb/inflow.c:217 [...] #4 0x000000000065bacb in target_terminal_init () at src/gdb/target.c:456 #5 0x00000000004676d2 in startup_inferior () at src/gdb/fork-child.c:531 [...] #7 0x000000000046b168 in linux_nat_create_inferior () at src/gdb/linux-nat.c:1112 [...] #9 0x00000000005f20c9 in start_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:657 If the command to start the inferior is issued on the main UI, then readline will have deprepped the terminal when we reach the above, and the problem doesn't appear. If however the command is issued on a non-main UI, then when we reach that gdb_has_a_terminal call, the main UI's terminal state is still set to whatever readline has sets it to in rl_prep_terminal, which happens to have echo disabled. Later, when the following synchronous execution command finishes, we'll call target_terminal_ours to restore gdb's the main UI's terminal settings, and that restores the terminal state with echo disabled... Conceptually, the fix is to move the gdb_has_a_terminal call earlier, to someplace during GDB initialization, before readline/ncurses have had a chance to change terminal settings. Turns out that "set_initial_gdb_ttystate" is exactly such a place. I say conceptually, because the fix actually inlines the gdb_has_a_terminal part that saves the terminal state in set_initial_gdb_ttystate and then simplifies gdb_has_a_terminal, since there's no point in making gdb_has_a_terminal do lazy computation. gdb/ChangeLog: 2016-08-23 Pedro Alves <palves@redhat.com> PR gdb/20494 * inflow.c (our_terminal_info, initial_gdb_ttystate): Update comments. (enum gdb_has_a_terminal_flag_enum, gdb_has_a_terminal_flag): Delete. (set_initial_gdb_ttystate): Record our_terminal_info here too, instead of ... (gdb_has_a_terminal): ... here. Reimplement in terms of initial_gdb_ttystate. Make static. * terminal.h (gdb_has_a_terminal): Delete declaration. (set_initial_gdb_ttystate): Add comment. * top.c (show_interactive_mode): Use input_interactive_p instead of gdb_has_a_terminal. gdb/testsuite/ChangeLog: 2016-08-23 Pedro Alves <palves@redhat.com> PR gdb/20494 * gdb.base/new-ui-echo.c: New file. * gdb.base/new-ui-echo.exp: New file.
2016-08-23gdbserver_spawn "" rather than gdbserver_spawn ${binfile}Yao Qi3-2/+9
Hi, I happen to see gdbserver is spawned like this in gdb.log, spawn /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../../gdb/gdbserver/gdbserver --once :2346 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.s erver/connect-stopped-target/connect-stopped-target /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/connect-stopped-target/connect-stopped-t arget spawn /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../../gdb/gdbserver/gdbserver --once :2347 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.s erver/connect-stopped-target/connect-stopped-target /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/connect-stopped-target/connect-stopped-t arget as we can see, there are two instances of connect-stopped-target or connect-stopped-target in the command line spawning gdbserver, but none of these gets parameters from command line. In these two tests, gdbserver is spawned via "gdbserver_spawn ${binfile}". However, the argument of gdbserver_spawn is the argument passed the child inferior, not the program itself. # Start a gdbserver process running SERVER_EXEC, and connect GDB # to it. CHILD_ARGS are passed to the inferior. # # Returns the target protocol and socket to connect to. proc gdbserver_spawn { child_args } { set target_exec [gdbserver_download_current_prog] GDBserver gets the program via last_loaded_file, which is set by gdb_file_cmd. In each test, we don't need to pass ${binfile}. gdb/testsuite: 2016-08-23 Yao Qi <yao.qi@linaro.org> * gdb.server/connect-stopped-target.exp (do_test): Pass "" to gdbserver_spawn. * gdb.server/connect-without-multi-process.exp (do_test): Likewise.
2016-08-23Fix signals-state-child.exp in remote testingYao Qi2-6/+29
Remote testing isn't considered in signals-state-child.exp, so the it fails like shell diff -s /scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/testsuite/outputs/gdb.base/signals-state-child/standalone.txt /scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/testsuite/outputs/gdb.base/signals-state-child/gdb.txt^M diff: /scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/testsuite/outputs/gdb.base/signals-state-child/standalone.txt: No such file or directory^M (gdb) FAIL: gdb.base/signals-state-child.exp: signals states are identical This patch is to fix it. gdb/testsuite: 2016-08-23 Yao Qi <yao.qi@linaro.org> * gdb.base/signals-state-child.exp: Set variables gdb_txt and standalone_txt. Delete gdb_txt and standalone_txt on host and target. Spawn the binary on target. Copy files from target to host.
2016-08-22Fix PR gdb/20505 - Make vDSO detection work with core filesPedro Alves2-24/+59
Loading a core dump that was either generated on a system running pristine glibc master, or on a Fedora/RHEL system with LD_DEBUG=unused set in the environment, solib-svr4.c:svr4_current_sos fails to filter out the vDSO, resulting in: (gdb) core-file corefile.core^M [New LWP 2362]^M warning: Could not load shared library symbols for linux-vdso.so.1.^M Do you need "set solib-search-path" or "set sysroot"?^M Core was generated by `build-gdb/gdb/testsuite/outputs/gdb.base/corefile/'.^M ... The problem is that gdbarch_vsyscall_range does not support core inferiors at all. When live debugging, we're finding the vDSO's start address with auxv/AT_SYSINFO_EHDR, and then we find the vDSO's size by look for the corresponding mapping, by parsing /proc/PID/maps. When debugging a core dump, we can also determine the starting address from auxv/AT_SYSINFO_EHDR. However, we obviously can't read the core mappings out of the host's /proc. But we can instead look for a corresponding load segment in the core's bfd. gdb/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * linux-tdep.c (linux_vsyscall_range_raw): For core inferiors, find the vDSO's start address with AT_SYSINFO_EHDR too, and determine the vDSO's size by finding the PT_LOAD segment that matches AT_SYSINFO_EHDR. gdb/testsuite/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * gdb.base/vdso-warning.exp: Test core dumps too. Use with_test_prefix. Factor out bits to ... (test_no_vdso): ... this new procedure.
2016-08-19Fix missing files for ld when test suite not compiled in the source directoryCarl E. Love7-22/+23
This patch fixes an issues with six test suite expect files that do not run correctly when the test suite is not built in the source directory. The issue is these tests are not using the current "standard_testfile" call but rather using the older set command to initialize the "testfile", "srcfile" and "binprefix" variables or are missing the set for the "binprefix" variable. ----------------------------------------------- gdb/testsuite/ChangeLog 2016-08-19 Carl Love <cel@us.ibm.com> * gdb.arch/altivec-regs.exp: Use standard_testfile instead of maintaining separate logic for constructing the output path. * gdb.arch/powerpc-d128-regs.exp: Likewise. * gdb.arch/ppc-dfp.exp: Likewise. * gdb.arch/ppc-fp.exp: Likewise. * gdb.arch/vsx-regs.exp: Likewise. * gdb.arch/altivec-abi.exp: Likewise, plus added local variable binprefix for generating the additional binary files.
2016-08-19x32: Fix gdb.trace/mi-trace-frame-collected.expPedro Alves2-2/+17
gdb.trace/mi-trace-frame-collected.exp has a couple failures on x32: FAIL: gdb.trace/mi-trace-frame-collected.exp: live: -trace-frame-collected (register) FAIL: gdb.trace/mi-trace-frame-collected.exp: tfile: -trace-frame-collected (register) gdb.log: -trace-frame-collected ^done,explicit-variables=[{name="gdb_char_test",value="0 '\\000'"}],computed-expressions=[],registers=[{number="16",value="0x4004dc"},{number="204",value="0x4004dc"}],tvars =[],memory=[{address="0x00601060",length="1"}] (gdb) FAIL: gdb.trace/mi-trace-frame-collected.exp: live: -trace-frame-collected (register) [...] -trace-frame-collected ^done,explicit-variables=[{name="gdb_char_test",value="0 '\\000'"}],computed-expressions=[],registers=[{number="16",value="0x4004dc"},{number="204",value="0x4004dc"}],tvars =[],memory=[{address="0x00601060",length="1"}] (gdb) FAIL: gdb.trace/mi-trace-frame-collected.exp: tfile: -trace-frame-collected (register) This test only collects the PC, and thus expects to only see one register in the output of -trace-frame-collected. However, while on the 64-bit ABI gdb only exposes 64-bit $pc/$rip (register 16 above), on x32, GDB exposes 32-bit $eip as well, as a pseudo-register (register 204 above). Thus, collecting $pc/$rip automatically always collects $eip as well. gdb/testsuite/ChangeLog: 2016-08-19 Pedro Alves <palves@redhat.com> * gdb.trace/mi-trace-frame-collected.exp (test_trace_frame_collected): On x32, expect two registers.
2016-08-18Add ChangeLog updates to my previous two commitsCarl E. Love1-0/+6
gdb/ChangeLog: * MAINTAINERS (Write After Approval): Add "Carl Love". gdb/testsuite/ChangeLog: * gdb.arch/powerpc-power.s: Add new Power9 instruction tests and sync up the test with tests in gas/testsuite/gas/ppc. * gdb.arch/powerpc-power.exp: Likewise.
2016-08-18Fix for powerpc-power.exp gdb regression test for Power 9Carl Love2-505/+2717
The GDB testsuite reports 5 test failures on Power 7 instructions. Additionally the ppc test is missing the new Power 9 instructions as well as a large number of older instructions. Additionally, some instruction names have changed or been deleted. This patch fixes the test failures and completely updates the test to make it consistent with the supported Power 9 instructions listed in: gas/testsuite/gas/ppc/power7.d gas/testsuite/gas/ppc/power8.d gas/testsuite/gas/ppc/power9.d gas/testsuite/gas/ppc/altivec.d gas/testsuite/gas/ppc/altivec2.d gas/testsuite/gas/ppc/altivec3.d gas/testsuite/gas/ppc/vsx.d gas/testsuite/gas/ppc/vsx2.d gas/testsuite/gas/ppc/vsx3.d ----------------------------------------------------- gdb/testsuite/ChangeLog 2016-08-18 Carl Love <cel@us.ibm.com> * gdb.arch/powerpc-power.s: Add new Power9 instruction tests and sync up the test with tests in gas/testsuite/gas/ppc. * gdb.arch/powerpc-power.exp: Likewise.
2016-08-17Fix remove-inferior error messageSimon Marchi2-1/+6
This error message should not contain the word symbol: (gdb) remove-inferiors 1 Warning: Can not remove current symbol inferior 1. gdb/ChangeLog: * inferior.c (remove_inferior_command): Fix error message. gdb/testsuite/ChangeLog: * gdb.multi/remove-inferiors.exp (test_remove_inferiors): Fix expected error message.
2016-08-17Add remove-inferiors testSimon Marchi3-0/+98
I noticed that the remove-inferiors command was not tested, and as I am doing some changes related to the user selection, I want to make sure I don't break it. For example, I want to make sure it's not possible to remove the current inferior. gdb/testsuite/ChangeLog: * gdb.multi/remove-inferiors.exp: New file. * gdb.multi/remove-inferiors.c: New file.
2016-08-12Fix warning in gdb.base/signals-state-child.cYao Qi2-1/+6
I see the following warning when running signals-state-child.exp. gdb/testsuite/gdb.base/signals-state-child.c:77:4: warning: too many arguments for format [-Wformat-extra-args] fprintf (out, "sigaction={sa_handler=", i); ^ this patch is to remove the argument from fprintf. gdb/testsuite: 2016-08-12 Yao Qi <yao.qi@linaro.org> * gdb.base/signals-state-child.c (main): Remove "i" from fprintf's argument list.
2016-08-10Fix PR gdb/19187 (process record over a fork causes internal error)Pedro Alves2-2/+8
Right after a fork is detected, we detach breakpoints from the child (detach_breakpoints), which calls into target_remove_breakpoint with inferior_ptid pointing at the child process, but leaves the breakpoint marked inserted (in the parent). The problem is that record-full.c always deletes all knowledge of the breakpoint. Then when we later really delete the breakpoint from the parent, we fail the assertion, since the breakpoint is unexpectedly not found in the record-full.c breakpoint table. The fix is simply to not forget about the breakpoint if we're detaching it from a fork child. gdb/ChangeLog: 2016-08-10 Pedro Alves <palves@redhat.com> PR gdb/19187 * record-full.c (record_full_remove_breakpoint): Don't remove the breakpoint from the record_full_breakpoints VEC if we're detaching the breakpoint from a fork child. gdb/testsuite/ChangeLog: 2016-08-10 Pedro Alves <palves@redhat.com> PR gdb/19187 * gdb.reverse/waitpid-reverse.exp: Add comment and remove setup_kfails.
2016-08-09Fix PR gdb/20418 - Problems with synchronous commands and new-uiPedro Alves4-2/+148
When executing commands on a secondary UI running the MI interpreter, some commands that should be synchronous are not. MI incorrectly continues processing input right after the synchronous command is sent, before the target stops. The problem happens when we emit MI async events (=library-loaded, etc.), and we go about restoring the previous terminal state, we end up calling target_terminal_ours, which incorrectly always installs the current UI's input_fd in the event loop... That is, code like this: old_chain = make_cleanup_restore_target_terminal (); target_terminal_ours_for_output (); fprintf_unfiltered (mi->event_channel, "library-loaded"); ... do_cleanups (old_chain); The fix is to move the add_file_handler/delete_file_handler calls out of target_terminal_$foo, making these completely no-ops unless called with the main UI as current UI. gdb/ChangeLog: 2016-08-09 Pedro Alves <palves@redhat.com> PR gdb/20418 * event-top.c (ui_register_input_event_handler) (ui_unregister_input_event_handler): New functions. (async_enable_stdin): Register input in the event loop. (async_disable_stdin): Unregister input from the event loop. (gdb_setup_readline): Register input in the event loop. * infrun.c (check_curr_ui_sync_execution_done): Register input in the event loop. * target.c (target_terminal_inferior): Don't unregister input from the event loop. (target_terminal_ours): Don't register input in the event loop. * target.h (target_terminal_inferior) (target_terminal_ours_for_output, target_terminal_ours): Update comments. * top.h (ui_register_input_event_handler) (ui_unregister_input_event_handler): New declarations. * utils.c (ui_unregister_input_event_handler_cleanup) (prepare_to_handle_input): New functions. (defaulted_query, prompt_for_continue): Use prepare_to_handle_input. gdb/testsuite/ChangeLog: 2016-08-09 Pedro Alves <palves@redhat.com> Simon Marchi <simon.marchi@ericsson.com> PR gdb/20418 * gdb.mi/new-ui-mi-sync.c, gdb.mi/new-ui-mi-sync.exp: New files. * lib/mi-support.exp (mi_expect_interrupt): Remove anchors.
2016-08-09Fix PR mi/20431 - Missing MI prompts after sync execution MI command ↵Pedro Alves2-0/+85
(-exec-continue, etc.) errors gdb 7.11 introduced an MI regression: a failing MI sync execution command misses printing the MI prompt, and then all subsequent command miss it too: $ gdb-7.11.1 -i=mi [...] p 1 &"p 1\n" ~"$1 = 1" ~"\n" ^done (gdb) <<< prompted ok -exec-continue ^error,msg="The program is not being run." <<< missing prompt after this print 1 &"print 1\n" ~"$2 = 1" ~"\n" ^done <<< missing prompt after this gdb 7.10.1 behaved correctly, even with "set mi-async on": -exec-continue ^error,msg="The program is not being run." (gdb) <<< prompted ok etc. Bisecting points at: commit 0b333c5e7d6c Author: Pedro Alves <palves@redhat.com> Date: Wed Sep 9 18:23:23 2015 +0100 Merge async and sync code paths some more [...] The problem is that when an exception is thrown, we leave the prompt state set to PROMPT_BLOCKED, and then mi_execute_command_input_handler doesn't print the prompt. It used to work because before that patch, we happened to skip disabling stdin if the current target didn't do async (which it never does before execution). I was surprised to find that this bug isn't caught by the testsuite, so I made a thorough test that tests all combinations of pairs of: - a failing synchronous execution command - a failing non-execution command - a non-failing command gdb/ChangeLog: 2016-08-09 Pedro Alves <palves@redhat.com> PR mi/20431 * mi/mi-main.c (mi_execute_command): Enable input and set prompt state to PROMPT_NEEDED. gdb/testsuite/ChangeLog: 2016-08-09 Pedro Alves <palves@redhat.com> PR mi/20431 * gdb.mi/mi-cmd-error.exp: New file.
2016-08-09Fix PR gdb/18653: gdb disturbs inferior's inherited signal dispositionsPedro Alves4-0/+194
gdb's (or gdbserver's) own signal handling should not interfere with the signal dispositions their spawned children inherit. However, it currently does. For example, some paths in gdb cause SIGPIPE to be set to SIG_IGN, and as consequence, the child starts with SIGPIPE to set to SIG_IGN too, even though gdb was started with SIGPIPE set to SIG_DFL. This is because the exec family of functions does not reset the signal disposition of signals that are set to SIG_IGN: http://pubs.opengroup.org/onlinepubs/7908799/xsh/execve.html Signals set to the default action (SIG_DFL) in the calling process image are set to the default action in the new process image. Signals set to be ignored (SIG_IGN) by the calling process image are set to be ignored by the new process image. Signals set to be caught by the calling process image are set to the default action in the new process image (see <signal.h>). And neither does it reset signal masks or flags. In order to be transparent, when spawning new child processes to debug (with "run", etc.), reset signal actions and mask back to what was originally inherited from gdb/gdbserver's parent, just before execing the target program to debug. gdb/ChangeLog: 2016-08-09 Pedro Alves <palves@redhat.com> PR gdb/18653 * Makefile.in (SFILES): Add common/signals-state-save-restore.c. (HFILES_NO_SRCDIR): Add common/signals-state-save-restore.h. (COMMON_OBS): Add signals-state-save-restore.o. (signals-state-save-restore.o): New rule. * configure: Regenerate. * fork-child.c: Include "signals-state-save-restore.h". (fork_inferior): Call restore_original_signals_state. * main.c: Include "signals-state-save-restore.h". (captured_main): Call save_original_signals_state. * common/common.m4: Add sigaction to AC_CHECK_FUNCS checks. * common/signals-state-save-restore.c: New file. * common/signals-state-save-restore.h: New file. gdb/gdbserver/ChangeLog: 2016-08-09 Pedro Alves <palves@redhat.com> PR gdb/18653 * Makefile.in (OBS): Add signals-state-save-restore.o. (signals-state-save-restore.o): New rule. * config.in: Regenerate. * configure: Regenerate. * linux-low.c: Include "signals-state-save-restore.h". (linux_create_inferior): Call restore_original_signals_state. * server.c: Include "dispositions-save-restore.h". (captured_main): Call save_original_signals_state. gdb/testsuite/ChangeLog: 2016-08-09 Pedro Alves <palves@redhat.com> PR gdb/18653 * gdb.base/signals-state-child.c: New file. * gdb.base/signals-state-child.exp: New file. * gdb.gdb/selftest.exp (do_steps_and_nexts): Add new pattern.
2016-08-09Fix PR gdb/20295: GDB segfaults printing bitfield member of optimized out valuePedro Alves2-0/+91
With something like: struct A { int bitfield:4; } var; If 'var' ends up wholly-optimized out, printing 'var.bitfield' crashes gdb here: (top-gdb) bt #0 0x000000000058b89f in extract_unsigned_integer (addr=0x2 <error: Cannot access memory at address 0x2>, len=2, byte_order=BFD_ENDIAN_LITTLE) at /home/pedro/gdb/mygit/src/gdb/findvar.c:109 #1 0x00000000005a187a in unpack_bits_as_long (field_type=0x16cff70, valaddr=0x0, bitpos=16, bitsize=12) at /home/pedro/gdb/mygit/src/gdb/value.c:3347 #2 0x00000000005a1b9d in unpack_value_bitfield (dest_val=0x1b5d9d0, bitpos=16, bitsize=12, valaddr=0x0, embedded_offset=0, val=0x1b5d8d0) at /home/pedro/gdb/mygit/src/gdb/value.c:3441 #3 0x00000000005a2a5f in value_fetch_lazy (val=0x1b5d9d0) at /home/pedro/gdb/mygit/src/gdb/value.c:3958 #4 0x00000000005a10a7 in value_primitive_field (arg1=0x1b5d8d0, offset=0, fieldno=0, arg_type=0x16d04c0) at /home/pedro/gdb/mygit/src/gdb/value.c:3161 #5 0x00000000005b01e5 in do_search_struct_field (name=0x1727c60 "bitfield", arg1=0x1b5d8d0, offset=0, type=0x16d04c0, looking_for_baseclass=0, result_ptr=0x7fffffffcaf8, [...] unpack_value_bitfield is already optimized-out/unavailable -aware: (...) VALADDR points to the contents of VAL. If the VAL's contents required to extract the bitfield from are unavailable/optimized out, DEST_VAL is correspondingly marked unavailable/optimized out. however, it is not considering the case of the value having no contents buffer at all, as can happen through allocate_optimized_out_value. gdb/ChangeLog: 2016-08-09 Pedro Alves <palves@redhat.com> * value.c (unpack_value_bitfield): Skip unpacking if the parent has no contents buffer to begin with. gdb/testsuite/ChangeLog: 2016-08-09 Pedro Alves <palves@redhat.com> * gdb.dwarf2/bitfield-parent-optimized-out.exp: New file.
2016-08-03PR python/18565 - make Frame.function work for inline framesTom Tromey2-0/+9
PR python/18565 notes that calling frame filters don't work properly for inlined functions. This happens because Frame.function on an inline frame will yield the wrong result. This patch changes this code to use find_frame_funname instead, which handles inline frames properly. Built and regtested on x86-64 Fedora 24. 2016-08-03 Tom Tromey <tom@tromey.com> PR python/18565: * python/py-frame.c (frapy_function): Use find_frame_funname. 2016-08-03 Tom Tromey <tom@tromey.com> PR python/18565: * gdb.python/py-frame-inline.exp: Add Frame.function test.
2016-08-01Swap "single-process" and "multi-process" in process-dies-while-detaching.expgdb-7.12-branchpointYao Qi2-1/+7
"single-process" and "multi-process" are used in the test message of process-dies-while-detaching.exp, but they are misplaced due to set mode [expr {$multi_process ? "single-process" : "multi-process"}] This patch is to swap them. gdb/testsuite: 2016-08-01 Yao Qi <yao.qi@linaro.org> * gdb.threads/process-dies-while-detaching.exp (do_test): Set variable mode to "multi-process" if $multi_process is 1, otherwise set it to "single-process".
2016-08-01Tweak gdb.cp tests for aarch32Yao Qi4-5/+11
There are some gdb.cp/ tests fails if the program is compiled for arm 32-bit but GDB/GDBserver is aarch64 64-bit program, because target triplet doesn't match "arm*-*-*". Instead, we can use is_aarch32_target. gdb/testsuite: 2016-08-01 Yao Qi <yao.qi@linaro.org> * gdb.cp/anon-struct.exp: Check is_aarch32_target. * gdb.cp/cpexprs.exp: Likewise. * gdb.cp/m-static.exp: Likewise.
2016-07-26PR python/20190 - compute TLS symbol without a frameTom Tromey2-0/+23
PR python/20190 arose from an exception I noticed when trying to use the Python unwinder for Spider Monkey in Firefox. The problem is that the unwinder wants to examine the value of a thread-local variable. However, sympy_value rejects this because symbol_read_needs_frame returns true for a TLS variable. This problem arose once before, though in a different context: https://sourceware.org/bugzilla/show_bug.cgi?id=11803 At the time Pedro and Daniel pointed out a simpler way to fix that bug (see links in 20190 if you are interested); but for this new bug I couldn't think of a similar fix and ended up implementing Daniel's other suggestion: https://sourceware.org/ml/gdb-patches/2010-07/msg00393.html That is, this patch makes it possible to detect whether a symbol needs a specific frame, or whether it just needs the inferior to have registers. Built and regtested on x86-64 Fedora 24. 2016-07-26 Tom Tromey <tom@tromey.com> * symtab.c (register_symbol_computed_impl): Update. PR python/20190: * value.h (symbol_read_needs): Declare. (symbol_read_needs_frame): Add comment. * symtab.h (struct symbol_computed_ops) <read_variable>: Update comment. <get_symbol_read_needs>: Rename. Change return type. * findvar.c (symbol_read_needs): New function. (symbol_read_needs_frame): Rewrite. (default_read_var_value): Use symbol_read_needs. * dwarf2loc.c (struct symbol_needs_baton): Rename. <needs>: Renamed from needs_frame. Changed type. (needs_frame_read_addr_from_reg, symbol_needs_get_reg_value) (symbol_needs_read_mem, symbol_needs_frame_base) (symbol_needs_frame_cfa, symbol_needs_tls_address) (symbol_needs_dwarf_call): Rename. (needs_dwarf_reg_entry_value): Update. (symbol_needs_ctx_funcs, dwarf2_loc_desc_get_symbol_read_needs): Rename and update. (locexpr_get_symbol_read_needs, loclist_symbol_needs): Likewise. (dwarf2_locexpr_funcs, dwarf2_loclist_funcs): Update. * defs.h (enum symbol_needs_kind): New. 2016-07-26 Tom Tromey <tom@tromey.com> PR python/20190: * gdb.threads/tls.exp (check_thread_local): Add python symbol test.
2016-07-26btrace, testsuite: fix assembly source file selectionMarkus Metzger5-18/+42
Some btrace tests use assembly source files. They use the target triplet to distinguish between x86_64 and ia32 ISA. This does not work for -m32 tests without setting the target triplet to i686-?-?. Instead use is_amd64_regs_target to distinguish between x86_64 and ia32 ISA. See also https://sourceware.org/ml/gdb-patches/2016-07/msg00256.html. testsuite/ * gdb.btrace/record_goto.exp: Use is_amd64_regs_target for selecting assembly source files. * gdb.btrace/stepi.exp: Use is_amd64_regs_target for selecting assembly source files. * gdb.btrace/tailcall.exp: Use is_amd64_regs_target for selecting assembly source files. * gdb.btrace/tailcall-only.exp: Use is_amd64_regs_target for selecting assembly source files.
2016-07-25Handle correctly passing a bad interpreter name to new-uiSimon Marchi2-1/+33
When a bad interpreter name is passed to new-ui, such as: (gdb) new-ui bloop /dev/pts/10 A partially created UI is left in the UI list, with interp set to NULL. Trying to do anything that will print on this UI (such as "start") will cause a segmentation fault. Changes in v2: - Use with_test_prefix to namespace test procedures - Give an explicit stable test name - Add a "bad terminal path" test - Remove useless runto_main - Add missing intro comments I did not factor out the pty spawn, as there is some magic involved I don't quite understand. But it wouldn't bring that much anyway. gdb/ChangeLog: * top.h (make_delete_ui_cleanup): New declaration. * top.c (delete_ui_cleanup): New function. (make_delete_ui_cleanup): New function. (new_ui_command): Create restore_ui cleanup earlier, create a delete_ui cleanup and discard it on success. gdb/testsuite/ChangeLog: * gdb.base/new-ui.exp (do_test_invalid_args): New procedure.
2016-07-25btrace: Resume recording after disconnect.Tim Wiederhake3-0/+109
This patch allows gdbserver to continue recording after disconnect. On reconnect, the recorded data is accessible to gdb as if no disconnect happened. A possible application for this feature is remotely examine bugs that occur at irregular intervals, where maintaining a gdb connection is inconvenient. This also fixes the issue mentioned here: https://sourceware.org/ml/gdb-patches/2015-11/msg00424.html Signed-off-by: Tim Wiederhake <tim.wiederhake@intel.com> gdb/ChangeLog: * NEWS: Resume btrace on reconnect. * record-btrace.c: Added record-btrace.h include. (record_btrace_open): Split into this and ... (record_btrace_push_target): ... this. (record_btrace_disconnect): New function. (init_record_btrace_ops): Use record_btrace_disconnect. * record-btrace.h: New file. * remote.c: Added record-btrace.h include. (remote_start_remote): Check recording status. (remote_btrace_maybe_reopen): New function. gdb/doc/ChangeLog: * gdb.texinfo: Resume btrace on reconnect. gdb/testsuite/ChangeLog: * gdb.btrace/reconnect.c: New file. * gdb.btrace/reconnect.exp: New file. Change-Id: I95e8b0ab8a89e58591aba0e63818cee82fd211bc
2016-07-23Implement catch syscall groupGabriel Krisman Bertazi2-0/+45
Implement support to add catchpoints for a group of related syscalls using the syntax: (gdb) catch syscall group:<group> or (gdb) catch syscall g:<group> Several groups are predefined in the xml files for all architectures supported by GDB over Linux. They are based on the groups defined by strace. gdb/ * xml-syscall.c (get_syscalls_by_group): New. (get_syscall_group_names): New. (struct syscall_group_desc): New structure to store group data. (struct syscalls_info): Include field to store the group list. (sysinfo_free_syscall_group_desc): New. (free_syscalls_info): Free group list. (syscall_group_create_syscall_group_desc): New. (syscall_group_add_syscall): New. (syscall_create_syscall_desc): Add syscall to its groups. (syscall_start_syscall): Load group attribute. (syscall_group_get_group_by_name): New. (xml_list_syscalls_by_group): New. (xml_list_of_groups): New. * xml-syscall.h (get_syscalls_by_group): Export function to retrieve a list of syscalls filtered by the group name. (get_syscall_group_names): Export function to retrieve the list of syscall groups. * break-catch-syscall.c (catch_syscall_split_args): Verify if argument is a syscall group and expand it to a list of syscalls when creating catchpoints. (catch_syscall_completer): Add word completion for system call groups. * configure.ac: Include dependency for xsltproc when building in maintainer-mode. * break-catch-syscall.c (_initialize_breakpoint): Update catch syscall command documentation. * NEWS: Include section about catching groups of syscalls. * configure: Regenerate. * data-directory/Makefile.in: Generate syscall xml when building in maintainer mode. * syscalls/gdb-syscalls.dtd: Include group attribute to the syscall element. * syscalls/apply-defaults.xsl: New. * syscalls/linux-defaults.xml.in: New. * syscalls/aarch64-linux.xml: Rename to aarch64-linux.xml.in. * syscalls/amd64-linux.xml: Rename to amd64-linux.xml.in. * syscalls/arm-linux.xml: Rename to arm-linux.xml.in. * syscalls/bfin-linux.xml: Rename to bfin-linux.xml.in. * syscalls/i386-linux.xml: Rename to i386-linux.xml.in. * syscalls/mips-n32-linux.xml: Rename to mips-n32-linux.xml.in. * syscalls/mips-n64-linux.xml: Rename to mips-n64-linux.xml.in. * syscalls/mips-o32-linux.xml: Rename to mips-o32-linux.xml.in. * syscalls/ppc-linux.xml: Rename to ppc-linux.xml.in. * syscalls/ppc64-linux.xml: Rename to ppc64-linux.xml.in. * syscalls/s390-linux.xml: Rename to s390-linux.xml.in. * syscalls/s390x-linux.xml: Rename to s390x-linux.xml.in. * syscalls/sparc-linux.xml: Rename to sparc-linux.xml.in. * syscalls/sparc64-linux.xml: Rename to sparc64-linux.xml.in. * syscalls/aarch64-linux.xml: Regenerate. * syscalls/amd64-linux.xml: Regenerate. * syscalls/arm-linux.xml: Regenerate. * syscalls/i386-linux.xml: Regenerate. * syscalls/mips-n32-linux.xml: Regenerate. * syscalls/mips-n64-linux.xml: Regenerate. * syscalls/mips-o32-linux.xml: Regenerate. * syscalls/ppc-linux.xml: Regenerate. * syscalls/ppc64-linux.xml: Regenerate. * syscalls/s390-linux.xml: Regenerate. * syscalls/s390x-linux.xml: Regenerate. * syscalls/sparc-linux.xml: Regenerate. * syscalls/sparc64-linux.xml: Regenerate. gdb/testsuite/ * gdb.base/catch-syscall.exp (do_syscall_tests): Add call to test_catch_syscall_group. (test_catch_syscall_group): New. gdb/doc/ * gdb.texinfo (Set Catchpoints): Add 'group' argument to catch syscall.
2016-07-21Allow empty struct expressions in RustTom Tromey3-0/+9
I learned recently that empty struct expressions, like "X{}", have been promoted from experimental to stable in Rust. This patch changes the Rust expression parser to allow this case. New test case included. Built and regtested on x86-64 Fedora 23, using Rust 1.11 beta. 2016-07-21 Tom Tromey <tom@tromey.com> * rust-lang.c (rust_tuple_struct_type_p): Return false for empty structs. * rust-exp.y (struct_expr_list): Allow empty elements. 2016-07-21 Tom Tromey <tom@tromey.com> * gdb.rust/simple.rs (main): Use empty struct expression. * gdb.rust/simple.exp: Add tests for empty struct expression.
2016-07-21Skip gdb.server/ tests if lack of XML supportYao Qi2-0/+19
I recently see some gdb.server/*.exp fails in my native gdb testing, in which libexpat isn't available, so GDB isn't able to parse xml file. It causes gdb.server/ tests fails because GDB can't get registers correctly from GDBserver. (gdb) PASS: gdb.server/connect-without-multi-process.exp: multiprocess=off: break main target remote localhost:2352^M Remote debugging using localhost:2352^M warning: Can not parse XML target description; XML support was disabled at compile time^M Reading /lib/ld-linux-armhf.so.3 from remote target...^M warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.^M Reading /lib/ld-linux-armhf.so.3 from remote target...^M Reading symbols from target:/lib/ld-linux-armhf.so.3...Reading /lib/ld-2.17.so.debug from remote target...^M Reading /lib/.debug/ld-2.17.so.debug from remote target...^M (no debugging symbols found)...done.^M Remote 'g' packet reply is too long: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000efffbe00000000808d0f4d100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000^ 0x4d0f8d80 in _start () from target:/lib/ld-linux-armhf.so.3^M Without XML support in GDB, it can't parse xml sent by GDBserver, and has to fall back to the oldest arch. However, GDBserver doesn't know this (IMO, this is a defect in RSP), and still choose the right target description to create regcache and 'g' packet. If the port only has one target description or coincidentally two sides choose the same target description, there is no such issue. Otherwise, GDB is broken on read registers. This patch is to skip gdbserver tests if XML is not support and the target has multiple target descriptions. gdb/testsuite: 2016-07-21 Yao Qi <yao.qi@linaro.org> * lib/gdbserver-support.exp (skip_gdbserver_tests): Return 1 if gdb_skip_xml_test is true on some targets.
2016-07-21Fix fail in gdb.server/solib-list.expYao Qi2-0/+9
If I run single test solib-list.exp, it is OK. If I run two, as below, there are fails, $ make check RUNTESTFLAGS="server-run.exp solib-list.exp" FAIL: gdb.server/solib-list.exp: non-stop 0: continue (the program exited) FAIL: gdb.server/solib-list.exp: non-stop 0: p libvar FAIL: gdb.server/solib-list.exp: non-stop 1: continue (the program exited) FAIL: gdb.server/solib-list.exp: non-stop 1: p libvar in gdb.log, /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../../gdb/gdbserver/gdbserver --once :2347 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/server-run/server-run /lib64/ld-linux-x86-64.so.2 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/solib-list/solib-list server-run is spawned, which is wrong. If I only run solib-list.exp, ld-linux is spawned, which is right. /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../../gdb/gdbserver/gdbserver --once :2346 /lib64/ld-linux-x86-64.so.2 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/solib-list/solib-list in test, we spawn gdbserver this way, # Note we pass ${interp_system}, the program gdbserver spawns, as # argument here, instead of using gdb_load, because we don't want # to download the interpreter to the target (it's already there) # or to the test output directory. set res [gdbserver_spawn "${interp_system} ${remote_binfile}"] in gdbserver_spawn -> gdbserver_download_current_prog, if last_loaded_file is set (when you run multiple tests), it is returned. This patch is to unset last_loaded_file in solib-list.exp. gdb/testsuite: 2016-07-21 Yao Qi <yao.qi@linaro.org> * gdb.server/solib-list.exp: Unset last_loaded_file.
2016-07-20testsuite: Fix gdb.gdb/selftest.exp for C++-O2-g-built GDBJan Kratochvil2-0/+13
tested on Fedora 24 x86_64 after: ./configure; make That is: CFLAGS='-g -O2' CXXFLAGS='-g -O2' FAIL: gdb.gdb/selftest.exp: unknown source line FAIL: gdb.gdb/selftest.exp: step into xmalloc call gdb/testsuite/ChangeLog 2016-07-20 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.gdb/selftest.exp (do_steps_and_nexts): Add "next over TRY" and "step into captured_main (args)".
2016-07-20testsuite: Fix gdb.btrace/tailcall-only.exp errors on x86_64-m32Jan Kratochvil2-2/+6
$ runtest 'CC_FOR_TARGET=gcc -m32' gdb.btrace/tailcall-only.exp Running ./gdb.btrace/tailcall-only.exp ... gdb compile failed, tailcall-only.c: Assembler messages: tailcall-only.c:142: Error: cannot represent relocation type BFD_RELOC_64 [...] tailcall-only.c:425: Error: cannot represent relocation type BFD_RELOC_64 It works for the other x86 arch combinations: On Mon, 11 Apr 2016 08:44:23 +0200, Metzger, Markus T wrote: I'm setting the target triplet to "i686-unknown-linux" in my m32 configuration. Like this: set target_triplet "i686-unknown-linux" set_board_info cflags "-m32" set_board_info cppflags "-m32" On Wed, 20 Jul 2016 16:02:20 +0200, Pedro Alves wrote: There's no reason you should _not_ set it. But, multilib-style testing with --target_board=unix\{-m64,-m32\} etc. should work _too_, IMO. gdb/testsuite/ChangeLog 2016-07-20 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.btrace/tailcall-only.exp: Use is_lp64_target check.
2016-07-20testsuite patch: Skip py-unwind.exp on x86_64 -m32Jan Kratochvil2-1/+5
(gdb) source /home/jkratoch/redhat/gdb-clean/gdb/testsuite/outputs/gdb.python/py-unwind/py-unwind.py^M Python script imported^M Python Exception <type 'exceptions.ValueError'> Bad register: ^M (gdb) FAIL: gdb.python/py-unwind.exp: import python scripts class TestUnwinder(Unwinder): AMD64_RBP = 6 AMD64_RSP = 7 AMD64_RIP = 16 On Tue, 19 Jul 2016 12:06:09 +0200, Yao Qi wrote: py-unwind.exp does nothing on arch specific thing, so py-unwind.exp shouldn't be aware of the arch difference, but py-unwind.py should. On Tue, 19 Jul 2016 20:04:33 +0200, Pedro Alves wrote: How about we handle this in the .exp file for now and leave something more complicated for when the test is first ported to some other arch. WDYT? gdb/testsuite/ChangeLog 2016-07-20 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.python/py-unwind.exp: Test also ![is_lp64_target].
2016-07-19Build gdb.opt/inline-*.exp tests at -O0, rely on __attribute__((always_inline))Pedro Alves6-5/+21
A test recently added to gdb.opt/inline-cmds.exp fails for arm-none-eabi targets because -O2 leads to instructions to be reordered widely. I guess it might have made sense years ago to enable optimization in these tests, but I fail to see the need for that nowadays. Using -O0 while relying on __attribute__((always_inline)), which is already used in the tests [1] [2], avoids this sort of trouble, while still exercising the inlining-related use cases that are the focus of these tests. I think that nowadays we can safely assume that all compilers we care about support __attribute__((always_inline)) or similar. [1] - Except one spot that missed it. [2] - Note that the .exp files make sure the frames that should have been inlined are indeed inlined, with "info frame". gdb/testsuite/ChangeLog: 2016-07-19 Pedro Alves <palves@redhat.com> * gdb.opt/inline-break.exp: Remove optimize=-O2. * gdb.opt/inline-bt.exp: Likewise. * gdb.opt/inline-cmds.exp: Remove optimize=-O2 and add additional_flags=-Winline. * gdb.opt/inline-locals.exp: Likewise. * gdb.opt/inline-markers.c (ATTR): Define. (inlined_fn): Use it.
2016-07-19Use do_self_tests in selftest.expYao Qi2-105/+9
This patch uses do_self_tests to simplify selftest.exp. It doesn't change the tests except the order, -PASS: gdb.gdb/selftest.exp: Disassemble main PASS: gdb.gdb/selftest.exp: breakpoint in captured_main +PASS: gdb.gdb/selftest.exp: run until breakpoint at captured_main +PASS: gdb.gdb/selftest.exp: Disassemble main PASS: gdb.gdb/selftest.exp: set interrupt character in test_with_self PASS: gdb.gdb/selftest.exp: set listsize to 1 -PASS: gdb.gdb/selftest.exp: run until breakpoint at captured_main gdb/testsuite: 2016-07-19 Yao Qi <yao.qi@linaro.org> * gdb.gdb/selftest.exp: Remove checks on is_remote and isnative. (test_with_self): Remove some code. Remove argument executable. (top-level): Use do_self_tests.
2016-07-15GDB testsuite: Escape paths used in regular expressionsDon Breazeal3-7/+17
This patch fixes problems with a few GDB testsuites when executing in a path that contains special characters (e.g. "++"). When such paths are used as a regular expression, the regular expression parser will choke and cause the tests to fail. This patch uses string_to_regexp to escape strings that will be used as regular expressions, in order to sanitize path names used in expect scripts. 2016-07-15 Zachary Welch <zwelch@codesourcery.com> Don Breazeal <donb@codesourcery.com> gdb/testsuite/ChangeLog: * gdb.base/maint.exp: Escape paths used in regular expressions. * gdb.stabs/weird.exp: Likewise.
2016-07-13PR python/15620, PR python/18620 - breakpoint events in PythonTom Tromey2-0/+47
This patch adds some breakpoint events to Python. In particular, there is a creation event that is emitted when a breakpoint is created; a modification event that is emitted when a breakpoint changes somehow; and a deletion event that is emitted when a breakpoint is deleted. In this patch, the event's payload is the breakpoint itself. I considered making a new event type to hold the breakpoint, but I didn't see a need. Still, I thought I would mention this as a spot where some other choice is possible. Built and regtested on x86-64 Fedora 23. 2016-07-13 Tom Tromey <tom@tromey.com> PR python/15620, PR python/18620: * python/py-evts.c (gdbpy_initialize_py_events): Call add_new_registry for new events. * python/py-events.h (events_object) <breakpoint_created, breakpoint_deleted, breakpoint_modified>: New fields. * python/py-breakpoint.c (gdbpy_breakpoint_created): Emit the breakpoint changed event. (gdbpy_breakpoint_deleted): Emit the breakpoint deleted event. (gdbpy_breakpoint_modified): New function. (gdbpy_initialize_breakpoints): Attach to the breakpoint modified observer. 2016-07-13 Tom Tromey <tom@tromey.com> PR python/15620, PR python/18620: * python.texi (Events In Python): Document new breakpoint events. 2016-07-13 Tom Tromey <tom@tromey.com> PR python/15620, PR python/18620: * gdb.python/py-breakpoint.exp (connect_event, check_last_event) (test_bkpt_events): New procs.
2016-07-13PR python/17698 - add Breakpoint.pendingTom Tromey2-0/+19
This patch adds a "pending" attribute to gdb.Breakpoint. Built and regtested on x86-64 Fedora 23. 2016-07-13 Tom Tromey <tom@tromey.com> PR python/17698: * NEWS: Update. * python/py-breakpoint.c (bppy_get_pending): New function. (breakpoint_object_getset): Add entry for "pending". * breakpoint.h (pending_breakpoint_p): Declare. * breakpoint.c (pending_breakpoint_p): New function. 2016-07-13 Tom Tromey <tom@tromey.com> PR python/17698: * python.texi (Breakpoints In Python): Document Breakpoint.pending. 2016-07-13 Tom Tromey <tom@tromey.com> PR python/17698: * gdb.python/py-breakpoint.exp (test_bkpt_basic): Add "pending" test. (test_watchpoints): Likewise. (test_bkpt_pending): New proc.
2016-07-13Fix PR cli/18053Tom Tromey2-0/+13
PR cli/18053 concerns a couple of minor bugs in the JIT debuginfo support. First, jit-reader-load should use filename completion and support tilde expansion. Second, the help for jit-reader-unload is incorrect. While working on this I also realized that jit-reader-unload should use the no-op completer, so I've included that as well. Built and regtested on x86-64 Fedora 23. A completer test for jit-reader-load is included, but not a tilde-expansion test, as I couldn't think of a reliable way to test that. 2016-07-13 Tom Tromey <tom@tromey.com> PR cli/18053: * jit.c (jit_reader_load_command): Use tilde_expand. (_initialize_jit): Fix help for jit-reader-unload. Set completer for new commands. 2016-07-13 Tom Tromey <tom@tromey.com> PR cli/18053: * gdb.base/jit-so.exp (one_jit_test): Add jit-reader-load completion test.
2016-07-13[ppc64] Fix for function descriptorsJan Kratochvil6-13/+46
Marin Cermak has found various testcases (or one of them) of GDB FAIL on ppc64. https://sourceware.org/bugzilla/show_bug.cgi?id=20328 .o contained only the function descriptor address. The DWARF as produced by Tcl Dwarf::assemble: <1><27>: Abbrev Number: 4 (DW_TAG_subprogram) <28> DW_AT_name : main <2d> DW_AT_external : 1 <2e> DW_AT_low_pc : 0x1001ff98 <36> DW_AT_high_pc : 0x1002ff98 <2><3e>: Abbrev Number: 5 (DW_TAG_lexical_block) Runtime info: $2 = {<text variable, no debug info>} 0x10000674 <.main> $3 = {void ()} 0x1001ff98 <main> On Tue, 12 Jul 2016 15:22:49 +0200, Ulrich Weigand wrote: Well, most of the gdb.dwarf2 test cases simply use explicitly placed labels for the DW_AT_low_pc / DW_AT_high_pc attributes. See e.g. dw2-unresolved-main.c: asm (".globl cu_text_start"); asm ("cu_text_start:"); On Wed, 13 Jul 2016 10:54:00 +0200, Jan Kratochvil wrote: Now I see I should not do that because: lib/dwarf.exp: proc function_range { func src } { So I am providing this patch. gdb/testsuite/ChangeLog 2016-07-13 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.dwarf2/atomic-type.exp: Use function_range for low_pc and high_pc. * gdb.dwarf2/atomic.c (f): Rename f_end_lbl to f_label. * gdb.dwarf2/dw2-bad-mips-linkage-name.c (f): Rename f_end_lbl to f_label. (g): Rename g_end_lbl to g_label. * gdb.dwarf2/dw2-bad-mips-linkage-name.exp: Use function_range for low_pc and high_pc. * gdb.dwarf2/dw2-lexical-block-bare.exp: Likewise.
2016-07-12PR python/19293 - invalidate frame cache when unwinders changeTom Tromey2-2/+14
PR python/19293 notes that when a Python unwinder is disabled, the frame cache is not invalidated. This means that disabling an unwinder doesn't have any immediate effect -- but in my experience it's often the case that I want to enable or disable an unwinder in order to see what happens. This patch adds a new gdb.invalidate_cached_frames function and arranges for the relevant bits of library code to call it. I've only partially documented this function, considering a warning sufficient without going into all the reasons ordinary code should not call it. The name of the new function was taken from a comment in frame.h next to reinit_frame_cache. No new test as I think the updates to the existing test are sufficient to show that the code is working as intended. Built and regtested on x86-64 Fedora 23. 2016-07-12 Tom Tromey <tom@tromey.com> PR python/19293: * python/lib/gdb/command/unwinders.py (do_enable_unwinder): Call gdb.invalidate_cached_frames. * python/lib/gdb/unwinder.py (register_unwinder): Call gdb.invalidate_cached_frames. * python/python.c (gdbpy_invalidate_cached_frames): New function. (python_GdbMethods): Add entry for invalidate_cached_frames. 2016-07-12 Tom Tromey <tom@tromey.com> PR python/19293: * python.texi (Frames In Python): Document gdb.invalidate_cached_frames. 2016-07-12 Tom Tromey <tom@tromey.com> PR python/19293: * gdb.python/py-unwind-maint.exp: Update tests.
2016-07-12Match the selftest output when captured_main is inlinedYao Qi2-0/+10
In gdb.gdb/observer.exp, I see the following fail, (gdb) break captured_main^M Breakpoint 1 at 0x57e409: file ../../binutils-gdb/gdb/main.c, line 492.^M (gdb) PASS: gdb.gdb/observer.exp: breakpoint in captured_main run -nw -nx -data-directory /home/yao.qi/SourceCode/gnu/build/gdb/testsuite/../data-directory^M Starting program: /home/yao.qi/SourceCode/gnu/build/gdb/testsuite/outputs/gdb.gdb/observer/xgdb -nw -nx -data-directory /home/yao.qi/SourceCode/gnu/build/gdb/testsuite/../data-directory^M [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".^M ^M Breakpoint 1, gdb_main (args=args@entry=0x7fffffffdca0) at ../../binutils-gdb/gdb/main.c:1157^M 1157 captured_main (args);^M (gdb) FAIL: gdb.gdb/observer.exp: run until breakpoint at captured_main looks the test sets breakpoint on captured_main, and expects program stops at captured_main. However, program stops at the place where captured_main is called, because captured_main is inlined, <1><8519e3>: Abbrev Number: 58 (DW_TAG_subprogram) <8519e4> DW_AT_name : (indirect string, offset: 0x880d3): captured_main <8519e8> DW_AT_decl_file : 1 <8519e9> DW_AT_decl_line : 444 <8519eb> DW_AT_type : <0x846e48> <8519ef> DW_AT_inline : 1 (inlined) <8519f0> DW_AT_sibling : <0x851c01> The test passes if I build GDB with '-O0 -g3', because captured_main isn't inlined. This patch is to match the output when captured_main is inlined. gdb/testsuite: 2016-07-12 Yao Qi <yao.qi@linaro.org> * lib/selftest-support.exp (selftest_setup): Match the output when captured_main is inlined.
2016-07-07Fix of default lookup for "this" symbol.Walfred Tedeschi3-3/+47
Using the default lookup for the symbol "this" might lead to segmentation fault in GDB. Some languages, e.g. Fortran, use as default lookup routine the C++ routines. For those languages "this" can be the instance of a class or even the definition of a class. When an instance of a class having the name "this" is evaluated in GDB a segmentation fault was observed. As example of the issue take into consideration the Fortran code: type foo real :: a type(bar) :: x character*7 :: b end type foo type(foo) :: this Issue appears when evaluating the variable "this" in GDB. Within the language definition structure there is a field that represents the name of the special symbol used for the C++ "this" for the language being described. The fix presented here takes into account the aforementioned field. In the case the aforementioned field is NULL "this" is not represented in the language described and the lookup should return a null_block_symbol. Tests: Performed tests with gfortran and ifort. Reviewed: https://sourceware.org/ml/gdb-patches/2016-04/msg00068.html After the commited patch: https://sourceware.org/ml/gdb-patches/2016-06/msg00364.html Patch can be applied. 2016-06-16 Walfred Tedeschi <walfred.tedeschi@intel.com> gdb/ChangeLog: * cp-namespace.c (cp_lookup_bare_symbol): Use language passed as parameter to look for the symbol "this". gdb/testsuite/ChangeLog: * gdb.fortran/derived-types.exp (result_line, result_line_2): New variables. (print this%a, print this%b, print this): New tests. * gdb.fortran/derived-types.f90 (this): New object and initialization.
2016-07-06gdb.ada/arraydim.exp: Fix directory layoutSimon Marchi2-2/+7
I forgot to fix this one in the previous commit. gdb/testsuite/ChangeLog: * gdb.ada/arraydim.exp: Remove extra directory level in build directory.
2016-07-06Remove extra output directory level for Ada testsSimon Marchi5-12/+17
The output of Ada tests create a layout where the test name ("formatted_ref" in this example) appears twice: outputs └── gdb.ada └── formatted_ref └── formatted_ref ├── b~formatted_ref.adb ├── b~formatted_ref.ads ├── b~formatted_ref.ali ├── b~formatted_ref.o ├── defs.ali ├── defs.o ├── formatted_ref ├── formatted_ref.ali └── formatted_ref.o This causes a problem when testing with the native-gdbserver board, when the binary has the same name as the test. When gdb_remote_download is called to upload the compiled binary, the implementation for native-gdbserver copies it in the standard output directory (in outputs/gdb.ada/formatted_ref). However, there is already a directory named formatted_ref in there, so the copy fails and gdbserver isn't able to load the binary. This patch bypasses the problem by removing the extra directory level. The compiled binary will already be in its final location in the standard output directory, so the copy will effectively be a no-op. gdb/testsuite/ChangeLog: * lib/ada.exp: Remove extra directory level in build directory. * gdb.ada/cond_lang.exp: Likewise. * gdb.ada/exec_changed.exp: Likewise. * gdb.ada/lang_switch.exp: Likewise.
generated by cgit v1.1 at 2025-01-09 02:29:16 +0000