From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15947 invoked by alias); 28 Oct 2013 16:52:04 -0000 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 Received: (qmail 15934 invoked by uid 89); 28 Oct 2013 16:52:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 28 Oct 2013 16:52:03 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9SGq1P3011208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Oct 2013 12:52:02 -0400 Received: from barimba (ovpn-113-94.phx2.redhat.com [10.3.113.94]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r9SGq05g030477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Oct 2013 12:52:01 -0400 From: Tom Tromey To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v4 2/9] add "this" pointers to more target APIs References: <1382464769-2465-1-git-send-email-tromey@redhat.com> <1382464769-2465-3-git-send-email-tromey@redhat.com> <526E8AF2.7050202@redhat.com> <87r4b5cpxd.fsf@fleche.redhat.com> <526E9451.6050103@redhat.com> Date: Mon, 28 Oct 2013 16:52:00 -0000 In-Reply-To: <526E9451.6050103@redhat.com> (Pedro Alves's message of "Mon, 28 Oct 2013 16:44:01 +0000") Message-ID: <87mwltcp8v.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-10/txt/msg00868.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> On 10/28/2013 04:37 PM, Tom Tromey wrote: >> >> It is all moot, I think. There is no reason for linux-nat to ever call >> linux_nat_is_async_p any more. I think we can drop all the dead code >> instead. I noted this in the first submission and said I will do it in >> a followup; but I think I'll just tack it on to this series instead. Pedro> I'd rather keep the code to allow forcing sync mode for a while, Pedro> to make it easier to debug problems and compare modes. With this series, there's no way to force sync mode. I think maybe it could be done by adding a new "maint" setting. We can't reuse "set target-async" due to the MI misuse, unless we're willing to change the default setting of this parameter based on the current interpreter. In fact an earlier version of my patch series did just this, but IIRC I thought it was too hackish. While we're here, I wonder now whether the distinction between "can async" and "is async" makes sense any more. I'm inclined to remove one of them. Tom