aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-03-24gdb.linespec/macro-relative.exp: Mark the test as unsupported if using fission.Doug Evans2-0/+11
2014-03-25daily updateAlan Modra1-1/+1
2014-03-24Fix PR breakpoints/16101: gdb.base/dprintf.exp agent-printf failures with ↵Hui Zhu4-34/+77
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-24testsuite: Remove needless linux-nat requirement in gdb-sigterm.exp.Jan Kratochvil2-1/+4
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-24Fix PR/16720Pierre Langlois2-1/+6
2014-03-24 Pierre Langlois <pierre.langlois@embecosm.com> * avr-tdep.c (avr_scan_prologue): Accept push r1 instruction for small stack allocation.
2014-03-24darwin-nat.c: fix dump of messages on x86_64.Tristan Gingold2-18/+22
gdb/ * darwin-nat.c (exc_server): Remove unused prototype. (darwin_dump_message): Correctly display data on x86_64. (darwin_encode_reply): Fix style. Add comments and fix indentation.
2014-03-24Fix stack offset in Mach-O output for -P compact_unwind.Tristan Gingold2-5/+12
Minor fix in compact unwind output: to be more readable, the stack offset for indirect compact unwind entries are mutiplied by its factor (4 or 8). binutils/ * od-macho.c (dump_unwind_encoding_x86): Set the factor. (dump_exe_compact_unwind): Change the condition. Improve indentation.
2014-03-24Fix typo in previous entry.Pierre Langlois1-1/+1
2014-03-24Add myself as a write-after-approval mainainer.Pierre Langlois2-0/+5
2014-03-21 Pierre Langlois <pierre.langlois@embecosm.com> * MAINTAINERS (Write After Approval): Add "Pierre Langlois".
2014-03-24daily updateAlan Modra1-1/+1
2014-03-22* infcmd.c: Whitespace fixes.Doug Evans2-2/+14
(interrupt_command): Merge two function comments into one.
2014-03-22* infcmd.c (interrupt_command): Renamed from interrupt_target_command.Doug Evans2-2/+7
2014-03-23daily updateAlan Modra1-1/+1
2014-03-22Remove target_read_live_memoryYao Qi4-63/+22
As we move code on reading unavailable memory to target side, GDB core side doesn't need the "switching momentarily out of tfind mode" dance. The target remote knows how to read live memory (through remote_ops). Remove set_traceframe_number and make_cleanup_restore_traceframe_number, since they are no longer used. gdb: 2014-03-22 Yao Qi <yao@codesourcery.com> * remote.c (target_read_live_memory): Remove. (memory_xfer_live_readonly_partial): Rename it to remote_xfer_live_readonly_partial. Remove argument 'object'. All callers updated. Call remote_read_bytes_1 instead of target_read_live_memory. * tracepoint.c (set_traceframe_number): Remove. (make_cleanup_restore_traceframe_number): Likewise . * tracepoint.h (set_traceframe_number): Remove declaration. (make_cleanup_restore_traceframe_number): Likewise.
2014-03-22Factor remote_read_bytes.Yao Qi2-43/+60
This patch moves code in remote_read_bytes on reading from the remote stub to a new function remote_read_bytes_1. gdb: 2014-03-22 Yao Qi <yao@codesourcery.com> * remote.c (remote_read_bytes): Move code on reading from the remote stub to ... (remote_read_bytes_1): ... here. New function.
2014-03-22Move the traceframe_available_memory code from memory_xfer_partial_1 down to ↵Yao Qi5-143/+185
the targets As a follow-up to [PATCH 7/8] Adjust read_value_memory to use to_xfer_partial https://sourceware.org/ml/gdb-patches/2014-02/msg00384.html this patch moves traceframe_available_memory down to the target side. After this patch, the gdb core code is cleaner, and code on handling unavailable memory is moved to remote/tfile/ctf targets. In details, this patch moves traceframe_available_memory code from memory_xfer_partial_1 to remote target only, so remote target still uses traceframe_info mechanism to check unavailable memory, and use remote_ops to read them from read-only sections. We don't use traceframe_info mechanism for tfile and ctf target, because it is fast to iterate all traceframes from trace file, so the summary information got from traceframe_info is not necessary. This patch also moves two functions to remote.c from target.c, because they are only used in remote.c. I'll clean them up in another patch. gdb: 2014-03-22 Yao Qi <yao@codesourcery.com> * ctf.c (ctf_xfer_partial): Check the return value of exec_read_partial_read_only, if it is not TARGET_XFER_OK, return TARGET_XFER_UNAVAILABLE. * tracefile-tfile.c (tfile_xfer_partial): Likewise. * target.c (target_read_live_memory): Move it to remote.c. (memory_xfer_live_readonly_partial): Likewise. (memory_xfer_partial_1): Move some code to remote_read_bytes. * remote.c (target_read_live_memory): Moved from target.c. (memory_xfer_live_readonly_partial): Likewise. (remote_read_bytes): New, factored out from memory_xfer_partial_1.
2014-03-22Fix typo in previous entry.Doug Evans1-1/+1
2014-03-22 * gdb.guile/guile.exp (guile not supported): Verify multi-lineDoug Evans2-0/+9
guile command issues an error.
2014-03-22 * extension.c (eval_ext_lang_from_control_command): Avoid dereferencingDoug Evans4-1/+19
NULL pointer. testsuite/ * gdb.python/python.exp (python not supported): Verify multi-line python command issues an error.
2014-03-21gdb.threads/thread-specific.exp: Fix uninitialized variable referencesMaciej W. Rozycki2-5/+20
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-22daily updateAlan Modra1-1/+1
2014-03-212014-03-21 Christopher Faylor <me.binutils2014@cgf.cx>Chris Faylor3-10/+29
* ld.texinfo: Document change in handling of --enable-auto-image-base. * emultempl/pe.em (pe_auto_image_base): Set to default base. (gld_${EMULATION_NAME}_list_options): Change usage message to reflect optional --enable-auto-image-base argument. (gld${EMULATION_NAME}_handle_option): Handle optional --enable-auto-image-base argument. (compute_dll_image_base): Eliminate constant. Use pe_auto_image_base.
2014-03-21Add support to the Xtensa target for creating trampolines for out-of-range ↵David Weatherford11-2/+753
branches. * tc-xtensa.c (xtensa_check_frag_count, xtensa_create_trampoline_frag) (xtensa_maybe_create_trampoline_frag, init_trampoline_frag) (find_trampoline_seg, search_trampolines, get_best_trampoline) (check_and_update_trampolines, add_jump_to_trampoline) (dump_trampolines): New function. (md_parse_option): Add cases for --[no-]trampolines options. (md_assemble, finish_vinsn, xtensa_end): Add call to xtensa_check_frag_count. (xg_assemble_vliw_tokens): Add call to xtensa_maybe_create_trampoline_frag. (xtensa_relax_frag): Relax fragments with RELAX_TRAMPOLINE state. (relax_frag_immed): Relax jump instructions that cannot reach its target. * tc-xtensa.h (xtensa_relax_statesE::RELAX_TRAMPOLINE): New relax state. * as.texinfo: Document --[no-]trampolines command-line options. * c-xtensa.texi: Document trampolines relaxation and command line options. * frags.c (get_frag_count, clear_frag_count): New function. (frag_alloc): Increment totalfrags counter. * frags.h (get_frag_count, clear_frag_count): New function. * all.exp: Add test for trampoline relaxation. * trampoline.d: Trampoline relaxation expected dump. * trampoline.s: Trampoline relaxation test source.
2014-03-21normal_stop: Extend and clarify comment.Pedro Alves2-6/+14
Explain better why we skip saying "Switching to ..." in non-stop mode. gdb/ 2014-03-21 Pedro Alves <palves@redhat.com> * infrun.c (normal_stop): Extend comment.
2014-03-21Remove fixme of packet "k" from docHui Zhu2-3/+29
https://sourceware.org/ml/gdb-patches/2014-03/msg00324.html 2014-03-21 Pedro Alves <palves@redhat.com> Stan Shebs <stan@codesourcery.com> Hui Zhu <hui@codesourcery.com> * gdb.texinfo (Packets): Add anchor to "? packet". Remove fixme and update introduction of "k packet". Add anchor to "vKill packet".
2014-03-21Fix internal warning when "gdb -p xxx"Hui Zhu2-0/+53
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-21Fix internal warning when "gdb -p xxx"Hui Zhu5-33/+35
ps -e | grep a.out 28886 pts/12 00:00:00 a.out gdb -p 28886 Loaded symbols for /lib64/ld-linux-x86-64.so.2 0x0000003b0ccbc970 in __nanosleep_nocancel () from /lib64/libc.so.6 ../../binutils-gdb/gdb/cleanups.c:265: internal-warning: restore_my_cleanups has found a stale cleanup A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) The backtrace of this issue: (gdb) bt file=0x8b0c10 "s' failed.", line=265, fmt=0x8b0c38 "nutils-gdb/gdb/cleanups.c", ap=0x7fff803e3ed8) at ../../binutils-gdb/gdb/utils.c:748 fmt=0x8b0c38 "nutils-gdb/gdb/cleanups.c", ap=0x7fff803e3ed8) at ../../binutils-gdb/gdb/utils.c:799 string=0x8b0c38 "nutils-gdb/gdb/cleanups.c") at ../../binutils-gdb/gdb/utils.c:809 at ../../binutils-gdb/gdb/cleanups.c:265 at ../../binutils-gdb/gdb/cleanups.c:276 at ../../binutils-gdb/gdb/exceptions.c:142 at ../../binutils-gdb/gdb/exceptions.c:203 command=0x5d5fb8 <attach_command_continuation_free_args+18>, arg=0x7fff803e525b "2914", from_tty=1, mask=RETURN_MASK_ALL) at ../../binutils-gdb/gdb/exceptions.c:549 ---Type <return> to continue, or q <return> to quit--- func_args=0x7fff803e4280, errstring=0x8cf2e4 "/local/bin", mask=RETURN_MASK_ALL) at ../../binutils-gdb/gdb/exceptions.c:522 This is a new issue. It is introduced by commit https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=8bc2fe488957946d2cdccda3ce8d4f39e4003ea0 It removed the discard_cleanups (back_to) inside attach_command. Then restore_my_cleanups will throw a internal_warning. https://sourceware.org/ml/gdb-patches/2014-03/msg00374.html 2014-03-21 Hui Zhu <hui@codesourcery.com> Pedro Alves <palves@redhat.com> * darwin-nat.c (darwin_pid_to_exec_file): Change xmalloc to static buffer. * fbsd-nat.c (fbsd_pid_to_exec_file): Ditto. * linux-nat.c (linux_child_pid_to_exec_file): Ditto. * nbsd-nat.c (nbsd_pid_to_exec_file): Ditto.
2014-03-21daily updateAlan Modra1-1/+1
2014-03-20Add opcode relaxation for rl78-elfDJ Delorie5-23/+511
This patch adds initial in-gas opcode relaxation for the rl78 backend. Specifically, it checks for conditional branches that are too far and replaces them with inverted branches around longer fixed branches.
2014-03-20Avoid using the ISO C99 `z' formatted output modifierMaciej W. Rozycki2-1/+6
* mi/mi-interp.c (mi_memory_changed): Avoid using the ISO C99 `z' formatted output modifier.
2014-03-20gas/Richard Sandiford19-21/+187
* config/tc-mips.h (DIFF_EXPR_OK, CFI_DIFF_EXPR_OK): Define. * config/tc-mips.c (md_pcrel_from): Remove error message. (md_apply_fix): Convert PC-relative BFD_RELOC_32s to BFD_RELOC_32_PCREL. Report a specific error message for unhandled PC-relative expressions. Handle BFD_RELOC_8. gas/testsuite/ * gas/all/gas.exp: Remove XFAIL of forward.d for MIPS. * gas/mips/pcrel-1.s, gas/mips/pcrel-1.d, gas/mips/pcrel-2.s, gas/mips/pcrel-2.d, gas/mips/pcrel-3.s, gas/mips/pcrel-3.l, gas/mips/pcrel-4.s, gas/mips/pcrel-4-32.d, gas/mips/pcrel-4-n32.d, gas/mips/pcrel-4-64.d: New tests. * gas/mips/mips.exp: Run them. * gas/mips/lui-2.l: Tweak error message for line 7. ld/testsuite/ * ld-elf/merge.d: Remove MIPS XFAIL.
2014-03-20Fix probe-related internal error on AIXSergio Durigan Junior3-18/+29
-- Initial message by Tom Tromey: While testing on AIX, I happened to notice an internal error coming from parse_probes. This happens because there are no probes defined on this platform. This patch fixes the problem by changing an assert into an ordinary error, and then changing the relevant caller to cope. This fixes a few tests on AIX; also regtested on x86-64 Fedora 18. -- Followup by Sergio Durigan Junior: By reading the patch (and the original code), I found it a little bit obscure, so I took the liberty to try to improve it. Here's the patch. Could you please take a look and see if it works on AIX (and also if you like the approach)? gdb/ 2014-03-20 Tom Tromey <tromey@redhat.com> Sergio Durigan Junior <sergiodj@redhat.com> * probe.c (parse_probes): Turn assert into an ordinary error. * break-catch-throw.c (re_set_exception_catchpoint): Ignore exceptions when parsing probes. Rearrange the code for clarity.
2014-03-20Fix py-finish-breakpoint.exp with target async.Tom Tromey2-1/+9
With target async enabled, py-finish-breakpoint.exp triggers an assertion failure. The failure occurs because execute_command re-enters the event loop in some circumstances, and in this case resets the sync_execution flag. Then later GDB reaches this assertion in normal_stop: gdb_assert (sync_execution || !target_can_async_p ()); In detail: #1 - A synchronous execution command is run. sync_execution is set. #2 - A python breakpoint is hit (TARGET_WAITKIND_STOPPED), and the corresponding Python breakpoint's stop method is executed. When and while python commands are executed, interpreter_async is forced to 0. #3 - The Python stop method happens to execute a not-execution-related gdb command. In this case, "where 1". #4 - Seeing that sync_execution is set, execute_command nests a new event loop (although that wasn't necessary; this is the problem). #5 - The linux-nat target's pipe in the event loop happens to be marked. That's normal, due to this in linux_nat_wait: /* If we requested any event, and something came out, assume there may be more. If we requested a specific lwp or process, also assume there may be more. */ The nested event loop thus immediately wakes up and calls target_wait. No thread is actually executing in the inferior, so the target returns TARGET_WAITKIND_NO_RESUMED. #6 - normal_stop is reached. GDB prints "No unwaited-for children left.", and resets the sync_execution flag (IOW, there are no resumed threads left, so the synchronous command is considered completed.) This is already bogus. We were handling a breakpoint! #7 - the nested event loop unwinds/ends. GDB is now back to handling the python stop method (TARGET_WAITKIND_STOPPED), which decides the breakpoint should stop. normal_stop is called for this event. However, normal_stop actually works with the _last_ reported target status: void normal_stop (void) { struct target_waitstatus last; ptid_t last_ptid; struct cleanup *old_chain = make_cleanup (null_cleanup, NULL); ... get_last_target_status (&last_ptid, &last); ... if (last.kind == TARGET_WAITKIND_NO_RESUMED) { gdb_assert (sync_execution || !target_can_async_p ()); target_terminal_ours_for_output (); printf_filtered (_("No unwaited-for children left.\n")); } And due to the nesting in execute command, the last event is now TARGET_WAITKIND_NO_RESUMED, not the actual breakpoint event being handled. This could be seen to be broken in itself, but we can leave fixing that for another pass. The assertion is reached, and fails. execute_command has a comment explaining when it should synchronously wait for events: /* If the interpreter is in sync mode (we're running a user command's list, running command hooks or similars), and we just ran a synchronous command that started the target, wait for that command to end. */ However, the code did not follow this comment -- it didn't check to see if the command actually started the target, just whether the target was executing a sync command at this point. This patch fixes the problem by noting whether the target was executing in sync_execution mode before running the command, and then augmenting the condition to test this as well. 2014-03-20 Tom Tromey <tromey@redhat.com> PR gdb/14135 * top.c (execute_command): Only dispatch events if the command started the target.
2014-03-20make dprintf.exp pass in target async modePedro Alves5-0/+95
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-20Fix memory size for gather/scatter instructionsIlya Tocar14-219/+265
For gathers with indices larger than elements (e. g.) vpgatherqd ymm6{k1}, ZMMWORD PTR [ebp+zmm7*8-123] We currently treat memory size as a size of index register, while it is actually should be size of destination register: vpgatherqd ymm6{k1}, YMMWORD PTR [ebp+zmm7*8-123] This patch fixes it. opcodes/ * i386-opc.tbl: Change memory size for vgatherpf0qps, vgatherpf1qps, vscatterpf0qps, vscatterpf1qps, vgatherqps, vpgatherqd, vpscatterqd, vscatterqps. * i386-tbl.h: Regenerate. gas/testsuite/ * gas/i386/avx512pf-intel.d: Change memory size for vgatherpf0qps, vgatherpf1qps, vscatterpf0qps, vscatterpf1qps. * gas/i386/avx512pf.s: Ditto. * gas/i386/x86-64-avx512pf-intel.d: Ditto. * gas/i386/x86-64-avx512pf.s: Ditto. * gas/i386/avx512f-intel.d: Change memory size for vgatherqps, vpgatherqd, vpscatterqd, vscatterqps. * gas/i386/avx512f.s: Ditto. * gas/i386/x86-64-avx512f-intel.d: Ditto. * gas/i386/x86-64-avx512f.s: Ditto.
2014-03-20Further cleanup of signal-while-stepping-over-bp-other-thread.c.Pedro Alves2-29/+8
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-20Make signal-while-stepping-over-bp-other-thread.exp run against remote ↵Pedro Alves3-12/+12
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-20Handle multiple step-overs.Pedro Alves6-105/+373
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-20Fix for even more missed events; eliminate thread-hop code.Pedro Alves7-201/+303
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-20PR breakpoints/7143 - Watchpoint does not trigger when first setPedro Alves9-99/+189
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-20Fix missing breakpoint/watchpoint hits, eliminate deferred_step_ptid.Pedro Alves5-56/+143
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-20An off-by-one error in the code to catch bogus vn_next fields meant thatNick Clifton2-1/+6
linker testsuite failures were showing up for the cris target. Fixed by this patch. * readelf.c (process_version_sections): Fix off-by-one error in previous delta.
2014-03-20bfd/elf32-arm.c: Set st_value to zero for undefined symbolsWill Newton4-3/+21
Unless pointer_equality_needed is set then set st_value to be zero for undefined symbols. bfd/ChangeLog: 2014-03-20 Will Newton <will.newton@linaro.org> PR ld/16715 * elf32-arm.c (elf32_arm_check_relocs): Set pointer_equality_needed for absolute references within executable links. (elf32_arm_finish_dynamic_symbol): Set st_value to zero unless pointer_equality_needed is set. ld/testsuite/ChangeLog: 2014-03-20 Will Newton <will.newton@linaro.org> * ld-arm/ifunc-14.rd: Update symbol values.
2014-03-20daily updateAlan Modra1-1/+1
2014-03-19This is a fix for PR binutils/16723, where a corrupt .gnu.version_r section ↵Nick Clifton2-0/+13
could send readelf into an infinite loop. * readelf.c (process_version_sections): Prevent an infinite loop when the vn_next field is zero but there are still entries to be processed.
2014-03-19This patch adds support for the hyperprivileged registers %hstick_offsetJose E. Marchesi10-7/+43
and %hstick_enable to the Sparc assembler. * config/tc-sparc.c (hpriv_reg_table): Added entries for %hstick_offset and %hstick_enable. * doc/c-sparc.texi (Sparc-Regs): Document the %hstick_offset and %hstick_enable hyperprivileged registers. * sparc-dis.c (v9_hpriv_reg_names): Names for %hstick_offset and %hstick_enable added. * gas/sparc/rdhpr.s: Test rd %hstick_offset and %hstick_enable. * gas/sparc/rdhpr.d: Likewise. * gas/sparc/wrhpr.s: Test wr %hstick_offset and %hstick_enable. * gas/sparc/wrhpr.d: Likewise.
2014-03-19Fix Sparc test which was failing in the presence of new v9 opcodes.Jose E. Marchesi2-2/+7
* gas/sparc/ldd_std.d: Fix objdump invocation in order to get the old opcodes for the ldtw, ldtwa, stw and stwa instructions.
2014-03-19gdb.base/async.exp: Enable it.Pedro Alves2-7/+4
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-19gdb.base/async.exp: Make test messages unique.Pedro Alves2-2/+6
$ 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-19gdb.base/async.exp: Fix races.Pedro Alves2-1/+6
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.
generated by cgit v1.1 at 2024-12-20 22:02:48 +0000