Re: [rfc] expose gdb values to python

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

El lun, 29-09-2008 a las 12:59 -0400, Daniel Jacobowitz escribió: 
> On Mon, Sep 29, 2008 at 01:15:05PM -0300, Thiago Jung Bauermann wrote:
> > +/* Python's float type corresponds to native C's double type (which is
> > +   assumed to use IEEE double format).  */
> > +#define builtin_type_pyfloat builtin_type_ieee_double
> > +
> > +/* Python's long type corresponds to native C's long long type (which is
> > +   assumed to be int64_t).  */
> > +#define builtin_type_pylong builtin_type_int64
> > +
> > +/* The current language may not have a boolean type, so always use an
> > +   integer as boolean type.  Hopefully any language can deal with integers
> > +   as boolean values.  */
> > +#define builtin_type_pybool builtin_type_int32
> 
> Can't you get an architecture to use when you need these?  I'm scared
> the double change, in particular, will break any non-ieee target.
> This is supposed to be target arithmetic, we should use the target
> formats.

I did it this way having in mind the case when a value needs to be
created at a moment when no file is loaded (and thus an
architecture/target is not yet determined). This is the same problem
faced by the expression evaluator, when the user types (say):

(gdb) print 1.2

Right after starting GDB, before any file has been loaded. It uses
current_gdbarch for now.

I had a look again at the places where builtin_type_* are used, and I
found out in several cases that we can find a gdbarch when needed, but
sometimes I can't see how to do that, and then we'd have to resort to
something like the above.

Some of the uses of builtin_type_* are in convert_value_from_python, it
has two callers: the gdb.Value constructor and gdb.Function, which
registers a Python function that can be called from the GDB expression
evaluator. The constructor can be removed as the user won't need to
create new gdb.Value objects himself. I kept it because it was very
convenient for the testsuite. I'll rewrite it to use the
get_value_from_history trick. For gdb.Function, I think it's possible to
get gdbarch from the expression where it appears. I'll have to dig more
into this, but since that code is not in this patch, I can just remove
convert_value_from_python for now, and resubmit it later.

The other uses of builtin_type_* are in valpy_binop and
valpy_richcompare. They have a struct value handy, which is the second
argument to the binary operation. From its type->main_type->objfile I
can get a gdbarch. Sometimes a type will not have an objfile though (if
it is a builtin_type itself), and in those cases I'd have to resort to
some generic builtin_type. I thought this could happen if a gdb.Function
was called before an architecture is determined, but now that I wrote
all this, I believe since it would get its gdbarch from the expression,
I guess we can just punt if value->type->main_type->objfile is NULL.

Or should I expect types which are not associated with any objfile?

-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center