From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23524 invoked by alias); 18 Sep 2012 15:06:07 -0000 Received: (qmail 23509 invoked by uid 22791); 18 Sep 2012 15:06:06 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 18 Sep 2012 15:05:47 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id C97A11C778F; Tue, 18 Sep 2012 11:05:46 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VumIJPGrVgGu; Tue, 18 Sep 2012 11:05:46 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 9067F1C7716; Tue, 18 Sep 2012 11:05:46 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 19EF3C6963; Tue, 18 Sep 2012 08:05:43 -0700 (PDT) Date: Tue, 18 Sep 2012 15:06:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [RFA] wrong language used when re-setting breakpoint Message-ID: <20120918150542.GD3276@adacore.com> References: <1347928803-15526-1-git-send-email-brobecker@adacore.com> <87k3vrxu2o.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k3vrxu2o.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-09/txt/msg00364.txt.bz2 > I think the breakpoint re-setting code should be temporarily setting > current_language. breakpoint_re_set does this. I kind of agree, but ... at the same time, this type of changes then makes it harder for us to make progress in getting rid of the current_language global, no? Also, I think that relying on the global being set for a defined period of time is a little risky. It seems too easy for the current_language to change right from under us as a side-effect of some sub-action. > I don't have a problem with your patch. I think it is an improvement. > But I think it is important to understand why the current mechanism > isn't working, since I think a failure here may have other bad effects > as well. OK - I will commit the patch, then. But I think we'd be better off trying to find the other bad effects, and see if we can use a parameter to fix them, rather than making sure the global is set properly. The problem with my suggested approach, however, is that we have to wait for bugs that reveal those bad effects. Thanks, -- Joel