Re: assemble_external on .class files

Re: assemble_external on .class files

[Mark Klein]

At 03:19 PM 5/22/99 -0600, Jeffrey A Law wrote:

>I wouldn't worry about the extra .IMPORTs.  In fact, it's a little known
>aspect of SOM that the assembler is responsible for _not_ adding an imported
>symbol to the undefined symbols for a module if that symbol is not actually
>referenced.

To which I responded:

>Thanks ... brute force method it is! Just when I was starting to see the
>_trees_ through the forest. :-)

On further thought ... what will this do to other platforms requiring
assemble_external? While this fix may work for PA-RISC, might it cause
other problems elsewhere?


--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: assemble_external on .class files

[Jeffrey A Law]

  In message < 4.1.19990523114346.00c77100@garfield.dis.com >you write:
  > >Thanks ... brute force method it is! Just when I was starting to see the
  > >_trees_ through the forest. :-)
  > 
  > On further thought ... what will this do to other platforms requiring
  > assemble_external? While this fix may work for PA-RISC, might it cause
  > other problems elsewhere?
I do not believe so -- first most systems don't require importing symbols.
Second, we're already importing symbols which are never referenced on those
few systems that need imports.

jeff

Re: assemble_external on .class files

[Mark Klein]

At 03:19 PM 5/22/99 -0600, Jeffrey A Law wrote:

>I wouldn't worry about the extra .IMPORTs.  In fact, it's a little known
>aspect of SOM that the assembler is responsible for _not_ adding an imported
>symbol to the undefined symbols for a module if that symbol is not actually
>referenced.

To which I responded:

>Thanks ... brute force method it is! Just when I was starting to see the
>_trees_ through the forest. :-)

On further thought ... what will this do to other platforms requiring
assemble_external? While this fix may work for PA-RISC, might it cause
other problems elsewhere?


--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: assemble_external on .class files

[Jeffrey A Law]

  In message < 4.1.19990523114346.00c77100@garfield.dis.com >you write:
  > >Thanks ... brute force method it is! Just when I was starting to see the
  > >_trees_ through the forest. :-)
  > 
  > On further thought ... what will this do to other platforms requiring
  > assemble_external? While this fix may work for PA-RISC, might it cause
  > other problems elsewhere?
I do not believe so -- first most systems don't require importing symbols.
Second, we're already importing symbols which are never referenced on those
few systems that need imports.

jeff

Re: assemble_external on .class files

[Mark Klein]

At 10:44 PM 5/25/99 -0600, Jeffrey A Law wrote:

>Thanks.  Hmmm, this makes me think that we're find with having them overloaded
>on the same bit.  Mark, I think this is a red herring.

Could be, but then there's a problem with assemble_external vis the usage of
DECL_EXTERNAL for the vtable. Recall my earlier example, from 
java::lang::Object:

Method name:"finalize" protected Signature: 4=()void
...
Method name:"hashCode" public native Signature: 11=()int

and the vtable:

__vt_10HelloWorld
        .word _CL_10HelloWorld
        .word 0
        .word P%finalize__Q34java4lang6Object
        .IMPORT hashCode__Q34java4lang6Object,CODE
        .word P%hashCode__Q34java4lang6Object
        .word P%equals__Q34java4lang6ObjectPQ34java4lang6Object
        .word P%toString__Q34java4lang6Object
        .IMPORT clone__Q34java4lang6Object,CODE
        .word P%clone__Q34java4lang6Object

Note that in order to use the plabels, the symbols must first be imported on
PA-RISC. In this case, we have finalize, and it isn't native. However, in
order for assemble_external to emit the .IMPORT, DECL_EXTERNAL (among others)
must be true. But, hashCode is native and is imported, hence the .IMPORT. 
Since this is in contradiction to usage in jc1 as explained by Per, I've 
got a problem....

Jeff (or any other PA-RISC user) ... has anyone tried gcj/libjava on a HP9000?
Or is this a problem only on the HP3000?

G'night, y'all.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: assemble_external on .class files

[Jeffrey A Law]

  In message < 4.1.19990525180956.00c96100@garfield.dis.com >you write:
  > Turns out that this also isn't a complete solution, partially because 
  > assemble_external is looking for DECL_EXTERNAL. The tree field used
  > for DECL_EXTERNAL is also used for METHOD_NATIVE for java. That also
  > explains why certain .IMPORTs were happening and others were not ...
  > only native methods were getting the .IMPORTs. 
  > 
  > There may be another problem here in that DECL_EXTERNAL is explicitly
  > set in various places and could ultimately end up in a usage conflict
  > between it and the usage of METHOD_NATIVE elswhere in the code.
  > 
  > Suggestions?
Split up DECL_EXTERNAL and METHOD_NATIVE.  It seems awful strange/wrong to
have them overloaded on the same bit.  Can someone from the Java side 
explain why they're using the same bit?  Especially since DECL_EXTERNAL has
a well defined meaning already.  It seems to me using a lang specific flag
would make a lot more sense for METHOD_NATIVE.


jeff

assemble_external on .class files

[Mark Klein]

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			

Re: assemble_external on .class files

[Mark Klein]

At 03:19 PM 5/22/99 -0600, Jeffrey A Law wrote:

>  > My first attempt at 
>  > resolving this was to place an assemble_external() in
layout_class_method(),
>  > but that results in a lot of clutter with .IMPORT statements for a 
>  > whole bunch of things that really are not referenced.

>I wouldn't worry about the extra .IMPORTs.  In fact, it's a little known
>aspect of SOM that the assembler is responsible for _not_ adding an imported
>symbol to the undefined symbols for a module if that symbol is not actually
>referenced.

Turns out that this also isn't a complete solution, partially because 
assemble_external is looking for DECL_EXTERNAL. The tree field used
for DECL_EXTERNAL is also used for METHOD_NATIVE for java. That also
explains why certain .IMPORTs were happening and others were not ...
only native methods were getting the .IMPORTs. 

There may be another problem here in that DECL_EXTERNAL is explicitly
set in various places and could ultimately end up in a usage conflict
between it and the usage of METHOD_NATIVE elswhere in the code.

Suggestions?


M.



--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: assemble_external on .class files

[Jeffrey A Law]

  In message < 4.1.19990520204749.00c7fa90@garfield.dis.com >you write:
  > 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.
I wouldn't worry about the extra .IMPORTs.  In fact, it's a little known
aspect of SOM that the assembler is responsible for _not_ adding an imported
symbol to the undefined symbols for a module if that symbol is not actually
referenced.

Jeff

Re: assemble_external on .class files

[Jeffrey A Law]

  In message < 4.1.19990525220502.00ca56a0@garfield.dis.com >you write:
  > Jeff (or any other PA-RISC user) ... has anyone tried gcj/libjava on a
  > HP9000?
Nobody that I'm aware of.  I talked to Anthony Green a week or two about
some of this stuff and it sounds like x86-linux & sparc-solaris are the
native platforms that should "just work" out of the box since that's what
the Java team is using/testing regularly.  So it's not a huge suprise that
we've got a few issues to resolve on the PA (and likely other targets).

jeff

Re: assemble_external on .class files

[Per Bothner]

Jeffrey A Law <law@cygnus.com> writes:
> Split up DECL_EXTERNAL and METHOD_NATIVE.  It seems awful strange/wrong to
> have them overloaded on the same bit.  Can someone from the Java side 
> explain why they're using the same bit?  Especially since DECL_EXTERNAL has
> a well defined meaning already.  It seems to me using a lang specific flag
> would make a lot more sense for METHOD_NATIVE.

Well, the logic was the assumption that they would always be the same.

In a Java class, we have three kinds of methods:

(1) Regular methods (static or instance), with method bodies in the class
body.  These methods are neither native, nor external, since they are
declared in the current input (.java or .class) file.

(2) Native methods, which do not have bodies.  These must be bound to some
methods defined in some extenal C++ file.  Hence, they need to have
DECL_EXTERNAL set - as well as METHOD_NATIVE.

(3) Abstract methods - which have no bodies anywhere.  If they are ever
referenced, it would be a compiler bug.

I skimmed the earlier messages in this thread, which may be why I still don't
understand why there would be any reason to split up the flags.

However, perhaps there should be a comment where METHOD_NATIVE is
defined.  Something like the following may suffice:
/* Only native methods are external (and vice versa). */
or perhaps:
/* A method is external if and only if it is native. */
-- 
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

Re: assemble_external on .class files

[Per Bothner]

Mark Klein <mklein@dis.com> writes:

> Could be, but then there's a problem with assemble_external vis the usage of
> DECL_EXTERNAL for the vtable. Recall my earlier example, from 
> java::lang::Object:

Ah - that was in a message that had expired.

My logic only applies to entries in the "method table".  It is
wrong for entries in the vtable.  It is also wrong for calls
to static methods in other classes.

METHOD_NATIVE does need to be split from DECL_EXTERNAL.
There doesn't seem to be any available DECL_LANG_FLAGs,
but there are some TREE_LANG_FLAGSs available (in FUNCTION_DECLs).

That means that we need to set DECL_EXTERNAL separately.
I think it should be true for any methods that has METHOD_NATIVE,
*or* if is_compiled_class (DECL_CONTEXT (method_decl)) < 2.

 
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

Re: assemble_external on .class files

[Mark Klein]

At 03:19 PM 5/22/99 -0600, Jeffrey A Law wrote:

>I wouldn't worry about the extra .IMPORTs.  In fact, it's a little known
>aspect of SOM that the assembler is responsible for _not_ adding an imported
>symbol to the undefined symbols for a module if that symbol is not actually
>referenced.

Thanks ... brute force method it is! Just when I was starting to see the
_trees_ through the forest. :-)


--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: assemble_external on .class files

[Jeffrey A Law]

  In message < m2n1yseark.fsf@magnus.cygnus.com >you write:
  > Well, the logic was the assumption that they would always be the same.
  > 
  > In a Java class, we have three kinds of methods:
  > 
  > (1) Regular methods (static or instance), with method bodies in the class
  > body.  These methods are neither native, nor external, since they are
  > declared in the current input (.java or .class) file.
  > 
  > (2) Native methods, which do not have bodies.  These must be bound to some
  > methods defined in some extenal C++ file.  Hence, they need to have
  > DECL_EXTERNAL set - as well as METHOD_NATIVE.
  > 
  > (3) Abstract methods - which have no bodies anywhere.  If they are ever
  > referenced, it would be a compiler bug.
Thanks.  Hmmm, this makes me think that we're find with having them overloaded
on the same bit.  Mark, I think this is a red herring.

  > However, perhaps there should be a comment where METHOD_NATIVE is
  > defined.  Something like the following may suffice:
  > /* Only native methods are external (and vice versa). */
  > or perhaps:
  > /* A method is external if and only if it is native. */
Yea.  It would help clarify things for the future.

Thanks again!
jeff

Re: assemble_external on .class files

[Mark Klein]

At 10:55 PM 5/25/99 -0700, Per Bothner wrote:

>METHOD_NATIVE does need to be split from DECL_EXTERNAL.
>There doesn't seem to be any available DECL_LANG_FLAGs,
>but there are some TREE_LANG_FLAGSs available (in FUNCTION_DECLs).

Grabbed TREE_LANG_FLAG_6.

>That means that we need to set DECL_EXTERNAL separately.
>I think it should be true for any methods that has METHOD_NATIVE,
>*or* if is_compiled_class (DECL_CONTEXT (method_decl)) < 2.

The latter doesn't appear to be complete either since there are
certain classes which are external (e.g. java.lang.Object) where
is_compiled_class (DECL_CONTEXT (method_decl)) is returning 2.

Regards,


M.

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: assemble_external on .class files

[Mark Klein]

At 10:55 PM 5/25/99 -0700, Per Bothner wrote:

>METHOD_NATIVE does need to be split from DECL_EXTERNAL.
>There doesn't seem to be any available DECL_LANG_FLAGs,
>but there are some TREE_LANG_FLAGSs available (in FUNCTION_DECLs).

Grabbed TREE_LANG_FLAG_6.

>That means that we need to set DECL_EXTERNAL separately.
>I think it should be true for any methods that has METHOD_NATIVE,
>*or* if is_compiled_class (DECL_CONTEXT (method_decl)) < 2.

The latter doesn't appear to be complete either since there are
certain classes which are external (e.g. java.lang.Object) where
is_compiled_class (DECL_CONTEXT (method_decl)) is returning 2.

Regards,


M.

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: assemble_external on .class files

[Per Bothner]

Mark Klein <mklein@dis.com> writes:

> Could be, but then there's a problem with assemble_external vis the usage of
> DECL_EXTERNAL for the vtable. Recall my earlier example, from 
> java::lang::Object:

Ah - that was in a message that had expired.

My logic only applies to entries in the "method table".  It is
wrong for entries in the vtable.  It is also wrong for calls
to static methods in other classes.

METHOD_NATIVE does need to be split from DECL_EXTERNAL.
There doesn't seem to be any available DECL_LANG_FLAGs,
but there are some TREE_LANG_FLAGSs available (in FUNCTION_DECLs).

That means that we need to set DECL_EXTERNAL separately.
I think it should be true for any methods that has METHOD_NATIVE,
*or* if is_compiled_class (DECL_CONTEXT (method_decl)) < 2.

 
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

Re: assemble_external on .class files

[Jeffrey A Law]

  In message < 4.1.19990525220502.00ca56a0@garfield.dis.com >you write:
  > Jeff (or any other PA-RISC user) ... has anyone tried gcj/libjava on a
  > HP9000?
Nobody that I'm aware of.  I talked to Anthony Green a week or two about
some of this stuff and it sounds like x86-linux & sparc-solaris are the
native platforms that should "just work" out of the box since that's what
the Java team is using/testing regularly.  So it's not a huge suprise that
we've got a few issues to resolve on the PA (and likely other targets).

jeff

Re: assemble_external on .class files

[Mark Klein]

At 10:44 PM 5/25/99 -0600, Jeffrey A Law wrote:

>Thanks.  Hmmm, this makes me think that we're find with having them overloaded
>on the same bit.  Mark, I think this is a red herring.

Could be, but then there's a problem with assemble_external vis the usage of
DECL_EXTERNAL for the vtable. Recall my earlier example, from 
java::lang::Object:

Method name:"finalize" protected Signature: 4=()void
...
Method name:"hashCode" public native Signature: 11=()int

and the vtable:

__vt_10HelloWorld
        .word _CL_10HelloWorld
        .word 0
        .word P%finalize__Q34java4lang6Object
        .IMPORT hashCode__Q34java4lang6Object,CODE
        .word P%hashCode__Q34java4lang6Object
        .word P%equals__Q34java4lang6ObjectPQ34java4lang6Object
        .word P%toString__Q34java4lang6Object
        .IMPORT clone__Q34java4lang6Object,CODE
        .word P%clone__Q34java4lang6Object

Note that in order to use the plabels, the symbols must first be imported on
PA-RISC. In this case, we have finalize, and it isn't native. However, in
order for assemble_external to emit the .IMPORT, DECL_EXTERNAL (among others)
must be true. But, hashCode is native and is imported, hence the .IMPORT. 
Since this is in contradiction to usage in jc1 as explained by Per, I've 
got a problem....

Jeff (or any other PA-RISC user) ... has anyone tried gcj/libjava on a HP9000?
Or is this a problem only on the HP3000?

G'night, y'all.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: assemble_external on .class files

[Jeffrey A Law]

  In message < m2n1yseark.fsf@magnus.cygnus.com >you write:
  > Well, the logic was the assumption that they would always be the same.
  > 
  > In a Java class, we have three kinds of methods:
  > 
  > (1) Regular methods (static or instance), with method bodies in the class
  > body.  These methods are neither native, nor external, since they are
  > declared in the current input (.java or .class) file.
  > 
  > (2) Native methods, which do not have bodies.  These must be bound to some
  > methods defined in some extenal C++ file.  Hence, they need to have
  > DECL_EXTERNAL set - as well as METHOD_NATIVE.
  > 
  > (3) Abstract methods - which have no bodies anywhere.  If they are ever
  > referenced, it would be a compiler bug.
Thanks.  Hmmm, this makes me think that we're find with having them overloaded
on the same bit.  Mark, I think this is a red herring.

  > However, perhaps there should be a comment where METHOD_NATIVE is
  > defined.  Something like the following may suffice:
  > /* Only native methods are external (and vice versa). */
  > or perhaps:
  > /* A method is external if and only if it is native. */
Yea.  It would help clarify things for the future.

Thanks again!
jeff

Re: assemble_external on .class files

[Per Bothner]

Jeffrey A Law <law@cygnus.com> writes:
> Split up DECL_EXTERNAL and METHOD_NATIVE.  It seems awful strange/wrong to
> have them overloaded on the same bit.  Can someone from the Java side 
> explain why they're using the same bit?  Especially since DECL_EXTERNAL has
> a well defined meaning already.  It seems to me using a lang specific flag
> would make a lot more sense for METHOD_NATIVE.

Well, the logic was the assumption that they would always be the same.

In a Java class, we have three kinds of methods:

(1) Regular methods (static or instance), with method bodies in the class
body.  These methods are neither native, nor external, since they are
declared in the current input (.java or .class) file.

(2) Native methods, which do not have bodies.  These must be bound to some
methods defined in some extenal C++ file.  Hence, they need to have
DECL_EXTERNAL set - as well as METHOD_NATIVE.

(3) Abstract methods - which have no bodies anywhere.  If they are ever
referenced, it would be a compiler bug.

I skimmed the earlier messages in this thread, which may be why I still don't
understand why there would be any reason to split up the flags.

However, perhaps there should be a comment where METHOD_NATIVE is
defined.  Something like the following may suffice:
/* Only native methods are external (and vice versa). */
or perhaps:
/* A method is external if and only if it is native. */
-- 
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

Re: assemble_external on .class files

[Jeffrey A Law]

  In message < 4.1.19990525180956.00c96100@garfield.dis.com >you write:
  > Turns out that this also isn't a complete solution, partially because 
  > assemble_external is looking for DECL_EXTERNAL. The tree field used
  > for DECL_EXTERNAL is also used for METHOD_NATIVE for java. That also
  > explains why certain .IMPORTs were happening and others were not ...
  > only native methods were getting the .IMPORTs. 
  > 
  > There may be another problem here in that DECL_EXTERNAL is explicitly
  > set in various places and could ultimately end up in a usage conflict
  > between it and the usage of METHOD_NATIVE elswhere in the code.
  > 
  > Suggestions?
Split up DECL_EXTERNAL and METHOD_NATIVE.  It seems awful strange/wrong to
have them overloaded on the same bit.  Can someone from the Java side 
explain why they're using the same bit?  Especially since DECL_EXTERNAL has
a well defined meaning already.  It seems to me using a lang specific flag
would make a lot more sense for METHOD_NATIVE.


jeff

Re: assemble_external on .class files

[Mark Klein]

At 03:19 PM 5/22/99 -0600, Jeffrey A Law wrote:

>  > My first attempt at 
>  > resolving this was to place an assemble_external() in
layout_class_method(),
>  > but that results in a lot of clutter with .IMPORT statements for a 
>  > whole bunch of things that really are not referenced.

>I wouldn't worry about the extra .IMPORTs.  In fact, it's a little known
>aspect of SOM that the assembler is responsible for _not_ adding an imported
>symbol to the undefined symbols for a module if that symbol is not actually
>referenced.

Turns out that this also isn't a complete solution, partially because 
assemble_external is looking for DECL_EXTERNAL. The tree field used
for DECL_EXTERNAL is also used for METHOD_NATIVE for java. That also
explains why certain .IMPORTs were happening and others were not ...
only native methods were getting the .IMPORTs. 

There may be another problem here in that DECL_EXTERNAL is explicitly
set in various places and could ultimately end up in a usage conflict
between it and the usage of METHOD_NATIVE elswhere in the code.

Suggestions?


M.



--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: assemble_external on .class files

[Mark Klein]

At 03:19 PM 5/22/99 -0600, Jeffrey A Law wrote:

>I wouldn't worry about the extra .IMPORTs.  In fact, it's a little known
>aspect of SOM that the assembler is responsible for _not_ adding an imported
>symbol to the undefined symbols for a module if that symbol is not actually
>referenced.

Thanks ... brute force method it is! Just when I was starting to see the
_trees_ through the forest. :-)


--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: assemble_external on .class files

[Jeffrey A Law]

  In message < 4.1.19990520204749.00c7fa90@garfield.dis.com >you write:
  > 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.
I wouldn't worry about the extra .IMPORTs.  In fact, it's a little known
aspect of SOM that the assembler is responsible for _not_ adding an imported
symbol to the undefined symbols for a module if that symbol is not actually
referenced.

Jeff

assemble_external on .class files

[Mark Klein]

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