Andrew Overholt writes:
I have natively-compiled all of Eclipse and created .db files and merged
them all into the system-wide .db. I have verified that the .db file that
is being used by gij (this is a gcc that I have built from 4.0 branch head)
contains the .jar,.jar.so combinations that I want to use. However, two of
the jars are being loaded as bytecode when I want them to be loaded from
their corresponding .so (as evidenced by the following).
eclipse -vmargs -verbose:
[...]
[Loaded (bytecode) org.eclipse.core.resources.ResourcesPlugin from
(file:/home/andrew/work/eclipse/binary/eclipse/plugins/org.eclipse.core.resources_3.1.0.jar
<no certificates>)]
[...]
I wrote a little test app (attached) to generate the byte strings from a
jar just like they are presented by gcj-dbtool -l (*) so that I could
verify that the actual classes I'm interested in are in fact in the .db.
This is what I get:
java MD5Test
/home/andrew/work/eclipse/binary/eclipse/plugins/org.eclipse.core.resources_3.1.0.jar
[...]
org/eclipse/core/resources/ResourcesPlugin.class -> 617779565aed3728932e63a591ad9d
[...]
and
gcj-dbtool -l `gcj-dbtool -p`
[...]
[21443] 617779565aed3728932e63a591ad9d ->
/home/andrew/work/eclipse/native-3.1reallyclean/org.eclipse.core.resources_3.1.0.jar.so
[...]
(I have verified that my test program run on another jar that loads classes
that are BC-compiled has matching signatures to those in the .db)
Interestingly enough, when I try the same jar but with some modifications
(I edited some classes in Eclipse, re-generated the jar, and
natively-compiled it in the same way I did the above), its classes *are*
loaded from the .so. This leads me to believe that something's either
wrong with this jar/.jar.so or with the part of gij that intercepts class
loading to feed stuff from .jar.sos in the .db. Any ideas?
I suspect that there is something wrong with the .so. Perhaps, for
example, it has some unresolved symdols. In that case we silently
fall back to the .jars.
It would be nice if verbose:class indicated that it had tried to load
a class from a .so and failed.
I guess Eclipse could be loading these two jars in unique ways.
The second jar is SWT which I know has JNI .sos ripped out the
first time it is used so maybe that is causing some weirdness
there?
Thanks,
Andrew
* it would be nice if gcj-dbtool could have this functionality but I guess
then it'll need to store the original classname ... perhaps I'll write a
patch
Something like gcj-dbtool -<?> foo.jar. Yes, that'd be nice.
Andrew.