From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3374 invoked by alias); 9 Feb 2013 17:55:34 -0000 Received: (qmail 3354 invoked by uid 22791); 9 Feb 2013 17:55:33 -0000 X-SWARE-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-lb0-f175.google.com (HELO mail-lb0-f175.google.com) (209.85.217.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 09 Feb 2013 17:55:28 +0000 Received: by mail-lb0-f175.google.com with SMTP id n3so3699330lbo.20 for ; Sat, 09 Feb 2013 09:55:27 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.113.165 with SMTP id iz5mr8301613lab.50.1360432526941; Sat, 09 Feb 2013 09:55:26 -0800 (PST) Received: by 10.114.64.40 with HTTP; Sat, 9 Feb 2013 09:55:26 -0800 (PST) In-Reply-To: References: <20753.38272.55066.651097@ruffy2.mtv.corp.google.com> Date: Sat, 09 Feb 2013 17:55:00 -0000 Message-ID: Subject: Re: [RFC - Python Scripting] New method gdb.Architecture.disassemble From: Matt Rice To: Doug Evans Cc: Siva Chandra , gdb-patches Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00238.txt.bz2 On Fri, Feb 8, 2013 at 10:05 AM, Doug Evans wrote: > Let's take a step back and assume one wants to add disassembly to Python, > without knowing anything about what gdb does and doesn't already provide. Thanks for bringing this up, all very good points. > Global State In An API Is Bad. definitely agree, part of why i was wondering if the ui-out object shouldn't be passed in to the disassemble method was because it seemed more pure I suppose this leads me to consider that the "data-disassemble" command is (untested though) exposed already via the 'mi_execute' functions in the PR #11688 which already has generic conversion of arguments to and from mi commands. to transcribe an example (untested) from the mi docs [1] gdb.mi_execute("data-disassemble", ("-s", "$pc", "-e", "$pc+20", "--", 0)) This at least makes it rather apparent that we aren't working with a real python API and are using a python version of some gdb command interpreter (and all that entails). that at least gives us a stopgap that we can use while codifying a real API does disassemble method vs generic mi method make any difference? my main concern with the generic mi method is that it makes the coding of any real python API addressing your concerns somewhat less imminent [1] http://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI-Data-Manipulation.html#GDB_002fMI-Data-Manipulation