This is the mail archive of the
mailing list for the Archer project.
Method to retrieve a type's objfile, and an objfile's global scope
- From: Jim Blandy <jimb at red-bean dot com>
- To: Project Archer <archer at sourceware dot org>
- Date: Fri, 24 Jul 2009 09:54:30 -0700
- Subject: Method to retrieve a type's objfile, and an objfile's global scope
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:
return '$jsint(%d)' % (JSVAL_TO_INT(self.val))
return '$jsobject(%s)' % (JSVAL_TO_OBJECT(self.val))
return '$jsstring(%s)' % (JSVAL_TO_STRING(self.val))
return '(jsval unrecognized by pretty-printer)'
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())
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
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.