aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2014-03-26Skip tests on completion and readline when readline lib isn't usedYao Qi10-136/+198
The completion feature and other features on readline depend on the readline library. However, readline library is not always used, for example, running testsuite like make check RUNTESTFLAGS="--host_board=local-remote-host" the input stream is not a tty, and GDB doesn't use readline library as a result. This patch is to skip tests on completion and readline if 'show editing' is off, which means readline isn't used. Note that some tests in gdb.base/completion.exp test command complete, which isn't related to readline, so these tests aren't affected by readline library. This patch also moves these tests up, run them unconditionally, and run the rest if readline library is used. gdb/testsuite: 2014-03-26 Yao Qi <yao@codesourcery.com> * lib/gdb.exp (readline_is_used): New proc. * gdb.base/completion.exp: Move tests on command complete up. Skip the rest of tests if readline is not used. * gdb.ada/complete.exp: Skp the test if readline is not used. * gdb.base/filesym.exp: Likewise. * gdb.base/macscp.exp: Likewise. * gdb.base/readline-ask.exp: Likewise. * gdb.base/readline.exp: Likewise. * gdb.python/py-cmd.exp: Likewise. * gdb.trace/tfile.exp: Likewise.
2014-03-26Fix code format issues gdb.base/macscp.expYao Qi2-48/+56
When I do something else, I find code format in gdb.base/macscp.exp is messy. This patch is to fix various code format issues in it. Pushed as it is obvious. gdb/testsuite: 2014-03-26 Yao Qi <yao@codesourcery.com> * gdb.base/macscp.exp: Fix code format issues.
2014-03-25Fix type of "fp" and other registers for Nios II.Sandra Loosemore4-12/+19
2014-03-25 Sandra Loosemore <sandra@codesourcery.com> gdb/ * features/nios2-cpu.xml: Correct types of "gp", "fp", "ea", and "ra" registers. * features/nios2-linux.c: Regenerated. * features/nios2.c: Regenerated.
2014-03-25Support gdb.asm/asm-source.exp on powerpc64leUlrich Weigand3-0/+57
Add new powerpc64le.inc file appropriate for the ELFv2 ABI and use it to support the asm-source.exp test case on powerpc64le. gdb/testsuite/ 2014-03-25 Ulrich Weigand <uweigand@de.ibm.com> * gdb.asm/asm-source.exp: Handle powerpc64le-* targets. * gdb.asm/powerpc64le.inc: New file.
2014-03-25"source", foreground execution commands, and target-asyncPedro Alves6-0/+110
Sourcing a GDB script that runs foreground execution commands in succession fails if the target can async: Breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.base/source-execution.c:36 36 func1 (); (gdb) source ../../../src/gdb/testsuite/gdb.base/source-execution.gdb ../../../src/gdb/testsuite/gdb.base/source-execution.gdb:21: Error in sourced command file: Cannot execute this command while the selected thread is running. (gdb) FAIL: gdb.base/source-execution.exp: source source-execution.gdb That is, after a foreground execution command, GDB moves on to the following command immediately before waiting for the previous command to complete. https://sourceware.org/ml/gdb-patches/2011-09/msg00037.html (b4a14fd0) addressed this for command lists, Python's gdb.execute, etc., but missed "source". Fixed now in the same way. gdb/ 2014-03-25 Pedro Alves <palves@redhat.com> * cli/cli-script.c (script_from_file): Force the interpreter to sync mode. gdb/testsuite/ 2014-03-25 Pedro Alves <palves@redhat.com> Doug Evans <dje@google.com> * gdb.base/source-execution.c: New file. * gdb.base/source-execution.exp: New file. * gdb.base/source-execution.gdb: New file.
2014-03-24gdb.linespec/macro-relative.exp: Mark the test as unsupported if using fission.Doug Evans2-0/+11
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 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-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-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-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-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-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-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-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.
2014-03-19gdb.base/async.exp: Factor out test pattern to a procedure.Pedro Alves2-54/+47
All the tests here follow the same pattern (and they all have the same problem, not fixed here yet). Add a new procedure, factoring out the pattern to a simple place. gdb/testsuite/ 2014-03-19 Pedro Alves <palves@redhat.com> * gdb.base/async.exp (test_background): New procedure. Use it for all background execution command tests.
2014-03-19gdb.base/async.exp: Use prepare_for_testing.Pedro Alves2-13/+8
gdb/testsuite/ 2014-03-19 Pedro Alves <palves@redhat.com> * gdb.base/async.exp: Use prepare_for_testing.
2014-03-19gdb.base/async.exp: Fix stepi& test.Pedro Alves2-2/+8
Currently the test assumes that "stepi" over: 13 x = 5; end up somewhere midline. But, (at least) on x86, that assignment ends up compiled as just one movl instruction, so a stepi stops at the next line already: completed. PASS: gdb.base/async.exp: step & step& (gdb) foo () at ../../../src/gdb/testsuite/gdb.base/async.c:13 13 x = 5; completed. PASS: gdb.base/async.exp: step & stepi& (gdb) 14 y = 3; completed. FAIL: gdb.base/async.exp: (timeout) stepi & nexti& (gdb) 16 return x + y; completed. FAIL: gdb.base/async.exp: (timeout) nexti & finish& Run till exit from #0 foo () at ../../../src/gdb/testsuite/gdb.base/async.c:16 This patch fixes it, by making sure there's more than one instruction in that line. gdb/testsuite/ 2014-03-19 Pedro Alves <palves@redhat.com> * gdb.base/async.c (foo): Make 'x' volatile. Write to it twice in the same line.
2014-03-19gdb.base/async.exp: Don't hardcode line numbers.Pedro Alves3-6/+19
gdb/testsuite/ 2014-03-19 Pedro Alves <palves@redhat.com> * gdb.base/async.c (main): Add "jump here" and "until here" line marker comments. * gdb.base/async.exp (jump_here): New global. (jump& test): Use it. (until_here): New global. (until& test): Use it.
2014-03-19gdb.base/async.exp: Leave gdb_protocol alone.Pedro Alves2-18/+4
Many eons ago, async was only implemented in the remote target, and you'd activate it by doing "target async" rather than "target remote". That's long gone now, replaced by "set target-async on". gdb/testsuite/ 2014-03-19 Pedro Alves <palves@redhat.com> * gdb.base/async.exp: Don't frob gdb_protocol.
2014-03-18 * gdb.base/async.exp: Whitespace fixes. Turn on target-async.Doug Evans2-7/+14
Fix spelling of exec-done-display.
2014-03-18Fix SIGTERM signal safety (PR gdb/15358).Jan Kratochvil7-3/+176
gdb/ 2014-03-18 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/15358 * defs.h (sync_quit_force_run): New declaration. (QUIT): Check also SYNC_QUIT_FORCE_RUN. * event-top.c (async_sigterm_handler): New declaration. (async_sigterm_token): New variable. (async_init_signals): Create also async_sigterm_token. (async_sigterm_handler): New function. (sync_quit_force_run): New variable. (handle_sigterm): Replace quit_force call by other calls. * utils.c (quit): Call quit_force if SYNC_QUIT_FORCE_RUN. gdb/testsuite/ 2014-03-18 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/15358 * gdb.base/gdb-sigterm.c: New file. * gdb.base/gdb-sigterm.exp: New file. Message-ID: <20140316135334.GA30698@host2.jankratochvil.net>
2014-03-18Power: Correct little-endian e500v2 GPR frame offsetsMaciej W. Rozycki2-2/+9
This change corrects GPR frame offset calculation for the e500v2 processor. On this target, featuring the SPE APU, GPRs are 64-bit and are held in stack frames whole with the use of `evstdd' and `evldd' instructions. Their integer 32-bit part occupies the low-order word and therefore its offset varies between the two endiannesses possible. * rs6000-tdep.c (rs6000_frame_cache): Correct little-endian GPR offset into SPE pseudo registers.
2014-03-18PR gdb/13860: make "-exec-foo"'s MI output equal to "foo"'s MI output.Pedro Alves7-63/+98
Part of PR gdb/13860 is about the mi-solib.exp test's output being different in sync vs async modes. sync: >./gdb -nx -q ./testsuite/gdb.mi/solib-main -ex "set stop-on-solib-events 1" -ex "set target-async off" -i=mi =thread-group-added,id="i1" ~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main..." ~"done.\n" (gdb) &"start\n" ~"Temporary breakpoint 1 at 0x400608: file ../../../src/gdb/testsuite/gdb.mi/solib-main.c, line 21.\n" =breakpoint-created,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000000400608",func="main",file="../../../src/gdb/testsuite/gdb.mi/solib-main.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/solib-main.c",line="21",times="0",original-location="main"} ~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n" =thread-group-started,id="i1",pid="17724" =thread-created,id="1",group-id="i1" ^running *running,thread-id="all" (gdb) =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1" ~"Stopped due to shared library event (no libraries added or removed)\n" *stopped,reason="solib-event",frame={addr="0x000000379180f990",func="_dl_debug_state",args=[],from="/lib64/ld-linux-x86-64.so.2"},thread-id="1",stopped-threads="all",core="3" (gdb) async: >./gdb -nx -q ./testsuite/gdb.mi/solib-main -ex "set stop-on-solib-events 1" -ex "set target-async on" -i=mi =thread-group-added,id="i1" ~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main..." ~"done.\n" (gdb) start &"start\n" ~"Temporary breakpoint 1 at 0x400608: file ../../../src/gdb/testsuite/gdb.mi/solib-main.c, line 21.\n" =breakpoint-created,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000000400608",func="main",file="../../../src/gdb/testsuite/gdb.mi/solib-main.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/solib-main.c",line="21",times="0",original-location="main"} ~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n" =thread-group-started,id="i1",pid="17729" =thread-created,id="1",group-id="i1" ^running *running,thread-id="all" =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1" (gdb) *stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="1" For now, let's focus only on the *stopped event. We see that the async output is missing frame info. And this causes a test failure in async mode, as "mi_expect_stop solib-event" wants to see the frame info. However, if we compare the event output when a real MI execution command is used, compared to a CLI command (e.g., run vs -exec-run, next vs -exec-next, etc.), we see: >./gdb -nx -q ./testsuite/gdb.mi/solib-main -ex "set stop-on-solib-events 1" -ex "set target-async off" -i=mi =thread-group-added,id="i1" ~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main..." ~"done.\n" (gdb) r &"r\n" ~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n" =thread-group-started,id="i1",pid="17751" =thread-created,id="1",group-id="i1" ^running *running,thread-id="all" (gdb) =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1" ~"Stopped due to shared library event (no libraries added or removed)\n" *stopped,reason="solib-event",frame={addr="0x000000379180f990",func="_dl_debug_state",args=[],from="/lib64/ld-linux-x86-64.so.2"},thread-id="1",stopped-threads="all",core="3" (gdb) -exec-run =thread-exited,id="1",group-id="i1" =thread-group-exited,id="i1" =library-unloaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",thread-group="i1" =thread-group-started,id="i1",pid="17754" =thread-created,id="1",group-id="i1" ^running *running,thread-id="all" (gdb) =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1" *stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="1" =thread-selected,id="1" (gdb) As seen above, with MI commands, the *stopped event _doesn't_ have frame info. This is because normal_stop, as commanded by the result of bpstat_print, skips printing frame info in this case (it's an "event", not a "breakpoint"), and when the interpreter is MI, mi_on_normal_stop skips calling print_stack_frame, as the normal_stop call was already done with the MI uiout. This explains why the async output is different even with a CLI command. Its because in async mode, the mi_on_normal_stop path is always taken; it is always reached with the MI uiout, because the stop is handled from the event loop, instead of from within `proceed -> wait_for_inferior -> normal_stop' with the interpreter overridden, as in sync mode. This patch fixes the issue by making all cases output the same *stopped event, by factoring out the print code from normal_stop, and using it from mi_on_normal_stop as well. I chose the *stopped output without a frame, mainly because that is what you already get if you use MI execution commands, the commands frontends are supposed to use (except when implementing a console). This patch makes it simpler to tweak the MI output differently if desired, as we only have to change the centralized print_stop_event (taking into account whether the uiout is MI-like), and all different modes will change accordingly. Tested on x86_64 Fedora 17, no regressions. The mi-solib.exp test no longer fails in async mode with this patch, so the patch removes the kfail. 2014-03-18 Pedro Alves <palves@redhat.com> PR gdb/13860 * inferior.h (print_stop_event): Declare. * infrun.c (print_stop_event): New, factored out from ... (normal_stop): ... this. * mi/mi-interp.c (mi_on_normal_stop): Use print_stop_event instead of bpstat_print/print_stack_frame. 2014-03-18 Pedro Alves <palves@redhat.com> PR gdb/13860 * gdb.mi/mi-solib.exp: Remove gdb/13860 kfail. * lib/mi-support.exp (mi_expect_stop): Add special handling for solib-event.
2014-03-17fix latent bugs in ui-out.cTom Tromey2-2/+7
The destructor code in ui-out.c has a latent bug, which is hidden by the fact that nothing uses this right now. This patch fixes the problem. The bug is that we don't always clear a pointer in the ui-out object, leading to a bad free. 2014-03-17 Tom Tromey <tromey@redhat.com> * ui-out.c (clear_table, ui_out_new): Clear uiout->table.id.
2014-03-17[testsuite/Ada] New testcase for packed array renaming.Joel Brobecker5-0/+111
gdb/testsuite/ChangeLog: * gdb.ada/pckd_arr_ren: New testcase.
2014-03-17[Ada] Crash with references to GNAT packed arrays handlingPierre-Marie de Rodat2-8/+14
Consider the following declarations: type Packed_Array is array (Natural range <>) of Boolean; pragma Pack (Packed_Array); function Make (H, L : Natural) return Packed_Array is begin return (H .. L => False); end Make; A1 : Packed_Array := Make (1, 2); A2 : Packed_Array renames A1; One possible DWARF translation for A2 is: <3><1e4>: Abbrev Number: 21 (DW_TAG_variable) <1e5> DW_AT_name : a2 <1ea> DW_AT_type : <0x1d9> <3><1d9>: Abbrev Number: 22 (DW_TAG_const_type) <1da> DW_AT_type : <0x1de> <3><1de>: Abbrev Number: 23 (DW_TAG_reference_type) <1e0> DW_AT_type : <0x1a3> <3><1a3>: Abbrev Number: 17 (DW_TAG_array_type) <1a4> DW_AT_name : foo__Ta1S___XP1 <1a8> DW_AT_GNAT_descriptive_type: <0x16b> <3><16b>: Abbrev Number: 6 (DW_TAG_typedef) <16c> DW_AT_name : foo__Ta1S <172> DW_AT_type : <0x176> <3><176>: Abbrev Number: 17 (DW_TAG_array_type) <177> DW_AT_name : foo__Ta1S <17b> DW_AT_GNAT_descriptive_type: <0x223> Here, foo__Ta1S___XP1 is the type used for the code generation while foo__Ta1S is the source-level type. Both form a valid GNAT encoding for a packed array type. Trying to print A2 (1) can make GDB crash. This is because A2 is defined as a reference to a GNAT encoding for a packed array. When decoding constrained packed arrays, the ada_coerce_ref subprogram follows references and returns a fixed type from the target type, peeling the GNAT encoding for packed arrays. The remaining code assumes that the resulting type is still such an encoding while we only have a standard GDB array type, hence the crash: arr = ada_coerce_ref (arr); [...] type = decode_constrained_packed_array_type (value_type (arr)); decode_constrained_packed_array_type assumes that its argument is such an encoding. From its front comment: /* The array type encoded by TYPE, where ada_is_constrained_packed_array_type (TYPE). */ This patch simply replaces the call to ada_coerce_ref with a call to coerce_ref in order to avoid prematurely transforming the packed array type as a side-effect. This way, the remaining code will always work with a GNAT encoding. gdb/ChangeLog: * ada-lang.c (decode_constrained_packed_array): Perform a minimal coercion for reference with coerce_ref instead of ada_coerce_ref.
generated by cgit v1.1 at 2024-12-28 22:24:40 +0000