Re: [rfc] expose gdb values to python

[Thiago Jung Bauermann <bauerman@br.ibm.com>]

Daniel Jacobowitz wrote:
> On Fri, Sep 19, 2008 at 04:39:12PM -0600, Tom Tromey wrote:
>> 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".

Well, thanks for the sincerity I suppose. :-)

>> 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.
> 
> This seems iffy.  A value's just a value - how it's printed depends on
> how it's used, not how it was created.  e.g. if two languages had
> different number formatting, "print $1" should generate different
> results based on the current language.
> 
> So what the right language is may depend on the context.

My reasoning was that if a value comes from a C context (for example),
at least at first I'd expect it to always be printed in C syntax. But
I see your point. And I have no preference, really.

So leaving current_language in valpy_str is acceptable? Then one FIXME
can be just dropped.

>> 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.)
> 
> Why isn't this the same as for expression evaluation in GDB today?
> That does follow the language rules (and fail, in some cases).

From what I understood of the expression evaluator, this means just
calling value_struct_elt to find the element. If that's the case, it's what
this patch implements.

Is it useful to provide a casting mechanism, to enable for instance access
to elements from a specific type in the inheritance hierarchy?

With that, a python script will have the same capability as the user at the
GDB prompt to access any struct/class element, right?

But I'd leave type casting to the (still to be written) patch exposing the
type system to python.

> I'm not sure we really need length to work, but I haven't spent much
> time looking at it.  If we don't, I'd rather it failed always than
> intermittently.

A function which always fails? I can write that. :-)
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center