Bytecode verifier

Mon Mar 29 19:21:00 GMT 2004

Ranjit Mathew writes:
 > > > It is a Good Thing, IMHO, but I'm just confused by
 > > > how you did it, especially after I remember us being
 > > > reticent to even use libiberty in libgcj and by the
 > > > order in which I see different parts of the GCC tree being
 > > > configured and built (libiberty, front-ends, libraries).
 > > 
 > > libiberty is GPL; libgcj is GPL+exception. There's no reason to to
 > > link GPL code with GPL+exception code.
 > 
 > If the front-end bits provide the API for the verifier
 > and libgcj uses it, it has to link to GPL-ed code, no?
That's a big "if".
 > If libgcj provides the API for the verifier and the
 > front-end uses it, the configury and the build process
 > should get really weird.
I don't see the problem. How we organize our configury is a disjoint
problem from the licence applied to a given file. Some of the files
in the gcc directory are GPL + exception. I can see no overwhelming
reason why an interface to a verifier should not be GPL + exception,
no matter where it is.
 > BTW, as has been pointed earlier, Sun's JVM doesn't
 > even bother verifying classes loaded locally unless
 > you use the "-verify" flag, so maybe even we ought
 > not to bother by default.
Interesting.
Andrew.