Re: [RFC - Python Scripting] New method gdb.Architecture.disassemble

[Matt Rice <ratmice@gmail.com>]

On 2/6/13, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Siva" == Siva Chandra <sivachandra@google.com> 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.