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

[Siva Chandra <sivachandra at google dot com>]

On Wed, Feb 6, 2013 at 2:31 PM, Matt Rice <ratmice@gmail.com> wrote:
> 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.

Firstly, thanks a lot to everyone for the feedback.  Due to my limited
knowledge of GDB and its internals, my patch implements a Python
ui_out which I reversed engineered based on how gdb_disassembly works
and what I could understand from ui-out.c.  I was hoping to get this
this kind of feedback, and I have now got it :)

Based on what Matt says in his comments, it seems like a leaf row can
look like one of these 3 possibilities:

1. [1, 2, 3]
2. ['a' : 1, 'b': 2, 'c': 3]
3. ['a': 1, 'a': 2, 'a': 3]

1 and 2 can be encapsulated with fundamental Python data structures. I
am not aware of any fundamental Python data structure which can
capture 3. So, is using a helper class called LabelValuePair a good
idea? With this, all leaf rows can be lists whose elements are either
all values, or are all LabelValuePairs: [value, value, value] or
[LabelValuePair, LabelValuePair, LabelValuePair]. Does this sound
reasonable? We can always go in for a list of single element dicts,
but I think that kind of makes it ugly. LabelValuePair can look like
this (in its Python form):

class LabelValuePair(object):
  def __init__(self, label, value):
    self.label = label # not a writable attribute
    self.value = value # not a writable attribute

About table headers; are they relevant when ui_out is not for display?
That is, is it necessary to provision for them in the Python ui_out
object?

Thanks,
Siva Chandra