This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
assemble_external on .class files
- To: egcs at egcs dot cygnus dot com
- Subject: assemble_external on .class files
- From: Mark Klein <mklein at dis dot com>
- Date: Thu, 20 May 1999 21:05:52 -0700
- Cc: java-discuss at sourceware dot cygnus dot com
I'm having a whale of a time trying to figure out a problem I'm
experiencing with gcj:
External procedure labels need to be .IMPORTED before they can
be used on my platform. Some of these are part of a dispatch table
created from classes such as java::lang::Object. My first attempt at
resolving this was to place an assemble_external() in layout_class(),
but that results in a lot of clutter with .IMPORT statements for a
whole bunch of things that really are not referenced. I suppose this
could be my brute force method, but I would prefer to only do the
.IMPORT for referenced methods/classes.
Here's HelloWorld's _vt_:
.IMPORT clone__Q34java4lang6Object,CODE
.IMPORT hashCode__Q34java4lang6Object,CODE
.align 4
HelloWorld virtual table
.word _CL_10HelloWorld
.word 0
.word P%java::lang::Object::finalize(void)
.word P%java::lang::Object::hashCode(void)
.word P%java::lang::Object::equals(java::lang::Object *)
.word P%java::lang::Object::toString(void)
.word P%java::lang::Object::clone(void)
Note that clone() and hashCode() have been imported. But finalize(),
equals() and tostring() have not. They are referenced in some fashion
in order to be in the virtual table when the rest of their brethren
are not. But, clone() and hashCode() must be referenced in some other
path in order to cause them to be imported.
I can't seem to figure out what that path is in order to make the same
changes for the other case. I also have not completed by gdb port, so
I am debugging this with the native (non-symbolic) debugger, which is
also probably leading to some of my confusion as I chase pointers in trees.
TIA,
M.
--
Mark Klein DIS International, Ltd.
http://www.dis.com 415-892-8400
PGP Public Key Available