This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Extending gdb.Value

On Thu, Sep 30, 2010 at 10:29 AM, Joel Borggrén-Franck
<> wrote:
> On Wed, Sep 29, 2010 at 11:23 PM, Tom Tromey <> wrote:
>>>>>>> "Joel" == Joel Borggrén-Franck <> 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' ?:)


Was this the kind of use case you wanted?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]