From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88278 invoked by alias); 18 Sep 2015 15:02:38 -0000 Mailing-List: contact gdb-testers-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-testers-owner@sourceware.org Received: (qmail 88265 invoked by uid 89); 18 Sep 2015 15:02:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: kwanyin.sergiodj.net Received: from kwanyin.sergiodj.net (HELO kwanyin.sergiodj.net) (176.31.208.32) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 18 Sep 2015 15:02:36 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [binutils-gdb] infrun: scheduler-locking replay From: sergiodj+buildbot@redhat.com To: gdb-testers@sourceware.org Message-Id: Date: Fri, 18 Sep 2015 15:44:00 -0000 X-SW-Source: 2015-q3/txt/msg11897.txt.bz2 *** TEST RESULTS FOR COMMIT f2665db5f2c20f3f47673ad5343738b10ce81dde *** Author: Markus Metzger Branch: master Commit: f2665db5f2c20f3f47673ad5343738b10ce81dde infrun: scheduler-locking replay Record targets behave as if scheduler-locking were on in replay mode. Add a new scheduler-locking option "replay" to make this implicit behaviour explicit. It behaves like "on" in replay mode and like "off" in record mode. By making the current behaviour a scheduler-locking option, we allow the user to change it. Since it is the current behaviour, this new option is also the new default. One caveat is that when resuming a thread that is at the end of its execution history, record btrace implicitly stops replaying other threads and resumes the entire process. This is a convenience feature to not require the user to explicitly move all other threads to the end of their execution histories before being able to resume the process. We mimick this behaviour with scheduler-locking replay and move it from record-btrace into infrun. With all-stop on top of non-stop, we can't do this in record-btrace anymore. Record full does not really support multi-threading and is therefore not impacted. If it were extended to support multi-threading, it would 'benefit' from this change. The good thing is that all record targets will behave the same with respect to scheduler-locking. I put the code for this into clear_proceed_status. It also sends the about_to_proceed notification. gdb/ * NEWS: Announce new scheduler-locking mode. * infrun.c (schedlock_replay): New. (scheduler_enums): Add schedlock_replay. (scheduler_mode): Change default to schedlock_replay. (user_visible_resume_ptid): Handle schedlock_replay. (clear_proceed_status_thread): Stop replaying if resumed thread is not replaying. (schedlock_applies): Handle schedlock_replay. (_initialize_infrun): Document new scheduler-locking mode. * record-btrace.c (record_btrace_resume): Remove code to stop other threads when not replaying the resumed thread. doc/ * gdb.texinfo (All-Stop Mode): Describe new scheduler-locking mode.