This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch: FYI: one more stab at PR 20056


>>>>> "Ranjit" == Ranjit Mathew <rmathew@gmail.com> writes:

Ranjit> Would it be good to check this in into the Mauve
Ranjit> verifier testsuite? (That testsuite seems quite
Ranjit> unmaintained right now

Yes, it would be.  I put this on my to-do list.

BTW, I think a couple of tests in that test suite are "wrong".
Sadly, verification is a bit poorly defined... the description in the
JVMS can't be used to write a working verifier.  And, what Sun's
accepts changes over time ... and finally, as the Coglio papers point
out, there are restrictions in the JVMS that don't actually affect
type safety.  It's an ugly situation.

Ranjit> Does libjava_find_gij (testsuite/libjava.exp) return ""?

As I recall, get_multilibs returns the wrong value here.
Perhaps I have a broken dejagnu.

Ranjit> It would perhaps have to be compatible with Jasmin's syntax
Ranjit> and command-line options to enable it to be a drop-in replacement
Ranjit> for Jasmin within Mauve's verifier testsuite and maybe elsewhere.

Yeah, or we could just rewrite those tests.

Ranjit> A YACC/Lex-based assembler using the existing GCJ "jcf library"
Ranjit> doesn't seem too difficult. Perhaps a custom lexer and a
Ranjit> recursive-descent parser might be preferable for compactness,
Ranjit> portability, maintainability, etc. (<digression>Why do
Ranjit> people write custom lexers? Wouldn't a lex-compiled DFA be
Ranjit> faster for tokenising?</digression>)

We always had a hand-written one for gcj, I don't know why.  I've
assumed it was because lex couldn't understand matching non-ascii
characters, as required by java identifiers.  But, I never actually
looked into this.

Ranjit> Would such an addition ("GNU Assembler for Java" or "gaj") be
Ranjit> welcome?

Yes, definitely.

I would prefer to see this done as part of the classpath tools
project.  You ("one") could write it in java and use gnu.bytecode or
ASM for the bytecode tweaking.

It would be most convenient if jcf-dump (or the cp-tools javap... on
the gcjx branch I've removed jcf and jcf-dump) could dump a class in a
way that could be immediately read in by the assembler.  That would
make it much easier to write verifier tests, by starting with java
source and then modifying the result.  Like jasmin, it has to be
possible to generate invalid bytecode with the assembler.  (It would
be possible to hack gcjx to emit assembler output as well, directly
from java source, but that is probably overkill...)


I've also considered just checking in the bytecode form of the various
jasmin source files.  That is ugly but would let us do testing more
easily.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]