This is the mail archive of the
mailing list for the GCC project.
Putting C++ code into gcc front end
- From: Tom Tromey <tromey at redhat dot com>
- To: GCC Hackers <gcc at gcc dot gnu dot org>
- Date: 03 Mar 2003 18:42:11 -0700
- Subject: Putting C++ code into gcc front end
- Reply-to: tromey at redhat dot com
Recently I've some bugs in the gcj bytecode verifier. Historically
the gcj verifier hasn't had many bug reports against it, but the newer
Java compilers out there (specifically, the current jikes and the
current Eclipse java compiler -- both free) generate code that it
Based on reading the gcj code (and my experience writing the runtime
verifier), I think it would be easier, and cheaper in the long run, to
re-use the libgcj bytecode verifier instead of trying to fix the bugs
in the gcj one.
It would be easier because the gcj verifier's approach to subroutines
doesn't reflect the latest interpretations of the JVM spec. Changing
this means redoing the most complicated part of the verifier. This
part of the libgcj verifier is already well-debugged.
It would be cheaper to do this in the long run because it would mean
we'd only have to fix verifier bugs in one place. This would also
make it easier to keep up with changes that are made to the spec (this
does happen from time to time).
However, the libgcj verifier is written in C++. So, if I were to do
this, it would mean adding some C++ code to the gcj front end.
I'm sure this is a controversial idea, so I wanted to float it before
doing any of the work.
This code uses 3 C++ features of note: classes, destructors, and
exceptions. Rewriting it in C would be unpleasant (I think I'd prefer
to try to fix the gcj verifier). However, it does mean that it is
likely to be buildable with just about any version of g++ that is
still out there.
In case it matters, the C++ code in question is in gcc/libjava/verify.cc.
Before putting this into the front end it would require some surgery
in order to separate it from some things that are available only in
libgcj. I'd also have to fix one (the only known) libgcj verifier bug
first (but I have to do this anyway).