This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] expose gdb values to python
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