From: "Joel Borggrén-Franck" <joel.borggren.franck@gmail.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb@sourceware.org
Subject: Re: Extending gdb.Value
Date: Thu, 30 Sep 2010 08:29:00 -0000 [thread overview]
Message-ID: <AANLkTin4zpq96AprWZe5bHeN_WYr3Mr8EmSanqyNVm9M@mail.gmail.com> (raw)
In-Reply-To: <m37hi4i6ru.fsf@fleche.redhat.com>
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
next prev parent reply other threads:[~2010-09-30 8:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-24 7:29 Joel Borggrén-Franck
2010-09-29 15:18 ` Joel Borggrén-Franck
2010-09-29 21:23 ` Tom Tromey
2010-09-30 8:29 ` Joel Borggrén-Franck [this message]
2010-10-12 11:58 ` Joel Borggrén-Franck
2010-10-15 22:13 ` Tom Tromey
2010-10-19 19:20 ` Joel Borggrén-Franck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTin4zpq96AprWZe5bHeN_WYr3Mr8EmSanqyNVm9M@mail.gmail.com \
--to=joel.borggren.franck@gmail.com \
--cc=gdb@sourceware.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox