From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29681 invoked by alias); 6 Feb 2013 22:31:25 -0000 Received: (qmail 29660 invoked by uid 22791); 6 Feb 2013 22:31:24 -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-la0-f51.google.com (HELO mail-la0-f51.google.com) (209.85.215.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Feb 2013 22:31:18 +0000 Received: by mail-la0-f51.google.com with SMTP id fo13so1914890lab.24 for ; Wed, 06 Feb 2013 14:31:17 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.38.66 with SMTP id e2mr11707906lbk.90.1360189876742; Wed, 06 Feb 2013 14:31:16 -0800 (PST) Received: by 10.114.64.40 with HTTP; Wed, 6 Feb 2013 14:31:16 -0800 (PST) In-Reply-To: <87y5f1w6xc.fsf@fleche.redhat.com> References: <87y5f1w6xc.fsf@fleche.redhat.com> Date: Wed, 06 Feb 2013 22:31:00 -0000 Message-ID: Subject: Re: [RFC - Python Scripting] New method gdb.Architecture.disassemble From: Matt Rice To: Tom Tromey Cc: Siva Chandra , gdb-patches@sourceware.org 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/msg00170.txt.bz2 On 2/6/13, Tom Tromey wrote: >>>>>> "Siva" == Siva Chandra writes: > Siva> +/* This data structure captures the Python version of ui_out. The > Python > Siva> + version is not used to display output to a user, but to capture > the results > Siva> + from GDB's internals in to a Python data structure. Hence, it > does not have > Siva> + any representation for table headers. However, it can be viewed > as a > Siva> + recursive table structure wherin the highest level is a list of > rows. All > Siva> + rows in this list can either be a list themselves, or all of them > can be > Siva> + dicts holding the table's fields. If they were lists, then they > follow the > Siva> + same recurrsive structure as the higher levels. > > Typo, "recursive". > > I like this -- I've wanted it before -- but I wonder whether it handles > all cases. See http://sourceware.org/bugzilla/show_bug.cgi?id=11688#c6 these may help, not sure i'll try to be a little bit more pointed in identifying the sources of the problems disregarding the details of that specific patches attempt to paper around them: http://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI-Output-Syntax.html#GDB_002fMI-Output-Syntax value ==> const | tuple | list result ==> variable "=" value list ==> "[]" | "[" value ( "," value )* "]" | "[" result ( "," result )* "]" Notes: New gdb/mi commands should only output lists containing values. --- so, list can look like: [1, 2, 3] or ["a" = 1, "b" = 2, "c" = 3] both are created with a ui_out_type_list thus we don't know if to create a python dict or list, until something is added, and the existence of a fldname then a 2nd issue entirely separate is that: ["a" = 1, "a" = 2, "a" = 3] is also valid and seen in practice so sanely working around those issues is where the thoughts on adding new uiout types comes from. +static void +py_out_field_string (struct ui_out * ui_out, int fldno, int width, + enum ui_align align, const char *fldname, const char *str) +{ + struct py_out_data *py_out_data = ui_out_data (ui_out); + + CHECK_AND_INIT_FIELD_ROW_DATA (py_out_data->current_row->data); + + PyDict_SetItemString (py_out_data->current_row->data, fldname, + PyString_FromString (str)); +} need to test that 'fldname' isn't null, this should happen for the [value, value] type of list. PyDict_SetItemString: the key object is created using PyString_FromString(key) PyString_FromString: The parameter v must not be NULL my main concern is to do our best to make the datastructure returned compatible with some future implementation of py-out which can handle everything uiout throws at it. then ask when uiout throws some new found nonsensical junk at us how do we handle it? not to dissuade from using an incomplete solution. I suppose i'd be happy if the user had to create a py-uiout object (passing in a version to the creation function), then passed that to the dissasemble() function, but I dunno if the user really would.