This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Questions about __cxa_throw and type_info
- From: Tom Tromey <tromey at redhat dot com>
- To: Brian Ellis <nullroute at yahoo dot com>
- Cc: Joe Buck <Joe dot Buck at synopsys dot COM>, llibstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: 07 Apr 2007 13:17:22 -0600
- Subject: Re: Questions about __cxa_throw and type_info
- References: <735324.69438.qm@web32103.mail.mud.yahoo.com>
- Reply-to: tromey at redhat dot com
>>>>> "Brian" == Brian Ellis <nullroute@yahoo.com> writes:
Brian> I already have a proof of concept that is able to forge a
Brian> virtual table and instance an object. The virtual methods that
Brian> are overridden by the new forged virtual table enter a thunk
Brian> which invokes the interpreter passing the this pointer and
Brian> virtual function id as parameters.
We do a lot of this same stuff in libgcj -- we make new classes at
runtime; make calls between interpreted and compiled code; can have
interpreted methods in a new class override methods in its superclass;
etc.
Unfortunately for you our approach is much simpler than handling all
of C++ -- we only handle Java, which has single inheritance (it is
more complicated really, but our C++ code doesn't know that), and we
only handle the subset of exceptions that Java can use. Also we rely
on gcj to emit a lot of metadata describing class and vtable layout.
Doing this for C++ would be a nice library project IMO, say as an
adjunct to libffi. One nice thing about having a standard C++ ABI is
having higher-level tools to manipulate it.. :-)
Brian> The only major concept that I do not yet have a proof-positive
Brian> for is exception throwing and catching. I'd like for the
Brian> interpreter to be able to catch arbitrary objects thrown to it
Brian> from any c++ function that it has invoked as well as throw
Brian> objects that it has created.
In libgcj we only catch the subset of exceptions that are "java-like".
I looked at this problem a little bit years and years ago but we
punted on it ... we didn't need the full generality and it looked
super hard.
Tom