From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-39291-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 27555 invoked by alias); 2 Jun 2011 13:28:19 -0000
Received: (qmail 27542 invoked by uid 22791); 2 Jun 2011 13:28:17 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0	tests=AWL,BAYES_00,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 02 Jun 2011 13:28:04 +0000
Received: (qmail 28558 invoked from network); 2 Jun 2011 13:28:03 -0000
Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2)  by mail.codesourcery.com with ESMTPA; 2 Jun 2011 13:28:03 -0000
From: Pedro Alves <pedro@codesourcery.com>
To: gdb@sourceware.org
Subject: Re: Python and target-async
Date: Thu, 02 Jun 2011 13:28:00 -0000
User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; x86_64; ; )
Cc: Kevin Pouget <kevin.pouget@gmail.com>
References: <BANLkTimGZ3DSbkRts1Oc8_ZyrAG3hi7PzA@mail.gmail.com> <201105311844.25465.pedro@codesourcery.com> <BANLkTin-cWG-C+OcHc-MAmFJDTF-EE_zVQ@mail.gmail.com>
In-Reply-To: <BANLkTin-cWG-C+OcHc-MAmFJDTF-EE_zVQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201106021428.00690.pedro@codesourcery.com>
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2011-06/txt/msg00010.txt.bz2

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