This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Python and target-async
- From: Kevin Pouget <kevin dot pouget at gmail dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb at sourceware dot org
- Date: Wed, 17 Aug 2011 13:36:28 +0200
- Subject: Re: Python and target-async
- References: <BANLkTimGZ3DSbkRts1Oc8_ZyrAG3hi7PzA@mail.gmail.com> <201105311844.25465.pedro@codesourcery.com> <BANLkTin-cWG-C+OcHc-MAmFJDTF-EE_zVQ@mail.gmail.com> <201106021428.00690.pedro@codesourcery.com>
On Thu, Jun 2, 2011 at 3:28 PM, Pedro Alves <pedro@codesourcery.com> wrote:
>
> On Tuesday 31 May 2011 18:54:10, Kevin Pouget wrote:
> > > you have "set target-async on" twice. Was that a pasto?
> >
> > sorry, yes the first one was wrong
> >
> > here is the correct behaviour:
> >
> > > (gdb) set target-async off
> > > (gdb) py gdb.execute("attach PID") ; gdb.execute("where")
> > > 0x0000003cbd0aa47e in waitpid () from /lib64/libc.so.6
> > > #0 ?0x0000003cbd0aa47e in waitpid () from /lib64/libc.so.6
> > > #1 ?0x000000000043ede2 in ?? ()
> > > #2 ?0x000000000044005f in wait_for ()
> > > #3 ?0x0000000000430c45 in execute_command_internal ()
> > > #4 ?0x0000000000430e0e in execute_command ()
> > > #5 ?0x000000000041d526 in reader_loop ()
> > > #6 ?0x000000000041ccde in main ()
> >
> > and this one is wrong because the backtrace is not correctly computed:
> >
> > > (gdb) set target-async on
> > > (gdb) py gdb.execute("attach PID") ; gdb.execute("where")
> > > #0 ?0x0000003cbd0aa47e in ?? ()
> > > #1 ?0x0000000000000000 in ?? ()
> > > 0x0000003cbd0aa47e in waitpid () from /lib64/libc.so.6
> >
> > I expected to read:
> >
> > > (gdb) set target-async on
> > > (gdb) py gdb.execute("attach PID") ; gdb.execute("where")
> > > 0x0000003cbd0aa47e in waitpid () from /lib64/libc.so.6
> > > #0 ?0x0000003cbd0aa47e in waitpid () from /lib64/libc.so.6
> > > #1 ?0x000000000043ede2 in ?? ()
> > > #2 ?0x000000000044005f in wait_for ()
> > > #3 ?0x0000000000430c45 in execute_command_internal ()
> > > #4 ?0x0000000000430e0e in execute_command ()
> > > #5 ?0x000000000041d526 in reader_loop ()
> > > #6 ?0x000000000041ccde in main ()
> >
> > is it clearer this way ?
>
> 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. ?:-/
>
> --
> Pedro Alves
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?)
Thanks,
Kevin
( http://sourceware.org/bugzilla/show_bug.cgi?id=12929 )