From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15387 invoked by alias); 8 Nov 2013 20:10:51 -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 15378 invoked by uid 89); 8 Nov 2013 20:10:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 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 20:10:50 +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 rA8KAg0q021117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 8 Nov 2013 15:10:42 -0500 Received: from barimba (ovpn-113-94.phx2.redhat.com [10.3.113.94]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rA8KAfDZ000535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 8 Nov 2013 15:10:42 -0500 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> <87mwltcp8v.fsf@fleche.redhat.com> <527D2323.2010708@redhat.com> Date: Fri, 08 Nov 2013 21:53:00 -0000 In-Reply-To: <527D2323.2010708@redhat.com> (Pedro Alves's message of "Fri, 08 Nov 2013 17:45:07 +0000") Message-ID: <87ob5uodry.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-11/txt/msg00253.txt.bz2 >>>>> "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". I think the in the long run it would be better if all targets were async. 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. This is different from software single-step because, IIUC, SSS is an intrinsic feature of some ports; whereas sync targets are purely internal issues to gdb. >> 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". Tom