old-cross-binutils/gdb/testsuite/gdb.threads/break-while-running.exp

163 lines
5.3 KiB
Text
Raw Normal View History

# Copyright (C) 2014-2015 Free Software Foundation, Inc.
Fix "breakpoint always-inserted off"; remove "breakpoint always-inserted auto" By default, GDB removes all breakpoints from the target when the target stops and the prompt is given back to the user. This is useful in case GDB crashes while the user is interacting, as otherwise, there's a higher chance breakpoints would be left planted on the target. But, as long as any thread is running free, we need to make sure to keep breakpoints inserted, lest a thread misses a breakpoint. With that in mind, in preparation for non-stop mode, we added a "breakpoint always-inserted on" mode. This traded off the extra crash protection for never having threads miss breakpoints, and in addition is more efficient if there's a ton of breakpoints to remove/insert at each user command (e.g., at each "step"). When we added non-stop mode, and for a period, we required users to manually set "always-inserted on" when they enabled non-stop mode, as otherwise GDB removes all breakpoints from the target as soon as any thread stops, which means the other threads still running will miss breakpoints. The test added by this patch exercises this. That soon revealed a nuisance, and so later we added an extra "breakpoint always-inserted auto" mode, that made GDB behave like "always-inserted on" when non-stop was enabled, and "always-inserted off" when non-stop was disabled. "auto" was made the default at the same time. In hindsight, this "auto" setting was unnecessary, and not the ideal solution. Non-stop mode does depends on breakpoints always-inserted mode, but only as long as any thread is running. If no thread is running, no breakpoint can be missed. The same is true for all-stop too. E.g., if, in all-stop mode, and the user does: (gdb) c& (gdb) b foo That breakpoint at "foo" should be inserted immediately, but it currently isn't -- currently it'll end up inserted only if the target happens to trip on some event, and is re-resumed, e.g., an internal breakpoint triggers that doesn't cause a user-visible stop, and so we end up in keep_going calling insert_breakpoints. The test added by this patch also covers this. IOW, no matter whether in non-stop or all-stop, if the target fully stops, we can remove breakpoints. And no matter whether in all-stop or non-stop, if any thread is running in the target, then we need breakpoints to be immediately inserted. And then, if the target has global breakpoints, we need to keep breakpoints even when the target is stopped. So with that in mind, and aiming at reducing all-stop vs non-stop differences for all-stop-on-stop-of-non-stop, this patch fixes "breakpoint always-inserted off" to not remove breakpoints from the target until it fully stops, and then removes the "auto" setting as unnecessary. I propose removing it straight away rather than keeping it as an alias, unless someone complains they have scripts that need it and that can't adjust. Tested on x86_64 Fedora 20. gdb/ 2014-09-22 Pedro Alves <palves@redhat.com> * NEWS: Mention merge of "breakpoint always-inserted" modes "off" and "auto" merged. * breakpoint.c (enum ugll_insert_mode): New enum. (always_inserted_mode): Now a plain boolean. (show_always_inserted_mode): No longer handle AUTO_BOOLEAN_AUTO. (breakpoints_always_inserted_mode): Delete. (breakpoints_should_be_inserted_now): New function. (insert_breakpoints): Pass UGLL_INSERT to update_global_location_list instead of calling insert_breakpoint_locations manually. (create_solib_event_breakpoint_1): New, factored out from ... (create_solib_event_breakpoint): ... this. (create_and_insert_solib_event_breakpoint): Use create_solib_event_breakpoint_1 instead of calling insert_breakpoint_locations manually. (update_global_location_list): Change parameter type from boolean to enum ugll_insert_mode. All callers adjusted. Adjust to use breakpoints_should_be_inserted_now and handle UGLL_INSERT. (update_global_location_list_nothrow): Change parameter type from boolean to enum ugll_insert_mode. (_initialize_breakpoint): "breakpoint always-inserted" option is now a boolean command. Update help text. * breakpoint.h (breakpoints_always_inserted_mode): Delete declaration. (breakpoints_should_be_inserted_now): New declaration. * infrun.c (handle_inferior_event) <TARGET_WAITKIND_LOADED>: Remove breakpoints_always_inserted_mode check. (normal_stop): Adjust to use breakpoints_should_be_inserted_now. * remote.c (remote_start_remote): Likewise. gdb/doc/ 2014-09-22 Pedro Alves <palves@redhat.com> * gdb.texinfo (Set Breaks): Document that "set breakpoint always-inserted off" is the default mode now. Delete documentation of "set breakpoint always-inserted auto". gdb/testsuite/ 2014-09-22 Pedro Alves <palves@redhat.com> * gdb.threads/break-while-running.exp: New file. * gdb.threads/break-while-running.c: New file.
2014-09-22 08:56:55 +00:00
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
# Test that:
#
# - setting a breakpoint while a thread is running results in the
# breakpoint being inserted immediately.
#
# - if breakpoint always-inserted mode is off, GDB doesn't remove
# breakpoints from the target when a thread stops, if there are
# still threads running.
standard_testfile
if {[prepare_for_testing "failed to prepare" $testfile $srcfile {debug pthreads}] == -1} {
return -1
}
Fix non-stop regressions caused by "breakpoints always-inserted off" changes Commit a25a5a45 (Fix "breakpoint always-inserted off"; remove "breakpoint always-inserted auto") regressed non-stop remote debugging. This was exposed by mi-nsintrall.exp intermittently failing with a spurious SIGTRAP. The problem is that when debugging with "target remote", new threads the target has spawned but have never reported a stop aren't visible to GDB until it explicitly resyncs its thread list with the target's. For example, in a program like this: int main (void) { pthread_t child_thread; pthread_create (&child_thread, NULL, child_function, NULL); return 0; <<<< set breakpoint here } If the user sets a breakpoint at the "return" statement, and runs the program, when that breakpoint hit is reported, GDB is only aware of the main thread. So if we base the decision to remove or insert breakpoints from the target based on whether all the threads we know about are stopped, we'll miss that child_thread is running, and thus we'll remove breakpoints from the target, even through they should still remain inserted, otherwise child_thread will miss them. The break-while-running.exp test actually should also be exposing this thread-list-out-of-synch problem. That test sets a breakpoint while the main thread is stopped, but other threads are running. Because other threads are running, the breakpoint is supposed to be inserted immediately. But, unless something forces a refetch of the thread list, like, e.g., "info threads", GDB won't be aware of the other threads that had been spawned by the main thread, and so won't insert new or old breakpoints in the target. And it turns out that the test is exactly doing an explicit "info threads", masking out the problem... This commit adjust the test to exercise the case of not issuing "info threads". The test then fails without the GDB fix. In the ni-nsintrall.exp case, what happens is that several threads hit the same breakpoint, and when the first thread reports the stop, because GDB wasn't aware other threads exist, all threads known to GDB are found stopped, so GDB removes the breakpoints from the target. The other threads follow up with SIGTRAPs too for that same breakpoint, which has already been removed. For the first few threads, the moribund breakpoints machinery suppresses the SIGTRAPs, but after a few events (precisely '3 * thread_count () + 1' at the time the breakpoint was removed, see update_global_location_list), the moribund breakpoint machinery is no longer aware of the removed breakpoint, and the SIGTRAP is reported as a spurious stop. The fix is naturally then to stop assuming that if no thread in the list is executing, then the target is fully stopped. We can't know that until we fully sync the thread list. Because updating the thread list on every stop would be too much RSP traffic, I chose instead to update it whenever we're about to present a stop to the user. Actually updating the thread list at that point happens to be an item I had added to the local/remote parity wiki page a while ago: Native GNU/Linux debugging adds new threads to the thread list as the program creates them "The [New Thread foo] messages". Remote debugging can't do that, and it's arguable whether we shouldn't even stop native debugging from doing that, as it hinders inferior performance. However, a related issue is that with remote targets (and gdbserver), even after the program stops, the user still needs to do "info threads" to pull an updated thread list. This, should most likely be addressed, so that GDB pulls the list itself, perhaps just before presenting a stop to the user. With that in place, the need to delay "Program received signal FOO" was actually caught by the manythreads.exp test. Without that bit, I was getting: [Thread 0x7ffff7f13700 (LWP 4499) exited] [New Thread 0x7ffff7f0b700 (LWP 4500)] ^C Program received signal SIGINT, Interrupt. [New Thread 0x7ffff7f03700 (LWP 4501)] <<< new output [Switching to Thread 0x7ffff7f0b700 (LWP 4500)] __GI___nptl_death_event () at events.c:31 31 { (gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1 That is, I was now getting "New Thread" lines after the "Program received signal" line, and the test doesn't expect them. As the number of new threads discovered before and after the "Program received signal" output is unbounded, it's much nicer to defer "Program received signal" until after synching the thread list, thus close to the "switching to thread" output and "current frame/source" info: [Thread 0x7ffff7863700 (LWP 7647) exited] ^C[New Thread 0x7ffff786b700 (LWP 7648)] Program received signal SIGINT, Interrupt. [Switching to Thread 0x7ffff7fc4740 (LWP 6243)] __GI___nptl_create_event () at events.c:25 25 { (gdb) PASS: gdb.threads/manythreads.exp: stop threads 1 Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-02 Pedro Alves <palves@redhat.com> * breakpoint.c (breakpoints_should_be_inserted_now): Use threads_are_executing. * breakpoint.h (breakpoints_should_be_inserted_now): Add describing comment. * gdbthread.h (threads_are_executing): Declare. (handle_signal_stop) <random signals>: Don't print about the signal here if stopping. (end_stepping_range): Don't notify observers here. (normal_stop): Update the thread list. If stopped by a random signal or a stepping range ended, notify observers. * thread.c (threads_executing): New global. (init_thread_list): Clear 'threads_executing'. (set_executing): Set or clear 'threads_executing'. (threads_are_executing): New function. (update_threads_executing): New function. (update_thread_list): Use it. gdb/testsuite/ 2014-10-02 Pedro Alves <palves@redhat.com> * gdb.threads/break-while-running.exp (test): Add new 'update_thread_list' argument. Skip "info threads" if false. (top level): Add new 'update_thread_list' axis.
2014-10-02 08:55:38 +00:00
# The test proper. UPDATE_THREAD_LIST indicates whether we should do
# an "info threads" to sync the thread list after the first stop.
# ALWAYS_INSERTED indicates whether testing in "breakpoint
# always-inserted" mode. NON_STOP indicates whether we're testing in
# non-stop, or all-stop mode.
Fix "breakpoint always-inserted off"; remove "breakpoint always-inserted auto" By default, GDB removes all breakpoints from the target when the target stops and the prompt is given back to the user. This is useful in case GDB crashes while the user is interacting, as otherwise, there's a higher chance breakpoints would be left planted on the target. But, as long as any thread is running free, we need to make sure to keep breakpoints inserted, lest a thread misses a breakpoint. With that in mind, in preparation for non-stop mode, we added a "breakpoint always-inserted on" mode. This traded off the extra crash protection for never having threads miss breakpoints, and in addition is more efficient if there's a ton of breakpoints to remove/insert at each user command (e.g., at each "step"). When we added non-stop mode, and for a period, we required users to manually set "always-inserted on" when they enabled non-stop mode, as otherwise GDB removes all breakpoints from the target as soon as any thread stops, which means the other threads still running will miss breakpoints. The test added by this patch exercises this. That soon revealed a nuisance, and so later we added an extra "breakpoint always-inserted auto" mode, that made GDB behave like "always-inserted on" when non-stop was enabled, and "always-inserted off" when non-stop was disabled. "auto" was made the default at the same time. In hindsight, this "auto" setting was unnecessary, and not the ideal solution. Non-stop mode does depends on breakpoints always-inserted mode, but only as long as any thread is running. If no thread is running, no breakpoint can be missed. The same is true for all-stop too. E.g., if, in all-stop mode, and the user does: (gdb) c& (gdb) b foo That breakpoint at "foo" should be inserted immediately, but it currently isn't -- currently it'll end up inserted only if the target happens to trip on some event, and is re-resumed, e.g., an internal breakpoint triggers that doesn't cause a user-visible stop, and so we end up in keep_going calling insert_breakpoints. The test added by this patch also covers this. IOW, no matter whether in non-stop or all-stop, if the target fully stops, we can remove breakpoints. And no matter whether in all-stop or non-stop, if any thread is running in the target, then we need breakpoints to be immediately inserted. And then, if the target has global breakpoints, we need to keep breakpoints even when the target is stopped. So with that in mind, and aiming at reducing all-stop vs non-stop differences for all-stop-on-stop-of-non-stop, this patch fixes "breakpoint always-inserted off" to not remove breakpoints from the target until it fully stops, and then removes the "auto" setting as unnecessary. I propose removing it straight away rather than keeping it as an alias, unless someone complains they have scripts that need it and that can't adjust. Tested on x86_64 Fedora 20. gdb/ 2014-09-22 Pedro Alves <palves@redhat.com> * NEWS: Mention merge of "breakpoint always-inserted" modes "off" and "auto" merged. * breakpoint.c (enum ugll_insert_mode): New enum. (always_inserted_mode): Now a plain boolean. (show_always_inserted_mode): No longer handle AUTO_BOOLEAN_AUTO. (breakpoints_always_inserted_mode): Delete. (breakpoints_should_be_inserted_now): New function. (insert_breakpoints): Pass UGLL_INSERT to update_global_location_list instead of calling insert_breakpoint_locations manually. (create_solib_event_breakpoint_1): New, factored out from ... (create_solib_event_breakpoint): ... this. (create_and_insert_solib_event_breakpoint): Use create_solib_event_breakpoint_1 instead of calling insert_breakpoint_locations manually. (update_global_location_list): Change parameter type from boolean to enum ugll_insert_mode. All callers adjusted. Adjust to use breakpoints_should_be_inserted_now and handle UGLL_INSERT. (update_global_location_list_nothrow): Change parameter type from boolean to enum ugll_insert_mode. (_initialize_breakpoint): "breakpoint always-inserted" option is now a boolean command. Update help text. * breakpoint.h (breakpoints_always_inserted_mode): Delete declaration. (breakpoints_should_be_inserted_now): New declaration. * infrun.c (handle_inferior_event) <TARGET_WAITKIND_LOADED>: Remove breakpoints_always_inserted_mode check. (normal_stop): Adjust to use breakpoints_should_be_inserted_now. * remote.c (remote_start_remote): Likewise. gdb/doc/ 2014-09-22 Pedro Alves <palves@redhat.com> * gdb.texinfo (Set Breaks): Document that "set breakpoint always-inserted off" is the default mode now. Delete documentation of "set breakpoint always-inserted auto". gdb/testsuite/ 2014-09-22 Pedro Alves <palves@redhat.com> * gdb.threads/break-while-running.exp: New file. * gdb.threads/break-while-running.c: New file.
2014-09-22 08:56:55 +00:00
Fix non-stop regressions caused by "breakpoints always-inserted off" changes Commit a25a5a45 (Fix "breakpoint always-inserted off"; remove "breakpoint always-inserted auto") regressed non-stop remote debugging. This was exposed by mi-nsintrall.exp intermittently failing with a spurious SIGTRAP. The problem is that when debugging with "target remote", new threads the target has spawned but have never reported a stop aren't visible to GDB until it explicitly resyncs its thread list with the target's. For example, in a program like this: int main (void) { pthread_t child_thread; pthread_create (&child_thread, NULL, child_function, NULL); return 0; <<<< set breakpoint here } If the user sets a breakpoint at the "return" statement, and runs the program, when that breakpoint hit is reported, GDB is only aware of the main thread. So if we base the decision to remove or insert breakpoints from the target based on whether all the threads we know about are stopped, we'll miss that child_thread is running, and thus we'll remove breakpoints from the target, even through they should still remain inserted, otherwise child_thread will miss them. The break-while-running.exp test actually should also be exposing this thread-list-out-of-synch problem. That test sets a breakpoint while the main thread is stopped, but other threads are running. Because other threads are running, the breakpoint is supposed to be inserted immediately. But, unless something forces a refetch of the thread list, like, e.g., "info threads", GDB won't be aware of the other threads that had been spawned by the main thread, and so won't insert new or old breakpoints in the target. And it turns out that the test is exactly doing an explicit "info threads", masking out the problem... This commit adjust the test to exercise the case of not issuing "info threads". The test then fails without the GDB fix. In the ni-nsintrall.exp case, what happens is that several threads hit the same breakpoint, and when the first thread reports the stop, because GDB wasn't aware other threads exist, all threads known to GDB are found stopped, so GDB removes the breakpoints from the target. The other threads follow up with SIGTRAPs too for that same breakpoint, which has already been removed. For the first few threads, the moribund breakpoints machinery suppresses the SIGTRAPs, but after a few events (precisely '3 * thread_count () + 1' at the time the breakpoint was removed, see update_global_location_list), the moribund breakpoint machinery is no longer aware of the removed breakpoint, and the SIGTRAP is reported as a spurious stop. The fix is naturally then to stop assuming that if no thread in the list is executing, then the target is fully stopped. We can't know that until we fully sync the thread list. Because updating the thread list on every stop would be too much RSP traffic, I chose instead to update it whenever we're about to present a stop to the user. Actually updating the thread list at that point happens to be an item I had added to the local/remote parity wiki page a while ago: Native GNU/Linux debugging adds new threads to the thread list as the program creates them "The [New Thread foo] messages". Remote debugging can't do that, and it's arguable whether we shouldn't even stop native debugging from doing that, as it hinders inferior performance. However, a related issue is that with remote targets (and gdbserver), even after the program stops, the user still needs to do "info threads" to pull an updated thread list. This, should most likely be addressed, so that GDB pulls the list itself, perhaps just before presenting a stop to the user. With that in place, the need to delay "Program received signal FOO" was actually caught by the manythreads.exp test. Without that bit, I was getting: [Thread 0x7ffff7f13700 (LWP 4499) exited] [New Thread 0x7ffff7f0b700 (LWP 4500)] ^C Program received signal SIGINT, Interrupt. [New Thread 0x7ffff7f03700 (LWP 4501)] <<< new output [Switching to Thread 0x7ffff7f0b700 (LWP 4500)] __GI___nptl_death_event () at events.c:31 31 { (gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1 That is, I was now getting "New Thread" lines after the "Program received signal" line, and the test doesn't expect them. As the number of new threads discovered before and after the "Program received signal" output is unbounded, it's much nicer to defer "Program received signal" until after synching the thread list, thus close to the "switching to thread" output and "current frame/source" info: [Thread 0x7ffff7863700 (LWP 7647) exited] ^C[New Thread 0x7ffff786b700 (LWP 7648)] Program received signal SIGINT, Interrupt. [Switching to Thread 0x7ffff7fc4740 (LWP 6243)] __GI___nptl_create_event () at events.c:25 25 { (gdb) PASS: gdb.threads/manythreads.exp: stop threads 1 Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-02 Pedro Alves <palves@redhat.com> * breakpoint.c (breakpoints_should_be_inserted_now): Use threads_are_executing. * breakpoint.h (breakpoints_should_be_inserted_now): Add describing comment. * gdbthread.h (threads_are_executing): Declare. (handle_signal_stop) <random signals>: Don't print about the signal here if stopping. (end_stepping_range): Don't notify observers here. (normal_stop): Update the thread list. If stopped by a random signal or a stepping range ended, notify observers. * thread.c (threads_executing): New global. (init_thread_list): Clear 'threads_executing'. (set_executing): Set or clear 'threads_executing'. (threads_are_executing): New function. (update_threads_executing): New function. (update_thread_list): Use it. gdb/testsuite/ 2014-10-02 Pedro Alves <palves@redhat.com> * gdb.threads/break-while-running.exp (test): Add new 'update_thread_list' argument. Skip "info threads" if false. (top level): Add new 'update_thread_list' axis.
2014-10-02 08:55:38 +00:00
proc test { update_thread_list always_inserted non_stop } {
Fix "breakpoint always-inserted off"; remove "breakpoint always-inserted auto" By default, GDB removes all breakpoints from the target when the target stops and the prompt is given back to the user. This is useful in case GDB crashes while the user is interacting, as otherwise, there's a higher chance breakpoints would be left planted on the target. But, as long as any thread is running free, we need to make sure to keep breakpoints inserted, lest a thread misses a breakpoint. With that in mind, in preparation for non-stop mode, we added a "breakpoint always-inserted on" mode. This traded off the extra crash protection for never having threads miss breakpoints, and in addition is more efficient if there's a ton of breakpoints to remove/insert at each user command (e.g., at each "step"). When we added non-stop mode, and for a period, we required users to manually set "always-inserted on" when they enabled non-stop mode, as otherwise GDB removes all breakpoints from the target as soon as any thread stops, which means the other threads still running will miss breakpoints. The test added by this patch exercises this. That soon revealed a nuisance, and so later we added an extra "breakpoint always-inserted auto" mode, that made GDB behave like "always-inserted on" when non-stop was enabled, and "always-inserted off" when non-stop was disabled. "auto" was made the default at the same time. In hindsight, this "auto" setting was unnecessary, and not the ideal solution. Non-stop mode does depends on breakpoints always-inserted mode, but only as long as any thread is running. If no thread is running, no breakpoint can be missed. The same is true for all-stop too. E.g., if, in all-stop mode, and the user does: (gdb) c& (gdb) b foo That breakpoint at "foo" should be inserted immediately, but it currently isn't -- currently it'll end up inserted only if the target happens to trip on some event, and is re-resumed, e.g., an internal breakpoint triggers that doesn't cause a user-visible stop, and so we end up in keep_going calling insert_breakpoints. The test added by this patch also covers this. IOW, no matter whether in non-stop or all-stop, if the target fully stops, we can remove breakpoints. And no matter whether in all-stop or non-stop, if any thread is running in the target, then we need breakpoints to be immediately inserted. And then, if the target has global breakpoints, we need to keep breakpoints even when the target is stopped. So with that in mind, and aiming at reducing all-stop vs non-stop differences for all-stop-on-stop-of-non-stop, this patch fixes "breakpoint always-inserted off" to not remove breakpoints from the target until it fully stops, and then removes the "auto" setting as unnecessary. I propose removing it straight away rather than keeping it as an alias, unless someone complains they have scripts that need it and that can't adjust. Tested on x86_64 Fedora 20. gdb/ 2014-09-22 Pedro Alves <palves@redhat.com> * NEWS: Mention merge of "breakpoint always-inserted" modes "off" and "auto" merged. * breakpoint.c (enum ugll_insert_mode): New enum. (always_inserted_mode): Now a plain boolean. (show_always_inserted_mode): No longer handle AUTO_BOOLEAN_AUTO. (breakpoints_always_inserted_mode): Delete. (breakpoints_should_be_inserted_now): New function. (insert_breakpoints): Pass UGLL_INSERT to update_global_location_list instead of calling insert_breakpoint_locations manually. (create_solib_event_breakpoint_1): New, factored out from ... (create_solib_event_breakpoint): ... this. (create_and_insert_solib_event_breakpoint): Use create_solib_event_breakpoint_1 instead of calling insert_breakpoint_locations manually. (update_global_location_list): Change parameter type from boolean to enum ugll_insert_mode. All callers adjusted. Adjust to use breakpoints_should_be_inserted_now and handle UGLL_INSERT. (update_global_location_list_nothrow): Change parameter type from boolean to enum ugll_insert_mode. (_initialize_breakpoint): "breakpoint always-inserted" option is now a boolean command. Update help text. * breakpoint.h (breakpoints_always_inserted_mode): Delete declaration. (breakpoints_should_be_inserted_now): New declaration. * infrun.c (handle_inferior_event) <TARGET_WAITKIND_LOADED>: Remove breakpoints_always_inserted_mode check. (normal_stop): Adjust to use breakpoints_should_be_inserted_now. * remote.c (remote_start_remote): Likewise. gdb/doc/ 2014-09-22 Pedro Alves <palves@redhat.com> * gdb.texinfo (Set Breaks): Document that "set breakpoint always-inserted off" is the default mode now. Delete documentation of "set breakpoint always-inserted auto". gdb/testsuite/ 2014-09-22 Pedro Alves <palves@redhat.com> * gdb.threads/break-while-running.exp: New file. * gdb.threads/break-while-running.c: New file.
2014-09-22 08:56:55 +00:00
global srcfile binfile
global gdb_prompt
global decimal
clean_restart $binfile
gdb_test_no_output "set non-stop $non_stop"
gdb_test_no_output "set breakpoint always-inserted $always_inserted"
if ![runto_main] {
return -1
}
# In all-stop, check whether we're testing with the remote or
# extended-remote targets. If so, skip the tests, as with the
# RSP, we can't issue commands until the target replies to vCont.
# Not an issue with the non-stop RSP variant, which has a
# non-blocking vCont.
if {$non_stop=="off" && [gdb_is_target_remote]} {
return -1
}
gdb_breakpoint [gdb_get_line_number "set wait-thread breakpoint here"]
gdb_continue_to_breakpoint "run to wait-thread breakpoint"
delete_breakpoints
# Leave the main thread stopped, so GDB can poke at memory freely.
if {$non_stop == "off"} {
gdb_test_no_output "set scheduler-locking on"
gdb_test "thread 2" "Switching to .*"
gdb_test "continue &" "Continuing\." "continuing thread 2"
gdb_test "thread 3" "Switching to .*"
gdb_test "continue &" "Continuing\." "continuing thread 3"
gdb_test "thread 1" "Switching to .*" "switch back to main thread"
}
Fix non-stop regressions caused by "breakpoints always-inserted off" changes Commit a25a5a45 (Fix "breakpoint always-inserted off"; remove "breakpoint always-inserted auto") regressed non-stop remote debugging. This was exposed by mi-nsintrall.exp intermittently failing with a spurious SIGTRAP. The problem is that when debugging with "target remote", new threads the target has spawned but have never reported a stop aren't visible to GDB until it explicitly resyncs its thread list with the target's. For example, in a program like this: int main (void) { pthread_t child_thread; pthread_create (&child_thread, NULL, child_function, NULL); return 0; <<<< set breakpoint here } If the user sets a breakpoint at the "return" statement, and runs the program, when that breakpoint hit is reported, GDB is only aware of the main thread. So if we base the decision to remove or insert breakpoints from the target based on whether all the threads we know about are stopped, we'll miss that child_thread is running, and thus we'll remove breakpoints from the target, even through they should still remain inserted, otherwise child_thread will miss them. The break-while-running.exp test actually should also be exposing this thread-list-out-of-synch problem. That test sets a breakpoint while the main thread is stopped, but other threads are running. Because other threads are running, the breakpoint is supposed to be inserted immediately. But, unless something forces a refetch of the thread list, like, e.g., "info threads", GDB won't be aware of the other threads that had been spawned by the main thread, and so won't insert new or old breakpoints in the target. And it turns out that the test is exactly doing an explicit "info threads", masking out the problem... This commit adjust the test to exercise the case of not issuing "info threads". The test then fails without the GDB fix. In the ni-nsintrall.exp case, what happens is that several threads hit the same breakpoint, and when the first thread reports the stop, because GDB wasn't aware other threads exist, all threads known to GDB are found stopped, so GDB removes the breakpoints from the target. The other threads follow up with SIGTRAPs too for that same breakpoint, which has already been removed. For the first few threads, the moribund breakpoints machinery suppresses the SIGTRAPs, but after a few events (precisely '3 * thread_count () + 1' at the time the breakpoint was removed, see update_global_location_list), the moribund breakpoint machinery is no longer aware of the removed breakpoint, and the SIGTRAP is reported as a spurious stop. The fix is naturally then to stop assuming that if no thread in the list is executing, then the target is fully stopped. We can't know that until we fully sync the thread list. Because updating the thread list on every stop would be too much RSP traffic, I chose instead to update it whenever we're about to present a stop to the user. Actually updating the thread list at that point happens to be an item I had added to the local/remote parity wiki page a while ago: Native GNU/Linux debugging adds new threads to the thread list as the program creates them "The [New Thread foo] messages". Remote debugging can't do that, and it's arguable whether we shouldn't even stop native debugging from doing that, as it hinders inferior performance. However, a related issue is that with remote targets (and gdbserver), even after the program stops, the user still needs to do "info threads" to pull an updated thread list. This, should most likely be addressed, so that GDB pulls the list itself, perhaps just before presenting a stop to the user. With that in place, the need to delay "Program received signal FOO" was actually caught by the manythreads.exp test. Without that bit, I was getting: [Thread 0x7ffff7f13700 (LWP 4499) exited] [New Thread 0x7ffff7f0b700 (LWP 4500)] ^C Program received signal SIGINT, Interrupt. [New Thread 0x7ffff7f03700 (LWP 4501)] <<< new output [Switching to Thread 0x7ffff7f0b700 (LWP 4500)] __GI___nptl_death_event () at events.c:31 31 { (gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1 That is, I was now getting "New Thread" lines after the "Program received signal" line, and the test doesn't expect them. As the number of new threads discovered before and after the "Program received signal" output is unbounded, it's much nicer to defer "Program received signal" until after synching the thread list, thus close to the "switching to thread" output and "current frame/source" info: [Thread 0x7ffff7863700 (LWP 7647) exited] ^C[New Thread 0x7ffff786b700 (LWP 7648)] Program received signal SIGINT, Interrupt. [Switching to Thread 0x7ffff7fc4740 (LWP 6243)] __GI___nptl_create_event () at events.c:25 25 { (gdb) PASS: gdb.threads/manythreads.exp: stop threads 1 Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-02 Pedro Alves <palves@redhat.com> * breakpoint.c (breakpoints_should_be_inserted_now): Use threads_are_executing. * breakpoint.h (breakpoints_should_be_inserted_now): Add describing comment. * gdbthread.h (threads_are_executing): Declare. (handle_signal_stop) <random signals>: Don't print about the signal here if stopping. (end_stepping_range): Don't notify observers here. (normal_stop): Update the thread list. If stopped by a random signal or a stepping range ended, notify observers. * thread.c (threads_executing): New global. (init_thread_list): Clear 'threads_executing'. (set_executing): Set or clear 'threads_executing'. (threads_are_executing): New function. (update_threads_executing): New function. (update_thread_list): Use it. gdb/testsuite/ 2014-10-02 Pedro Alves <palves@redhat.com> * gdb.threads/break-while-running.exp (test): Add new 'update_thread_list' argument. Skip "info threads" if false. (top level): Add new 'update_thread_list' axis.
2014-10-02 08:55:38 +00:00
# Test with and without pulling the thread list explicitly with
# "info threads". GDB should be able to figure out itself whether
# the target is running and thus breakpoints should be inserted,
# without the user explicitly fetching the thread list.
if {$update_thread_list} {
gdb_test "info threads" \
"\\\(running\\\).*\\\(running\\\).* main .*" \
"only main stopped"
}
Fix "breakpoint always-inserted off"; remove "breakpoint always-inserted auto" By default, GDB removes all breakpoints from the target when the target stops and the prompt is given back to the user. This is useful in case GDB crashes while the user is interacting, as otherwise, there's a higher chance breakpoints would be left planted on the target. But, as long as any thread is running free, we need to make sure to keep breakpoints inserted, lest a thread misses a breakpoint. With that in mind, in preparation for non-stop mode, we added a "breakpoint always-inserted on" mode. This traded off the extra crash protection for never having threads miss breakpoints, and in addition is more efficient if there's a ton of breakpoints to remove/insert at each user command (e.g., at each "step"). When we added non-stop mode, and for a period, we required users to manually set "always-inserted on" when they enabled non-stop mode, as otherwise GDB removes all breakpoints from the target as soon as any thread stops, which means the other threads still running will miss breakpoints. The test added by this patch exercises this. That soon revealed a nuisance, and so later we added an extra "breakpoint always-inserted auto" mode, that made GDB behave like "always-inserted on" when non-stop was enabled, and "always-inserted off" when non-stop was disabled. "auto" was made the default at the same time. In hindsight, this "auto" setting was unnecessary, and not the ideal solution. Non-stop mode does depends on breakpoints always-inserted mode, but only as long as any thread is running. If no thread is running, no breakpoint can be missed. The same is true for all-stop too. E.g., if, in all-stop mode, and the user does: (gdb) c& (gdb) b foo That breakpoint at "foo" should be inserted immediately, but it currently isn't -- currently it'll end up inserted only if the target happens to trip on some event, and is re-resumed, e.g., an internal breakpoint triggers that doesn't cause a user-visible stop, and so we end up in keep_going calling insert_breakpoints. The test added by this patch also covers this. IOW, no matter whether in non-stop or all-stop, if the target fully stops, we can remove breakpoints. And no matter whether in all-stop or non-stop, if any thread is running in the target, then we need breakpoints to be immediately inserted. And then, if the target has global breakpoints, we need to keep breakpoints even when the target is stopped. So with that in mind, and aiming at reducing all-stop vs non-stop differences for all-stop-on-stop-of-non-stop, this patch fixes "breakpoint always-inserted off" to not remove breakpoints from the target until it fully stops, and then removes the "auto" setting as unnecessary. I propose removing it straight away rather than keeping it as an alias, unless someone complains they have scripts that need it and that can't adjust. Tested on x86_64 Fedora 20. gdb/ 2014-09-22 Pedro Alves <palves@redhat.com> * NEWS: Mention merge of "breakpoint always-inserted" modes "off" and "auto" merged. * breakpoint.c (enum ugll_insert_mode): New enum. (always_inserted_mode): Now a plain boolean. (show_always_inserted_mode): No longer handle AUTO_BOOLEAN_AUTO. (breakpoints_always_inserted_mode): Delete. (breakpoints_should_be_inserted_now): New function. (insert_breakpoints): Pass UGLL_INSERT to update_global_location_list instead of calling insert_breakpoint_locations manually. (create_solib_event_breakpoint_1): New, factored out from ... (create_solib_event_breakpoint): ... this. (create_and_insert_solib_event_breakpoint): Use create_solib_event_breakpoint_1 instead of calling insert_breakpoint_locations manually. (update_global_location_list): Change parameter type from boolean to enum ugll_insert_mode. All callers adjusted. Adjust to use breakpoints_should_be_inserted_now and handle UGLL_INSERT. (update_global_location_list_nothrow): Change parameter type from boolean to enum ugll_insert_mode. (_initialize_breakpoint): "breakpoint always-inserted" option is now a boolean command. Update help text. * breakpoint.h (breakpoints_always_inserted_mode): Delete declaration. (breakpoints_should_be_inserted_now): New declaration. * infrun.c (handle_inferior_event) <TARGET_WAITKIND_LOADED>: Remove breakpoints_always_inserted_mode check. (normal_stop): Adjust to use breakpoints_should_be_inserted_now. * remote.c (remote_start_remote): Likewise. gdb/doc/ 2014-09-22 Pedro Alves <palves@redhat.com> * gdb.texinfo (Set Breaks): Document that "set breakpoint always-inserted off" is the default mode now. Delete documentation of "set breakpoint always-inserted auto". gdb/testsuite/ 2014-09-22 Pedro Alves <palves@redhat.com> * gdb.threads/break-while-running.exp: New file. * gdb.threads/break-while-running.c: New file.
2014-09-22 08:56:55 +00:00
# Don't use gdb_test as it's racy in this case -- gdb_test matches
# the prompt with an end anchor. Sometimes expect will manage to
# read the breakpoint hit output while still processing this test,
# defeating the anchor.
set test "set breakpoint while a thread is running"
gdb_test_multiple "break breakpoint_function" $test {
-re "Breakpoint $decimal at .*: file .*$srcfile.*\r\n$gdb_prompt " {
pass $test
}
-re "$gdb_prompt " {
fail $test
}
}
# Check that the breakpoint is hit. Can't use gdb_test here, as
# no prompt is expected to come out.
set test "breakpoint is hit"
gdb_test_multiple "" $test {
-re "Breakpoint .*, breakpoint_function \[^\r\n\]+" {
pass $test
}
}
if {$non_stop == "on"} {
gdb_test "info threads" \
"\\\(running\\\).* breakpoint_function .* main .*" \
"one thread running"
# Unblock the other thread, which should then trip on the same
# breakpoint, unless GDB removed it by mistake. Can't use
# gdb_test here for the same reasons as above.
set test "unblock second thread"
gdb_test_multiple "print second_child = 1" $test {
-re " = 1\r\n$gdb_prompt " {
pass $test
}
-re "$gdb_prompt " {
fail $test
}
}
set test "breakpoint on second child is hit"
gdb_test_multiple "" $test {
-re "Breakpoint .*, breakpoint_function \[^\r\n\]+" {
pass $test
}
}
gdb_test "info threads" \
" breakpoint_function .* breakpoint_function .* main .*" \
"all threads stopped"
} else {
# This test is not merged with the non-stop one because in
# all-stop we don't know where the other thread stops (inside
# usleep, for example).
set test "all threads stopped"
gdb_test_multiple "info threads" "$test" {
-re "\\\(running\\\).*$gdb_prompt $" {
fail $test
}
-re "breakpoint_function .* main .*$gdb_prompt $" {
pass $test
}
}
}
}
Fix non-stop regressions caused by "breakpoints always-inserted off" changes Commit a25a5a45 (Fix "breakpoint always-inserted off"; remove "breakpoint always-inserted auto") regressed non-stop remote debugging. This was exposed by mi-nsintrall.exp intermittently failing with a spurious SIGTRAP. The problem is that when debugging with "target remote", new threads the target has spawned but have never reported a stop aren't visible to GDB until it explicitly resyncs its thread list with the target's. For example, in a program like this: int main (void) { pthread_t child_thread; pthread_create (&child_thread, NULL, child_function, NULL); return 0; <<<< set breakpoint here } If the user sets a breakpoint at the "return" statement, and runs the program, when that breakpoint hit is reported, GDB is only aware of the main thread. So if we base the decision to remove or insert breakpoints from the target based on whether all the threads we know about are stopped, we'll miss that child_thread is running, and thus we'll remove breakpoints from the target, even through they should still remain inserted, otherwise child_thread will miss them. The break-while-running.exp test actually should also be exposing this thread-list-out-of-synch problem. That test sets a breakpoint while the main thread is stopped, but other threads are running. Because other threads are running, the breakpoint is supposed to be inserted immediately. But, unless something forces a refetch of the thread list, like, e.g., "info threads", GDB won't be aware of the other threads that had been spawned by the main thread, and so won't insert new or old breakpoints in the target. And it turns out that the test is exactly doing an explicit "info threads", masking out the problem... This commit adjust the test to exercise the case of not issuing "info threads". The test then fails without the GDB fix. In the ni-nsintrall.exp case, what happens is that several threads hit the same breakpoint, and when the first thread reports the stop, because GDB wasn't aware other threads exist, all threads known to GDB are found stopped, so GDB removes the breakpoints from the target. The other threads follow up with SIGTRAPs too for that same breakpoint, which has already been removed. For the first few threads, the moribund breakpoints machinery suppresses the SIGTRAPs, but after a few events (precisely '3 * thread_count () + 1' at the time the breakpoint was removed, see update_global_location_list), the moribund breakpoint machinery is no longer aware of the removed breakpoint, and the SIGTRAP is reported as a spurious stop. The fix is naturally then to stop assuming that if no thread in the list is executing, then the target is fully stopped. We can't know that until we fully sync the thread list. Because updating the thread list on every stop would be too much RSP traffic, I chose instead to update it whenever we're about to present a stop to the user. Actually updating the thread list at that point happens to be an item I had added to the local/remote parity wiki page a while ago: Native GNU/Linux debugging adds new threads to the thread list as the program creates them "The [New Thread foo] messages". Remote debugging can't do that, and it's arguable whether we shouldn't even stop native debugging from doing that, as it hinders inferior performance. However, a related issue is that with remote targets (and gdbserver), even after the program stops, the user still needs to do "info threads" to pull an updated thread list. This, should most likely be addressed, so that GDB pulls the list itself, perhaps just before presenting a stop to the user. With that in place, the need to delay "Program received signal FOO" was actually caught by the manythreads.exp test. Without that bit, I was getting: [Thread 0x7ffff7f13700 (LWP 4499) exited] [New Thread 0x7ffff7f0b700 (LWP 4500)] ^C Program received signal SIGINT, Interrupt. [New Thread 0x7ffff7f03700 (LWP 4501)] <<< new output [Switching to Thread 0x7ffff7f0b700 (LWP 4500)] __GI___nptl_death_event () at events.c:31 31 { (gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1 That is, I was now getting "New Thread" lines after the "Program received signal" line, and the test doesn't expect them. As the number of new threads discovered before and after the "Program received signal" output is unbounded, it's much nicer to defer "Program received signal" until after synching the thread list, thus close to the "switching to thread" output and "current frame/source" info: [Thread 0x7ffff7863700 (LWP 7647) exited] ^C[New Thread 0x7ffff786b700 (LWP 7648)] Program received signal SIGINT, Interrupt. [Switching to Thread 0x7ffff7fc4740 (LWP 6243)] __GI___nptl_create_event () at events.c:25 25 { (gdb) PASS: gdb.threads/manythreads.exp: stop threads 1 Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-02 Pedro Alves <palves@redhat.com> * breakpoint.c (breakpoints_should_be_inserted_now): Use threads_are_executing. * breakpoint.h (breakpoints_should_be_inserted_now): Add describing comment. * gdbthread.h (threads_are_executing): Declare. (handle_signal_stop) <random signals>: Don't print about the signal here if stopping. (end_stepping_range): Don't notify observers here. (normal_stop): Update the thread list. If stopped by a random signal or a stepping range ended, notify observers. * thread.c (threads_executing): New global. (init_thread_list): Clear 'threads_executing'. (set_executing): Set or clear 'threads_executing'. (threads_are_executing): New function. (update_threads_executing): New function. (update_thread_list): Use it. gdb/testsuite/ 2014-10-02 Pedro Alves <palves@redhat.com> * gdb.threads/break-while-running.exp (test): Add new 'update_thread_list' argument. Skip "info threads" if false. (top level): Add new 'update_thread_list' axis.
2014-10-02 08:55:38 +00:00
foreach update_thread_list { true false } {
foreach always_inserted { "off" "on" } {
foreach non_stop { "off" "on" } {
set stop_mode [expr ($non_stop=="off")?"all-stop":"non-stop"]
set update_list_mode [expr ($update_thread_list)?"w/ithr":"wo/ithr"]
with_test_prefix "$update_list_mode: always-inserted $always_inserted: $stop_mode" {
test $update_thread_list $always_inserted $non_stop
}
Fix "breakpoint always-inserted off"; remove "breakpoint always-inserted auto" By default, GDB removes all breakpoints from the target when the target stops and the prompt is given back to the user. This is useful in case GDB crashes while the user is interacting, as otherwise, there's a higher chance breakpoints would be left planted on the target. But, as long as any thread is running free, we need to make sure to keep breakpoints inserted, lest a thread misses a breakpoint. With that in mind, in preparation for non-stop mode, we added a "breakpoint always-inserted on" mode. This traded off the extra crash protection for never having threads miss breakpoints, and in addition is more efficient if there's a ton of breakpoints to remove/insert at each user command (e.g., at each "step"). When we added non-stop mode, and for a period, we required users to manually set "always-inserted on" when they enabled non-stop mode, as otherwise GDB removes all breakpoints from the target as soon as any thread stops, which means the other threads still running will miss breakpoints. The test added by this patch exercises this. That soon revealed a nuisance, and so later we added an extra "breakpoint always-inserted auto" mode, that made GDB behave like "always-inserted on" when non-stop was enabled, and "always-inserted off" when non-stop was disabled. "auto" was made the default at the same time. In hindsight, this "auto" setting was unnecessary, and not the ideal solution. Non-stop mode does depends on breakpoints always-inserted mode, but only as long as any thread is running. If no thread is running, no breakpoint can be missed. The same is true for all-stop too. E.g., if, in all-stop mode, and the user does: (gdb) c& (gdb) b foo That breakpoint at "foo" should be inserted immediately, but it currently isn't -- currently it'll end up inserted only if the target happens to trip on some event, and is re-resumed, e.g., an internal breakpoint triggers that doesn't cause a user-visible stop, and so we end up in keep_going calling insert_breakpoints. The test added by this patch also covers this. IOW, no matter whether in non-stop or all-stop, if the target fully stops, we can remove breakpoints. And no matter whether in all-stop or non-stop, if any thread is running in the target, then we need breakpoints to be immediately inserted. And then, if the target has global breakpoints, we need to keep breakpoints even when the target is stopped. So with that in mind, and aiming at reducing all-stop vs non-stop differences for all-stop-on-stop-of-non-stop, this patch fixes "breakpoint always-inserted off" to not remove breakpoints from the target until it fully stops, and then removes the "auto" setting as unnecessary. I propose removing it straight away rather than keeping it as an alias, unless someone complains they have scripts that need it and that can't adjust. Tested on x86_64 Fedora 20. gdb/ 2014-09-22 Pedro Alves <palves@redhat.com> * NEWS: Mention merge of "breakpoint always-inserted" modes "off" and "auto" merged. * breakpoint.c (enum ugll_insert_mode): New enum. (always_inserted_mode): Now a plain boolean. (show_always_inserted_mode): No longer handle AUTO_BOOLEAN_AUTO. (breakpoints_always_inserted_mode): Delete. (breakpoints_should_be_inserted_now): New function. (insert_breakpoints): Pass UGLL_INSERT to update_global_location_list instead of calling insert_breakpoint_locations manually. (create_solib_event_breakpoint_1): New, factored out from ... (create_solib_event_breakpoint): ... this. (create_and_insert_solib_event_breakpoint): Use create_solib_event_breakpoint_1 instead of calling insert_breakpoint_locations manually. (update_global_location_list): Change parameter type from boolean to enum ugll_insert_mode. All callers adjusted. Adjust to use breakpoints_should_be_inserted_now and handle UGLL_INSERT. (update_global_location_list_nothrow): Change parameter type from boolean to enum ugll_insert_mode. (_initialize_breakpoint): "breakpoint always-inserted" option is now a boolean command. Update help text. * breakpoint.h (breakpoints_always_inserted_mode): Delete declaration. (breakpoints_should_be_inserted_now): New declaration. * infrun.c (handle_inferior_event) <TARGET_WAITKIND_LOADED>: Remove breakpoints_always_inserted_mode check. (normal_stop): Adjust to use breakpoints_should_be_inserted_now. * remote.c (remote_start_remote): Likewise. gdb/doc/ 2014-09-22 Pedro Alves <palves@redhat.com> * gdb.texinfo (Set Breaks): Document that "set breakpoint always-inserted off" is the default mode now. Delete documentation of "set breakpoint always-inserted auto". gdb/testsuite/ 2014-09-22 Pedro Alves <palves@redhat.com> * gdb.threads/break-while-running.exp: New file. * gdb.threads/break-while-running.c: New file.
2014-09-22 08:56:55 +00:00
}
}
}