Method to retrieve a type's objfile, and an objfile's global scope

Method to retrieve a type's objfile, and an objfile's global scope

[Jim Blandy]

SpiderMonkey, like many interpreters for dynamically typed languages,
has an integral type 'jsval' that represents a tagged union of several
different kinds of values: small integers, booleans, pointers to
strings, and pointers to more structured objects.

The pretty-printer for jsval looks like this:

    def to_string(self):
        if JSVAL_IS_INT(self.val):
            return '$jsint(%d)' % (JSVAL_TO_INT(self.val))
        ...
        elif JSVAL_IS_OBJECT(self.val):
            return '$jsobject(%s)' % (JSVAL_TO_OBJECT(self.val))
        ...
        elif JSVAL_IS_STRING(self.val):
            return '$jsstring(%s)' % (JSVAL_TO_STRING(self.val))
        ...
        else:
            return '(jsval unrecognized by pretty-printer)'

Where:

def JSVAL_TO_OBJECT(v):  return jsval_to_ptr(v, JSObject_ptr_type())
def JSVAL_TO_STRING(v):  return jsval_to_ptr(v, JSString_ptr_type())
...
def JSObject_ptr_type():
    return gdb.lookup_type('JSObject').pointer()

What's kind of ugly here is that JSObject_ptr_type is looking up
JSObject in the current scope each time we call JSVAL_TO_OBJECT.
Aside from the multiple lookups, there's no necessary reason that we'd
find the definition of JSObject that matches that of the jsval we're
dealing with.  The value we happen to be pretty-printing need not come
from the current scope.

This kind of situation doesn't arise in pretty-printing code where
you're traversing a graph of properly-typed values: fetching a
structure's member gives you something of the appropriate type.  It
only arises when the language's types don't match the true types, as
in the case where the jsval, with the tag bits removed, is actually a
JSObject *.

One solution would be to provide access to a type's objfile, and then
to an objfile's global scope --- or perhaps more directly, simply
provide a function that returns the scope in which a type is defined.

Thoughts?

Re: Method to retrieve a type's objfile, and an objfile's global scope

[Tom Tromey]

>>>>> "Jim" == Jim Blandy <jimb@red-bean.com> writes:

Jim> One solution would be to provide access to a type's objfile, and then
Jim> to an objfile's global scope --- or perhaps more directly, simply
Jim> provide a function that returns the scope in which a type is defined.

Jim> Thoughts?

Yeah, I think we need something like this.

There are a few places where we should pass in some optional things to
modify type lookup: a block (or other sort of scope or scope proxy), an
arch, and a language.  Basically most occurrences of python_gdbarch and
python_language are bugs.  In this case, the ones in typy_lookup_typename.

I think archer already has some of the block stuff done.  I'm on another
branch right now, so it isn't convenient to check.


If you can't do this, please file a bug against archer.
I'd like us to be a bit more systematic about this; now is a good time
to start :-)

Tom