From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3399 invoked by alias); 17 Aug 2011 13:17:04 -0000 Received: (qmail 3385 invoked by uid 22791); 17 Aug 2011 13:17:03 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-gy0-f169.google.com (HELO mail-gy0-f169.google.com) (209.85.160.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 17 Aug 2011 13:16:43 +0000 Received: by gyg10 with SMTP id 10so783133gyg.0 for ; Wed, 17 Aug 2011 06:16:43 -0700 (PDT) Received: by 10.42.141.197 with SMTP id p5mr796924icu.191.1313587001180; Wed, 17 Aug 2011 06:16:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.4.211 with HTTP; Wed, 17 Aug 2011 06:16:21 -0700 (PDT) In-Reply-To: <201108171325.38389.pedro@codesourcery.com> References: <201106021428.00690.pedro@codesourcery.com> <201108171325.38389.pedro@codesourcery.com> From: Kevin Pouget Date: Wed, 17 Aug 2011 13:17:00 -0000 Message-ID: Subject: Re: Python and target-async To: Pedro Alves Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-08/txt/msg00071.txt.bz2 On Wed, Aug 17, 2011 at 2:25 PM, Pedro Alves wrote: > On Wednesday 17 August 2011 12:36:28, Kevin Pouget wrote: >> On Thu, Jun 2, 2011 at 3:28 PM, Pedro Alves wro= te: >> > Very much. =A0Thanks. =A0This sounds similar to the >> > define.exp:nextwhere testcase failing in async mode. >> > That is, the attach command installing a continuation >> > and returning before the attach is complete, and >> > the "where" command executing before the inferior reports >> > a stop to the attach command continuation. >> > I've got a fix for the "nextwhere" issue, that I'll >> > need some cleaning up before pushing, though >> > I'll bet that the python code will need fixing >> > of its own. =A0:-/ > >> Hi Pedro, >> >> any update on this issue? you said that only "some cleaning up" where >> required, but it's still failing on the last gdb-CVS ... anything I >> could do to help you? I really this bit to be solved to keep going ... >> (my copyright assignment is not ready yet, but maybe some >> beta-testing?) > > The patch I was talking about this one: > > > I was pulled away for a while from the project, and I've now come back to > it. =A0Unfortunately, "Some cleaning up" turned into "large and endless > cleaning up", and I haven't reached python yet even. =A0So I came up with > a plan B, as I need to make progress on other fronts for itsets/ptsets > support which is really what I want to get at. =A0Instead of converting e= verything and > its mother to an asynchronous state machine, I've come up with the patch > below, which flips the _interpreter_ to synchronous mode when we want to > run some command list, and similars, like several python command in one > gdb command. > > This makes the testsuite run regression free in async mode, > compared to sync mode. > > I'd like to push something like this in, as first step, then suggest > flipping async mode on by default (need to discuss what happens to > MI then), so that user don't need to do "set target-async on" > anymore to enable new functionality. > > Can you give it a try? > > (Note, I haven't yet checked if/where MI will need flipping > the interpreter to sync mode). thanks a lot, this patch solves the problem described in http://sourceware.org/bugzilla/show_bug.cgi?id=3D12929, Python included, so I'll use it for my further development, and I'll let you know if I notice anything wrong Cordially, Kevin NB: I don't use MI at all, only CLI and Python