From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31350 invoked by alias); 12 May 2010 18:04:51 -0000 Received: (qmail 31283 invoked by uid 48); 12 May 2010 18:04:51 -0000 Date: Wed, 12 May 2010 18:04:00 -0000 Message-ID: <20100512180451.31282.qmail@sourceware.org> From: "pedro at codesourcery dot com" To: gdb-prs@sourceware.org In-Reply-To: <20100507183730.11580.k04jg02@gmail.com> References: <20100507183730.11580.k04jg02@gmail.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug threads/11580] scheduler-locking breaks re-runs X-Bugzilla-Reason: CC Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2010-q2/txt/msg00251.txt.bz2 ------- Additional Comments From pedro at codesourcery dot com 2010-05-12 18:04 ------- Please no special casing like that. IMO, auto disabling the setting behind the user, or frontend's back is a bad idea. Better would be to optimistically enable setting scheduler locking when the target is exec, and instead complain/error later if the target being resumed doesn't support it. That is, have the "set scheduler-lock..." command implementation confirm is it is possible to enable schedlocking on the spot iff there's execution (target_has_execution), and, have infcmd.c, `proceed', or `resume' complain is scheduler locking is on, but the current target doesn't support it. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11580 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.