--- 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 {
void
--- 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=10407action=view)
updated test setup
Added two more tests:
invokeMethodIndirect1
invokeMethodIndirect2
A new class
--- 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,
--- 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=10262action=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 #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=10254action=view)
lazy linking - first part
This is the first part of the patch. See above for what it does.
--
thebohemian at
--- 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=10255action=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
--- 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=10187action=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=10188action=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
--- 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 #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=10161action=view)
preliminary patch - just for review
As andrew suggested I tried preparing a closure that is stored in the atable
and
--- 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
--- 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
--- 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?
--
--- 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
--- 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 #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 to
--- 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
--- 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=10153action=view)
preliminary patch - just for review
Here is a first start for a patch that makes access to static methods lazy. The
--- 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=10113action=view)
lazy linker test setup
This is a newer version of the test for class linking. The change is that the
actual tests
--
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=10103action=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
27 matches
Mail list logo
