From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2058 invoked by alias); 19 Aug 2011 13:35:47 -0000 Received: (qmail 1929 invoked by uid 22791); 19 Aug 2011 13:35:46 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-vx0-f169.google.com (HELO mail-vx0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Aug 2011 13:35:28 +0000 Received: by vxj3 with SMTP id 3so3119779vxj.0 for ; Fri, 19 Aug 2011 06:35:27 -0700 (PDT) Received: by 10.220.191.198 with SMTP id dn6mr634891vcb.81.1313760927276; Fri, 19 Aug 2011 06:35:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.194.195 with HTTP; Fri, 19 Aug 2011 06:35:07 -0700 (PDT) In-Reply-To: References: <201106021428.00690.pedro@codesourcery.com> <201108171325.38389.pedro@codesourcery.com> From: Kevin Pouget Date: Fri, 19 Aug 2011 13:35: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/msg00083.txt.bz2 > On Wed, Aug 17, 2011 at 2:25 PM, Pedro Alves wro= te: > > On Wednesday 17 August 2011 12:36:28, Kevin Pouget wrote: > >> On Thu, Jun 2, 2011 at 3:28 PM, Pedro Alves w= rote: > >> > 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 wi= th > > 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= everything 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 Hello Pedro, it seems that Python doesn't entirely come for free with your patch: although > (gdb) py gdb.execute("attach PID") ; gdb.execute("where") gives the expected output, class cmd_test(gdb.Command): def __init__(self): gdb.Command.__init__ (self, "test", gdb.COMMAND_NONE) def invoke (self, args, from_tty): gdb.execute("attach %s" % args) gdb.execute("where") #gdb.execute("detach") cmd_test() always returns something like > (gdb) test PID > #0 0x47eab690 in ?? () > Backtrace stopped: Not enough registers or memory available to unwind fur= ther > 0x0000003c47eab690 in __nanosleep_nocancel () from /lib64/libc.so.6 furthermore, the `gdb.execute("detach")' which I commented out above, leads to the internal_error that I reported in http://sourceware.org/bugzilla/show_bug.cgi?id=3D13110 : > ...gdb/thread.c:623: internal-error: is_thread_state: Assertion `tp' fail= ed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. Any thought on what to do for that? Thanks, Kevin