--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
|
--- Comment #1 from thebohemian at gmx dot net 2005-11-01 19:32 ---
Created an attachment (id=10103)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10103&action=view)
A test for the linking mechanism
This is a slightly bigger test for the linking mechanism. Unpack the tar.bz2,
put
--- Comment #2 from thebohemian at gmx dot net 2005-11-01 19:38 ---
More hints for the test:
running the start script as:
??-run.sh nothing
should succeed on every vm in every variant since the critical code locations
are not touched in any way. However this only succeed for gij in int
--- Comment #3 from thebohemian at gmx dot net 2005-11-02 11:09 ---
Created an attachment (id=10113)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10113&action=view)
lazy linker test setup
This is a newer version of the test for class linking. The change is that the
actual tests a
--- Comment #4 from thebohemian at gmx dot net 2005-11-05 14:57 ---
By further inspecting the problem I got the impression that gcj's approach of
linking is flawed. As I understand it gcj does linking-on-initialization but
for the java language, being built-around the idea of late bindin
--- Comment #5 from thebohemian at gmx dot net 2005-11-05 15:59 ---
Created an attachment (id=10153)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10153&action=view)
preliminary patch - just for review
Here is a first start for a patch that makes access to static methods lazy. The
--- Comment #6 from aph at gcc dot gnu dot org 2005-11-06 16:15 ---
You can get the class by generating a special-purpose thunk using the libffi
invocation interface and pointing the vector at the thunk.
Virtual methods are easy to do by adding a suitable "NoClassDefFoundError"
method t
--- Comment #7 from thebohemian at gmx dot net 2005-11-07 10:34 ---
Created an attachment (id=10161)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10161&action=view)
preliminary patch - just for review
As andrew suggested I tried preparing a closure that is stored in the atable
an
--- Comment #8 from aph at gcc dot gnu dot org 2005-11-07 10:40 ---
It's not possibe from this description to tell when this problem occurs, nor
which kind of error it is. What does "crash" mean? When does it occur?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
--- Comment #9 from thebohemian at gmx dot net 2005-11-07 12:51 ---
Ok, more details:
With my patch applied I run the test application in lazylinker.tar.bz2. Set up
the variable CLASSPATH to point to lib/java/lazylinker.jar, start gdb with gij,
set a breakpoint at link.cc:743 and run the
--- Comment #10 from green at redhat dot com 2005-11-07 14:47 ---
This patch seems overly complicated to me. I don't think we need the
trampoline function and the ffi_call. Since we're just planning on throwing
an exception, it seems like you should just be able to pass the class name
--- Comment #11 from aph at gcc dot gnu dot org 2005-11-07 14:52 ---
You're not describing this clearly. :-)
We need to point the execution vector at a piece of code that throws an
exception with the appropriate args. Now, how should we do that?
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #12 from green at redhat dot com 2005-11-07 15:06 ---
(In reply to comment #11)
> You're not describing this clearly. :-)
>
> We need to point the execution vector at a piece of code that throws an
> exception with the appropriate args. Now, how should we do that?
The clo
--- Comment #13 from thebohemian at gmx dot net 2005-11-07 20:03 ---
anthony you're right. It should work without ffi_call invocation.
Thanks for the review. I try to find out whether this fixes my segfault too,
tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
--- Comment #14 from thebohemian at gmx dot net 2005-11-08 10:15 ---
> But we don't need to use ffi_call here, we can just call the exception
> throwing function directly.
Right. That worked fine.
> Then you'll realize that these functions don't need to be separate at all.
Yep. I made
--- Comment #15 from green at redhat dot com 2005-11-08 12:54 ---
(In reply to comment #14)
> > Then you'll realize that you don't need to bother setting up
> > the ffi_cif - all you need is the exception argument.
> I doubt that this is right. The ffi_prep_closure() needs to know which
--- Comment #16 from thebohemian at gmx dot net 2005-11-09 15:18 ---
Created an attachment (id=10187)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10187&action=view)
preliminary patch - just for review
This is another preview of the patch. The patch begins to more and more depend
--- Comment #17 from thebohemian at gmx dot net 2005-11-09 15:22 ---
Created an attachment (id=10188)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10188&action=view)
lazy linker test setup
This is a small update to the test setup. BC-compilation is now done with
debugging symbols
--- Comment #18 from aph at gcc dot gnu dot org 2005-11-09 15:28 ---
It's probably not the best idea to solve everything in this bug in a single
patch.
Better make several patches, for the different issues.
Also, if there are some verifier changes needed, let's get those committed
firs
--- Comment #19 from thebohemian at gmx dot net 2005-11-16 16:35 ---
Created an attachment (id=10254)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10254&action=view)
lazy linking - first part
This is the first part of the patch. See above for what it does.
--
thebohemian at g
--- Comment #20 from thebohemian at gmx dot net 2005-11-16 16:51 ---
Created an attachment (id=10255)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10255&action=view)
lazy linking - part 2
This is the second part of the lazy linking patch. Applying both fixes most of
the problems
--- Comment #21 from aph at gcc dot gnu dot org 2005-11-16 17:20 ---
Accesses to static fields should be fixed already when compiling BC.
We generate a call to _Jv_ResolvePoolEntry(Class, int) for every static field
reference, which resolves the target class and returns a pointer to the
--- Comment #22 from thebohemian at gmx dot net 2005-11-17 12:39 ---
Created an attachment (id=10262)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10262&action=view)
lazy linking - part 2
This is the same patch as above but corrects the behavior in case that the
static field of a
--- Comment #23 from aph at gcc dot gnu dot org 2005-11-17 13:46 ---
mm, I was wrong about static fields.
The problem is that a JV_CONSTANT_Fieldref constant pool entry points to a
JV_CONSTANT_Class, and at the present time we attempt to resolve that
JV_CONSTANT_Class reference at link
--- Comment #24 from aph at gcc dot gnu dot org 2005-12-02 17:43 ---
This is great, but an additional test case for dynamic method invocation is
needed.
We need to be able to continue if a class T that contains a method that refers
to a missing class M is initialized. At that time, the
--- Comment #25 from thebohemian at gmx dot net 2005-12-05 11:34 ---
aph, this would be your test case right?
class T {
void fail(){
System.out.println("fail-0");
M m = new M();
System.out.println("fail-1");
m.test();
}
}
// Bytecode removed
class M {
voi
--- Comment #26 from thebohemian at gmx dot net 2005-12-05 11:52 ---
Created an attachment (id=10407)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10407&action=view)
updated test setup
Added two more tests:
invokeMethodIndirect1
invokeMethodIndirect2
A new class HelperClassInvok
27 matches
Mail list logo
