From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26223 invoked by alias); 8 Nov 2013 21:53:38 -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 26213 invoked by uid 89); 8 Nov 2013 21:53:37 -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 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 21:53:37 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rA8LrT68009555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 8 Nov 2013 16:53:29 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rA8LrSrL010825; Fri, 8 Nov 2013 16:53:29 -0500 Message-ID: <527D5D58.4030707@redhat.com> Date: Sat, 09 Nov 2013 03:35: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> <527D2323.2010708@redhat.com> <87ob5uodry.fsf@fleche.redhat.com> In-Reply-To: <87ob5uodry.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-11/txt/msg00254.txt.bz2 On 11/08/2013 08:10 PM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > > Tom> With this series, there's no way to force sync mode. > > Pedro> That'll really make our lives complicated. We'll definitely > Pedro> hit async specific problems, and not being able to easily > Pedro> compare how sync behaves will be a nuisance. Also, given most > Pedro> targets don't support async, I think it'll be very valuable > Pedro> to easily check how sync mode works on native GNU/Linux as proxy > Pedro> for those targets -- consider patches changing run control and > Pedro> execution commands code. Heck, I've gone through the trouble > Pedro> of implementing software single-step on x86 just to be able > Pedro> to use that as proxy for sss targets. :-) > > Ok. I will add it back under "maint". Thanks. > > I think the in the long run it would be better if all targets were > async. Yes, of course. It requires per-target work, however... I'm not seeing that happen anytime soon. (and djgpp might be a challenge.) > I think this is preferable because async is an enabling feature > for other features, and because removing sync mode would simplify one of > the more complicated parts of gdb. Certainly. >>> While we're here, I wonder now whether the distinction between "can >>> async" and "is async" makes sense any more. > > Pedro> Yeah, probably doesn't. > > I'll remove "is_async". Unless you'd rather I remove "can_async". No, that's fine. "is_async" would be my choice as well. -- Pedro Alves