From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16722 invoked by alias); 13 Apr 2009 19:00:06 -0000 Received: (qmail 16659 invoked by uid 22791); 13 Apr 2009 19:00:05 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e24smtp01.br.ibm.com (HELO e24smtp01.br.ibm.com) (32.104.18.85) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 13 Apr 2009 18:59:57 +0000 Received: from d24relay01.br.ibm.com (d24relay01.br.ibm.com [9.8.31.16]) by e24smtp01.br.ibm.com (8.13.1/8.13.1) with ESMTP id n3DJEKpQ013206 for ; Mon, 13 Apr 2009 16:14:20 -0300 Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n3DJxBkX3776516 for ; Mon, 13 Apr 2009 16:59:11 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n3DIxrni027471 for ; Mon, 13 Apr 2009 15:59:53 -0300 Received: from [9.18.202.130] ([9.18.202.130]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n3DIxqMl027466 for ; Mon, 13 Apr 2009 15:59:53 -0300 Subject: [rfc][python] multi-process assumptions for Inferior API From: Thiago Jung Bauermann To: gdb ml Content-Type: text/plain Date: Tue, 14 Apr 2009 02:59:00 -0000 Message-Id: <1239649191.29619.189.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: 2009-04/txt/msg00102.txt.bz2 Hi, I'm working on a Python API for manipulating GDB inferiors. I'd like to submit it to gdb-patches by the end of the week, right now I'm half-way through. It will basically follow Tromey's suggestion here (I won't work on the events part for now, though): http://sourceware.org/ml/archer/2008-q4/msg00430.html In particular, I'm following Tromey's goals, such as: * It ought to keep working once gdb moves to multi-process. E.g., the current "gdb.threads" stuff is not super in this regard (IMO). So I'd appreciate some insight from the multi-process wizards. I'm working with the following assumptions: - There's only one selected frame, even with multiple threads and multiple inferiors. - There's such a thing as a selected thread, which is the thread containing the selected frame. Change the selected thread, and the selected frame necessarily changes too. - There's such a thing as a selected inferior, which is the inferior containing the selected thread. Change the selected inferior, and the selected thread and selected frame necessarily change too. Are they correct? -- []'s Thiago Jung Bauermann IBM Linux Technology Center