This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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


Tom Tromey wrote:
> I'm checking this in.

Thanks. I confirm that at least on my
machine all PR20056 tests (18 in all, including
interpreter tests) PASS.

Would it be good to check this in into the Mauve
verifier testsuite? (That testsuite seems quite
unmaintained right now - the last check-in was
around a year ago and there are a few files with
DOS-style CRLF endings. Many of the sanity checks
from the verifier portion of the JVMS are also
missing.)


> on my machine the interpreter tests don't run (possible dejagnu
> problem?  Last time I looked, nothing made sense).

Does libjava_find_gij (testsuite/libjava.exp) return ""?
Do you have INTERPRETER set to something other than "yes"
in the same script? (You wouldn't have given --disable-interpreter
on the configure command line, right?)


> I ran all the usual tests with this patch, plus rebuilt eclipse, plus
> rebuilt the failing jonas .jar with -findirect-dispatch, plus ran the
> PR 20056 test case (both original and the one in the test suite) by
> hand (through both gcj -findirect-dispatch and gij).

Man, are you paranoid or what! :-P
"Once bitten, twice shy" and all that...


> This patch also tests that we don't try to set a field on an
> uninitialized object other than our own 'this'.  You can't write java
> code to test this, but you could write invalid bytecode that tries
> this.
> 
> 
> We really need to set up VM-level testing.  Automated testing for the
> verifier (i.e., flesh out the mauve verify module and run it
> automatically from the libgj test suite) is also needed.  The current
> situation is unstable.

<thinking_aloud>

As Bryce pointed out, we need an assembler for Java integrated
with the GCJ toolchain that makes it easier to write such tests.

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

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

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

</thinking_aloud>

Ranjit.

-- 
Ranjit Mathew      Email: rmathew AT gmail DOT com

Bangalore, INDIA.    Web: http://ranjitmathew.hostingzero.com/


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