java.lang.IllegalStateException: unresolved phantom target

[rapodaca]

Now that the problem of how to cross-compile c++ with g++ seems to be
solved:

http://groups.google.com/group/nestedvm/t/7373accf6010d6d7

I've hit another problem:

java org.ibex.nestedvm.Compiler -outfile Babel.class Babel babel
Exception in thread "main" java.lang.IllegalStateException: unresolved
phantom target
at org.ibex.classgen.MethodGen.resolveTarget(MethodGen.java:
555)
at org.ibex.classgen.MethodGen._generateCode(MethodGen.java:
664)
at org.ibex.classgen.MethodGen.generateCode(MethodGen.java:
618)
at org.ibex.classgen.MethodGen.dump(MethodGen.java:888)
at org.ibex.classgen.ClassFile._dump(ClassFile.java:193)
at org.ibex.classgen.ClassFile.dump(ClassFile.java:160)
at
org.ibex.nestedvm.ClassFileCompiler.__go(ClassFileCompiler.java:380)
at
org.ibex.nestedvm.ClassFileCompiler._go(ClassFileCompiler.java:72)
at org.ibex.nestedvm.Compiler.go(Compiler.java:259)
at org.ibex.nestedvm.Compiler.main(Compiler.java:183)

For some background, the project I'd like to run on nestedvm is "Open
Babel" v 2.1.1:

http://sourceforge.net/project/showfiles.php?group_id=40728&package_id=32894&release_id=521581

After successfully cross-compiling to MIPS (apparently) and getting
several binaries in the "tools" directory - one of which was "babel",
I used the command above and got the exception.

My environment had been set up prior to this by using "make env.sh"
and "source env.sh".

Any ideas?

Thanks,
Rich

[Brian Alliet]

On Sun, Nov 18, 2007 at 08:14:36AM -0800, rapodaca wrote:
> java org.ibex.nestedvm.Compiler -outfile Babel.class Babel babel
> Exception in thread "main" java.lang.IllegalStateException: unresolved
> phantom target

Definitey a bug in NestedVM. Could you post the binary ("babel") you're
trying to compile? I'll look into it.

As a work around you might try to compile via java source code:

java org.ibex.nestedvm.Compiler -outformat java -outfile Babel.java Babel babel

since the bug appears to be in the bytecode compiler. Another possible
workaround would be to turn off optimization when compiling with gcc.
This might avoid generating whatever instruction sequence is triggering
the bug.

-Brian

[rapodaca]

On Nov 18, 5:40 pm, Brian Alliet <br...@brianweb.net> wrote:
> On Sun, Nov 18, 2007 at 08:14:36AM -0800, rapodaca wrote:
> > java org.ibex.nestedvm.Compiler -outfile Babel.class Babel babel
> > Exception in thread "main" java.lang.IllegalStateException: unresolved
> > phantom target
>
> Definitey a bug in NestedVM. Could you post the binary ("babel") you're
> trying to compile? I'll look into it.

Hello Brian,

Interesting. I could post the MIPS binary I've built, but I think
there may be a complicating factor. It seems as if the babel binary
loads some other modules dynamically. Could it be possible that the
bytecode compiler can't resolve the dependency? Would building all
modules into the same binary help?

I've written up my experience so far with detailed instructions to
repeat the error here:

http://depth-first.com/articles/2007/11/19/compiling-open-babel-to-pure-java-bytecode-with-nestedvm-an-unsuccessful-first-attempt

If you like, I can still forward what I've built.

> As a work around you might try to compile via java source code:
>
> java org.ibex.nestedvm.Compiler -outformat java -outfile Babel.java Babel babel

I'll try that.

> since the bug appears to be in the bytecode compiler. Another possible
> workaround would be to turn off optimization when compiling with gcc.
> This might avoid generating whatever instruction sequence is triggering
> the bug.

I'll try that, too. Thanks.

Rich

[Brian Alliet]

On Mon, Nov 19, 2007 at 09:02:04AM -0800, rapodaca wrote:
> I've written up my experience so far with detailed instructions to
> repeat the error here:
> http://depth-first.com/articles/2007/11/19/compiling-open-babel-to-pure-java-bytecode-with-nestedvm-an-unsuccessful-first-attempt

Thanks for the detail instructions. I was able to reproduce the
problem.

It was actually kind of interesting to track down. Simplifying things
significantly (ignoring delay slots, etc), basically the last
instruction in the entire program was the instruction to call a
function (JAL). Control returns to the instruction following the JAL
after the method returns, but since this was the last instruction,
there is nowhere to return too. If this function were to actually
return a real machine would segfault.

This is buried in some exception handling code (which I don't
understand at all). It might be perfectly safe (maybe the function
never returns) or it might be an indication of a bug in the original
program or gcc. Either way, NestedVM will now handle it at runtime the
same way a real machine would, by crashing.

This patch fixes the bug (do a darcs pull, then make):

Tue Nov 20 14:51:29 EST 2007 br...@brianweb.net
* fix boundary case where last instructin in .text does a link

> > As a work around you might try to compile via java source code:

This actually would've worked too. The java source code compiler
doesn't have the same bug. In general, you don't want to use the java
source compiler though, it is slower and is bitrotting.

-Brian

[rapodaca]

On Nov 20, 12:13 pm, Brian Alliet <br...@brianweb.net> wrote:
> It was actually kind of interesting to track down. Simplifying things
> significantly (ignoring delay slots, etc), basically the last
> instruction in the entire program was the instruction to call a
> function (JAL). Control returns to the instruction following the JAL
> after the method returns, but since this was the last instruction,
> there is nowhere to return too. If this function were to actually
> return a real machine would segfault.

Great that you found the problem. Was it in the Open Babel code,
NestedVM, or somewhere else?

> This is buried in some exception handling code (which I don't
> understand at all). It might be perfectly safe (maybe the function
> never returns) or it might be an indication of a bug in the original
> program or gcc. Either way, NestedVM will now handle it at runtime the
> same way a real machine would, by crashing.
>
> This patch fixes the bug (do a darcs pull, then make):
>
> Tue Nov 20 14:51:29 EST 2007 br...@brianweb.net
> * fix boundary case where last instructin in .text does a link

I'm not too familiar with darcs, so I deleted my old installation, and
did a fresh "darcs get", followed by the same compile procedure as
before. Unfortunately, I hit the same exception as I did before when
trying to convert the "babel" binary to a classfile. I must have done
something wrong, but I'm not sure what.

> > > As a work around you might try to compile via java source code:
>
> This actually would've worked too. The java source code compiler
> doesn't have the same bug. In general, you don't want to use the java
> source compiler though, it is slower and is bitrotting.

I tried it and it did work (was surprisingly fast, too). I compiled
the "babel" binary to Java source, then compiled with javac (had to up
the memory allowance with -J-Xms256m -J-Xmx256m). How is the class
file generated by going through java source different from the one
built directly from the MIPS binary?

Anyway, I then got a Java class file that could be run with "java".

But there's still a problem (on my end) in that the "babel" binary is
configured to dynamically load a whole bunch of separate modules, none
of which seem to have been compiled into the MIPS binary statically.
So the program fails, for example, when you try to do something it
should understand like "babel -Hsmi".

I'm not really a C/C++ guy, but this seems like it should be an easy
problem to fix. Any ideas?

Thanks again for looking into this,
Rich