This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] expose gdb values to python
- From: Tom Tromey <tromey at redhat dot com>
- To: Thiago Jung Bauermann <bauerman at br dot ibm dot com>
- Cc: gdb-patches ml <gdb-patches at sourceware dot org>
- Date: Fri, 19 Sep 2008 16:39:12 -0600
- Subject: Re: [rfc] expose gdb values to python
- References: <1221199426.24580.26.camel@localhost.localdomain>
- Reply-to: tromey at redhat dot com
>>>>> "Thiago" == Thiago Jung Bauermann <bauerman@br.ibm.com> writes:
Thiago> This is the patch exposing struct value to Python.
Thank you so much, not just for this patch, but for all your work
separating the mess into patches.
Thiago> I believe it's better to avoid using current_language, right?
Thiago> I don't think there's a way to get a sensible language_defn to
Thiago> use here, so my only idea is to add an element to struct value
Thiago> which holds the language associated with the value. This
Thiago> element would be filled at the moment the value is created.
My first reaction to this was "no way". But, I couldn't think of a
concrete case where this would have bad results -- especially provided
we restrict use of the language field to stringifying the value.
Thiago> The other FIXME is for the bogus implementation of
Thiago> valpy_length, which is supposed to return the number of
Thiago> elements in the gdb.Value fake dictionary. I had a quick look
Thiago> at how I'd enumerate all elements in a struct/class to find a
Thiago> sensible answer, but I got scared by the code in
Thiago> value_struct_elt and friends.
I think there are a few ways to approach this.
The underlying question is what type model Value presents. If a Value
has a derived type, should we be able to access fields of the base
class using v["f"]? Or should we need v["Base"]["f"]?
There are some tradeoffs here. The "invisible access" approach is
convenient. However, it runs into issues with odd programs -- say,
multiple inheritance where a given name refers to multiple fields.
The "raw" approach doesn't have this problem (and here, valpy_length
is easy to write), but it is more cumbersome to use.
There are some intermediate ideas, too, like allowing the invisible
approach only when the field name is unique; or we could define the
search order. (It is tempting to use the language's rules, but I
suspect this might be too tricky to get right.)
I tend to like something toward the raw side, partly because any
cooked approach will still need some second way to deal with the
underlying explicit types.
I propose we decide these questions and implement this before checking
in this patch. The semantics of Value are critical.
Tom