Extending gdb.Value

Extending gdb.Value

[Joel Borggrén-Franck]

So I noticed today that I cant extend gdb.Value:

(gdb) python class foo(gdb.Value): pass
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: Error when calling the metaclass bases
    type 'gdb.Value' is not an acceptable base type
Error while executing Python code.
(gdb)

So a couple of questions regarding this:

1) Is this intended?
2) If so, why?

I have just started writhing magic proxies around gdb.Value, which is quite
doable in Python, but I realized it might be easier to just 'fix' the basic
problem if there is no explicit reason to disallow using gdb.Value as a
base.

Cheers
Joel Borggrén-Franck

Re: Extending gdb.Value

[Joel Borggrén-Franck]

On Fri, Sep 24, 2010 at 9:28 AM, Joel Borggrén-Franck
<joel.borggren.franck@gmail.com> wrote:
> So I noticed today that I cant extend gdb.Value:
>

The fix for this is trivial:

--- gdb-7.2-orig/gdb/python/py-value.c	2010-06-28 23:16:03.000000000 +0200
+++ gdb-7.2/gdb/python/py-value.c	2010-09-29 13:33:00.000000000 +0200
@@ -1156,7 +1156,7 @@
   0,				  /*tp_getattro*/
   0,				  /*tp_setattro*/
   0,				  /*tp_as_buffer*/
-  Py_TPFLAGS_DEFAULT | Py_TPFLAGS_CHECKTYPES,	/*tp_flags*/
+  Py_TPFLAGS_DEFAULT | Py_TPFLAGS_CHECKTYPES | Py_TPFLAGS_BASETYPE,
/*tp_flags*/
   "GDB value object",		  /* tp_doc */
   0,				  /* tp_traverse */
   0,				  /* tp_clear */

I'm convinced this is a good idea. I got lots of stuff I would like to
add on top of gdb.Value that only makes sense in the context of
specific applications.

So how can I test that this doesn't break anything? And which other
python types are suitable for being bases. Why not add all of them?

Cheers
/Joel

Re: Extending gdb.Value

[Tom Tromey]

>>>>> "Joel" == Joel Borggrén-Franck <joel.borggren.franck@gmail.com> writes:

Joel> So I noticed today that I cant extend gdb.Value:

Joel> The fix for this is trivial:
[...]

Joel> I'm convinced this is a good idea. I got lots of stuff I would like to
Joel> add on top of gdb.Value that only makes sense in the context of
Joel> specific applications.

Joel> So how can I test that this doesn't break anything? And which other
Joel> python types are suitable for being bases. Why not add all of them?

I think the reason things are the way they are is due to a mix of
ignorance and conservatism.  That is, we probably didn't think about it
early on (I know I didn't), and also we've generally tried to reduce our
exposure to "weird stuff" in case we need to make changes.

Could you elaborate on the uses to which you intend to put this?
That would be helpful.

The only thing I could think of that might be a problem here is
converting the Python subclass to a real `struct value' again.  See
convert_value_from_python, in particular:

      else if (PyObject_TypeCheck (obj, &value_object_type))
	value = value_copy (((value_object *) obj)->value);

Tom

Re: Extending gdb.Value

[Joel Borggrén-Franck]

On Wed, Sep 29, 2010 at 11:23 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Joel" == Joel Borggrén-Franck <joel.borggren.franck@gmail.com> writes:
>
> Joel> So I noticed today that I cant extend gdb.Value:
>
> Joel> The fix for this is trivial:
> [...]
>
> Joel> I'm convinced this is a good idea. I got lots of stuff I would like to
> Joel> add on top of gdb.Value that only makes sense in the context of
> Joel> specific applications.
>
> Joel> So how can I test that this doesn't break anything? And which other
> Joel> python types are suitable for being bases. Why not add all of them?
>
> I think the reason things are the way they are is due to a mix of
> ignorance and conservatism.  That is, we probably didn't think about it
> early on (I know I didn't), and also we've generally tried to reduce our
> exposure to "weird stuff" in case we need to make changes.
>
> Could you elaborate on the uses to which you intend to put this?
> That would be helpful.
>

The first use case is while debugging a virtual machine for a class-based
language. There are a lot of data on the heap of the target language that
to gdb looks like:

struct heapObj {
  int flags;
  clazz *cls;
  u8 first_byte_of_fields[1];
}

concatenated with a chunk of fields that only make sense with help from
data stored in cls. For example, the length of this object can't be
determined without looking it up through cls.

I would like to abstract over this by creating a subclass of gdb.Value that
overrides __getitem__ to do the lookup in the vm's datastructures so that
the heap-objects behaves just the same as regular gdb.Values. IE
my_heap_obj['foo'] should lookup the offset of 'foo' through cls, and return
a new HeapObject that represents the field 'foo'.

Further, this VM doesn't follow the same stack layout conventions as gcc,
so I can easily see the need to extend gdb.Frame to build a bt and frame
iterator that works. But I'll get back to that later.

Also, why not? Closed/final classes should IMO be avoided in favor of
saying 'hey you can do this, but I wont clean up the mess you create'  :)

Cheers
/Joel

Re: Extending gdb.Value

[Joel Borggrén-Franck]

On Thu, Sep 30, 2010 at 10:29 AM, Joel Borggrén-Franck
<joel.borggren.franck@gmail.com> wrote:
> On Wed, Sep 29, 2010 at 11:23 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>>> "Joel" == Joel Borggrén-Franck <joel.borggren.franck@gmail.com> writes:
>>
>> Joel> So I noticed today that I cant extend gdb.Value:
>>
>> Joel> The fix for this is trivial:
>> [...]
>>
>> Joel> I'm convinced this is a good idea. I got lots of stuff I would like to
>> Joel> add on top of gdb.Value that only makes sense in the context of
>> Joel> specific applications.
>>
>> Joel> So how can I test that this doesn't break anything? And which other
>> Joel> python types are suitable for being bases. Why not add all of them?
>>
>> I think the reason things are the way they are is due to a mix of
>> ignorance and conservatism.  That is, we probably didn't think about it
>> early on (I know I didn't), and also we've generally tried to reduce our
>> exposure to "weird stuff" in case we need to make changes.
>>
>> Could you elaborate on the uses to which you intend to put this?
>> That would be helpful.
>>
>
> The first use case is while debugging a virtual machine for a class-based
> language. There are a lot of data on the heap of the target language that
> to gdb looks like:
>
> struct heapObj {
>  int flags;
>  clazz *cls;
>  u8 first_byte_of_fields[1];
> }
>
> concatenated with a chunk of fields that only make sense with help from
> data stored in cls. For example, the length of this object can't be
> determined without looking it up through cls.
>
> I would like to abstract over this by creating a subclass of gdb.Value that
> overrides __getitem__ to do the lookup in the vm's datastructures so that
> the heap-objects behaves just the same as regular gdb.Values. IE
> my_heap_obj['foo'] should lookup the offset of 'foo' through cls, and return
> a new HeapObject that represents the field 'foo'.
>
> Further, this VM doesn't follow the same stack layout conventions as gcc,
> so I can easily see the need to extend gdb.Frame to build a bt and frame
> iterator that works. But I'll get back to that later.
>
> Also, why not? Closed/final classes should IMO be avoided in favor of
> saying 'hey you can do this, but I wont clean up the mess you create'  :)
>

Tom,

Was this the kind of use case you wanted?

Cheers
/Joel

Re: Extending gdb.Value

[Tom Tromey]

>>>>> "Joel" == Joel Borggrén-Franck <joel.borggren.franck@gmail.com> writes:

Sorry about the long delay on this.

Joel> Was this the kind of use case you wanted?

Yes, thanks.  I can't see any reason to avoid this change.  I will make
it next week.

Tom

Re: Extending gdb.Value

[Joel Borggrén-Franck]

On Sat, Oct 16, 2010 at 12:13 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Joel" == Joel Borggrén-Franck <joel.borggren.franck@gmail.com> writes:
>
> Sorry about the long delay on this.
>

No worries. Thank you for taking your time to fix this.

Cheers
Joel