From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31730 invoked by alias); 8 Nov 2013 17:57:12 -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 12456 invoked by uid 89); 8 Nov 2013 17:45:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,SPF_HELO_PASS,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Nov 2013 17:45:16 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rA8Hj8gn009893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 8 Nov 2013 12:45:08 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rA8Hj7JD014704; Fri, 8 Nov 2013 12:45:08 -0500 Message-ID: <527D2323.2010708@redhat.com> Date: Fri, 08 Nov 2013 18:04:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tom Tromey 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> <87mwltcp8v.fsf@fleche.redhat.com> In-Reply-To: <87mwltcp8v.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-11/txt/msg00249.txt.bz2 On 10/28/2013 04:52 PM, Tom Tromey wrote: >>>>>> "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. That'll really make our lives complicated. We'll definitely hit async specific problems, and not being able to easily compare how sync behaves will be a nuisance. Also, given most targets don't support async, I think it'll be very valuable to easily check how sync mode works on native GNU/Linux as proxy for those targets -- consider patches changing run control and execution commands code. Heck, I've gone through the trouble of implementing software single-step on x86 just to be able to use that as proxy for sss targets. :-) > I think maybe it could be done by adding a new "maint" setting. Yeah, "set target-async" used to be a set of maint commands. https://sourceware.org/ml/gdb-patches/2008-08/msg00423.html We've come full circle. :-) > > 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. Yeah, making the setting be MI specific is better. > 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. Yeah, probably doesn't. We used to have this target_async_mask mechanism, that got replaced by TARGET_WNOHANG: https://sourceware.org/ml/gdb-patches/2009-05/msg00459.html and forced waits: https://sourceware.org/ml/gdb-patches/2011-06/msg00086.html Before that, the target could support async, but have it masked (so "can" would be true, "is" would be "false"). -- Pedro Alves