Re: Python and target-async

[Kevin Pouget <kevin.pouget@gmail.com>]

> On Wed, Aug 17, 2011 at 2:25 PM, Pedro Alves <pedro@codesourcery.com> wrote:
> > On Wednesday 17 August 2011 12:36:28, Kevin Pouget wrote:
> >> On Thu, Jun 2, 2011 at 3:28 PM, Pedro Alves <pedro@codesourcery.com> wrote:
> >> > Very much.  Thanks.  This 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.  :-/
> >
> >> 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:
> > <http://sourceware.org/ml/gdb-patches/2011-06/msg00158.html>
> >
> > I was pulled away for a while from the project, and I've now come back to
> > it.  Unfortunately, "Some cleaning up" turned into "large and endless
> > cleaning up", and I haven't reached python yet even.  So 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.  Instead 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=12929, 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 further
> 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=13110 :

> ...gdb/thread.c:623: internal-error: is_thread_state: Assertion `tp' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.

Any thought on what to do for that?

Thanks,

Kevin