Re: Reconsidering gcjx

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:

Andrew> In particular, the type system and the rules for exception
Andrew> regions are different.  Also, a "slot" in the .class format
Andrew> doesn't necessarily correspond to a variable in the source
Andrew> language.

One way to look at this is: we really want to fix these things,
because, e.g., we'll probably be compiling all the java code in FC to
objects from class files for the foreseeable future anyway (to avoid
huge divergences from upstream build setups).

Moving to gcjx would turn "writing a 1.5 compiler" from a project
taking all of my time for the next year into a project that takes all
of my time for 2 months.  Then we'd have more time to fix other
things.

Andrew> In particular,
Andrew> .class files don't contain the full pathnames to source files.

I think this one we can handle via the specs.

Consider a simple compilation like "gcj -g -c foo.java".
In my proposal we would turn this into a series of invocations:

    ecj -g -Xjar /tmp/tmpfile.jar foo.java
    jc1 blah blah blah -o /tmp/tmpfile2.o tmpfile.jar

... but we could easily have the specs pass the real original file
name to jc1.

Just as a side note for non-java experts ... the reason we use an
intermediate jar file is that a single java compilation may result in
multiple .class files.  A jar file is convenient because it is simple
to make in java, and because gcj already has all the code needed to
read and compile one.

It occurs to me now that we'll probably need a way to make ecj not
compile eagerly.  I haven't looked to see whether it already has one.

Column numbers, as Per mentioned, are trickier.  We know that ecj has
this information (since Eclipse itself uses it), but there is no
standard way to pass it via the class file format.  But does gdb
actually use column numbers?

Tom