From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27458 invoked by alias); 17 Aug 2011 11:37:06 -0000 Received: (qmail 27398 invoked by uid 22791); 17 Aug 2011 11:37:05 -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; Wed, 17 Aug 2011 11:36:49 +0000 Received: by vxj3 with SMTP id 3so893903vxj.0 for ; Wed, 17 Aug 2011 04:36:48 -0700 (PDT) Received: by 10.52.26.204 with SMTP id n12mr823251vdg.143.1313581008171; Wed, 17 Aug 2011 04:36:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.194.195 with HTTP; Wed, 17 Aug 2011 04:36:28 -0700 (PDT) In-Reply-To: <201106021428.00690.pedro@codesourcery.com> References: <201105311844.25465.pedro@codesourcery.com> <201106021428.00690.pedro@codesourcery.com> From: Kevin Pouget Date: Wed, 17 Aug 2011 11:37: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/msg00068.txt.bz2 On Thu, Jun 2, 2011 at 3:28 PM, Pedro Alves 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 =A00x0000003cbd0aa47e in waitpid () from /lib64/libc.so.6 > > > #1 =A00x000000000043ede2 in ?? () > > > #2 =A00x000000000044005f in wait_for () > > > #3 =A00x0000000000430c45 in execute_command_internal () > > > #4 =A00x0000000000430e0e in execute_command () > > > #5 =A00x000000000041d526 in reader_loop () > > > #6 =A00x000000000041ccde 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 =A00x0000003cbd0aa47e in ?? () > > > #1 =A00x0000000000000000 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 =A00x0000003cbd0aa47e in waitpid () from /lib64/libc.so.6 > > > #1 =A00x000000000043ede2 in ?? () > > > #2 =A00x000000000044005f in wait_for () > > > #3 =A00x0000000000430c45 in execute_command_internal () > > > #4 =A00x0000000000430e0e in execute_command () > > > #5 =A00x000000000041d526 in reader_loop () > > > #6 =A00x000000000041ccde in main () > > > > is it clearer this way ? > > 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:-/ > > -- > 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=3D12929 )