Native code not loaded when it is in the db

[Andrew Overholt]

Hi Andrew,

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 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

[Andrew Haley]

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.

[Tom Tromey]

> > > > > "Andrew" == Andrew Haley  writes:

Andrew> It would be nice if verbose:class indicated that it had tried to load
Andrew> a class from a .so and failed.

At the point where this is printed, it would be really hard to
determine this.

I was thinking of adding something like '-Xverbose:libraries' to print
all .so activity, including error messages on failed loads.  That
would be useful in a number of situations.  I'll file a PR for this.

Tom

[Andrew Haley]

Tom Tromey writes:
> > > > > > "Andrew" == Andrew Haley  writes:
>
> Andrew> It would be nice if verbose:class indicated that it had tried to load
> Andrew> a class from a .so and failed.
>
> At the point where this is printed, it would be really hard to
> determine this.

Well, we always throw if we fail to load a .so.  So all we have to do
when -verbose: is turned on is print (" failed + " the Throwable)

Andrew.

[Tom Tromey]

> > > > > "Andrew" == Andrew Haley  writes:

Andrew> Well, we always throw if we fail to load a .so.  So all we have to do
Andrew> when -verbose: is turned on is print (" failed + " the Throwable)

Yeah, for the .db path.  We don't throw on failure in natRuntime.cc.

Tom

[Robin Green]

On Fri, 07 Oct 2005 09:40:50 -0400, Andrew Overholt wrote:
> 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).

Is this bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163969 ? This was
"fixed" ages ago - except it wasn't actually fixed for a long while,
because rawhide eclipse was not updated for about 2 months.