* Re: assemble_external on .class files
@ 1999-05-23 11:45 Mark Klein
1999-05-23 19:27 ` Jeffrey A Law
1999-05-31 21:36 ` Mark Klein
0 siblings, 2 replies; 26+ messages in thread
From: Mark Klein @ 1999-05-23 11:45 UTC (permalink / raw)
To: law; +Cc: egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-23 11:45 assemble_external on .class files Mark Klein
@ 1999-05-23 19:27 ` Jeffrey A Law
1999-05-31 21:36 ` Jeffrey A Law
1999-05-31 21:36 ` Mark Klein
1 sibling, 1 reply; 26+ messages in thread
From: Jeffrey A Law @ 1999-05-23 19:27 UTC (permalink / raw)
To: Mark Klein; +Cc: egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-23 19:27 ` Jeffrey A Law
@ 1999-05-31 21:36 ` Jeffrey A Law
0 siblings, 0 replies; 26+ messages in thread
From: Jeffrey A Law @ 1999-05-31 21:36 UTC (permalink / raw)
To: Mark Klein; +Cc: egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-23 11:45 assemble_external on .class files Mark Klein
1999-05-23 19:27 ` Jeffrey A Law
@ 1999-05-31 21:36 ` Mark Klein
1 sibling, 0 replies; 26+ messages in thread
From: Mark Klein @ 1999-05-31 21:36 UTC (permalink / raw)
To: law; +Cc: egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* assemble_external on .class files
@ 1999-05-20 21:06 Mark Klein
1999-05-22 14:23 ` Jeffrey A Law
1999-05-31 21:36 ` Mark Klein
0 siblings, 2 replies; 26+ messages in thread
From: Mark Klein @ 1999-05-20 21:06 UTC (permalink / raw)
To: egcs; +Cc: java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-20 21:06 Mark Klein
@ 1999-05-22 14:23 ` Jeffrey A Law
1999-05-22 15:28 ` Mark Klein
` (2 more replies)
1999-05-31 21:36 ` Mark Klein
1 sibling, 3 replies; 26+ messages in thread
From: Jeffrey A Law @ 1999-05-22 14:23 UTC (permalink / raw)
To: Mark Klein; +Cc: egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-22 14:23 ` Jeffrey A Law
@ 1999-05-22 15:28 ` Mark Klein
1999-05-31 21:36 ` Mark Klein
1999-05-25 18:33 ` Mark Klein
1999-05-31 21:36 ` Jeffrey A Law
2 siblings, 1 reply; 26+ messages in thread
From: Mark Klein @ 1999-05-22 15:28 UTC (permalink / raw)
To: law; +Cc: egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-22 15:28 ` Mark Klein
@ 1999-05-31 21:36 ` Mark Klein
0 siblings, 0 replies; 26+ messages in thread
From: Mark Klein @ 1999-05-31 21:36 UTC (permalink / raw)
To: law; +Cc: egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-22 14:23 ` Jeffrey A Law
1999-05-22 15:28 ` Mark Klein
@ 1999-05-25 18:33 ` Mark Klein
1999-05-25 19:41 ` Jeffrey A Law
1999-05-31 21:36 ` Mark Klein
1999-05-31 21:36 ` Jeffrey A Law
2 siblings, 2 replies; 26+ messages in thread
From: Mark Klein @ 1999-05-25 18:33 UTC (permalink / raw)
To: Jeffrey A Law; +Cc: egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-25 18:33 ` Mark Klein
@ 1999-05-25 19:41 ` Jeffrey A Law
1999-05-25 21:00 ` Per Bothner
1999-05-31 21:36 ` Jeffrey A Law
1999-05-31 21:36 ` Mark Klein
1 sibling, 2 replies; 26+ messages in thread
From: Jeffrey A Law @ 1999-05-25 19:41 UTC (permalink / raw)
To: Mark Klein; +Cc: egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-25 19:41 ` Jeffrey A Law
@ 1999-05-25 21:00 ` Per Bothner
1999-05-25 21:50 ` Jeffrey A Law
1999-05-31 21:36 ` Per Bothner
1999-05-31 21:36 ` Jeffrey A Law
1 sibling, 2 replies; 26+ messages in thread
From: Per Bothner @ 1999-05-25 21:00 UTC (permalink / raw)
To: law; +Cc: Mark Klein, egcs, java-discuss
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/
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-25 21:00 ` Per Bothner
@ 1999-05-25 21:50 ` Jeffrey A Law
1999-05-25 22:19 ` Mark Klein
1999-05-31 21:36 ` Jeffrey A Law
1999-05-31 21:36 ` Per Bothner
1 sibling, 2 replies; 26+ messages in thread
From: Jeffrey A Law @ 1999-05-25 21:50 UTC (permalink / raw)
To: Per Bothner; +Cc: Mark Klein, egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-25 21:50 ` Jeffrey A Law
@ 1999-05-25 22:19 ` Mark Klein
1999-05-25 22:24 ` Jeffrey A Law
` (2 more replies)
1999-05-31 21:36 ` Jeffrey A Law
1 sibling, 3 replies; 26+ messages in thread
From: Mark Klein @ 1999-05-25 22:19 UTC (permalink / raw)
To: law, Per Bothner; +Cc: egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-25 22:19 ` Mark Klein
@ 1999-05-25 22:24 ` Jeffrey A Law
1999-05-31 21:36 ` Jeffrey A Law
1999-05-25 22:49 ` Per Bothner
1999-05-31 21:36 ` Mark Klein
2 siblings, 1 reply; 26+ messages in thread
From: Jeffrey A Law @ 1999-05-25 22:24 UTC (permalink / raw)
To: Mark Klein; +Cc: Per Bothner, egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-25 22:24 ` Jeffrey A Law
@ 1999-05-31 21:36 ` Jeffrey A Law
0 siblings, 0 replies; 26+ messages in thread
From: Jeffrey A Law @ 1999-05-31 21:36 UTC (permalink / raw)
To: Mark Klein; +Cc: Per Bothner, egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-25 22:19 ` Mark Klein
1999-05-25 22:24 ` Jeffrey A Law
@ 1999-05-25 22:49 ` Per Bothner
1999-05-31 14:53 ` Mark Klein
1999-05-31 21:36 ` Per Bothner
1999-05-31 21:36 ` Mark Klein
2 siblings, 2 replies; 26+ messages in thread
From: Per Bothner @ 1999-05-25 22:49 UTC (permalink / raw)
To: Mark Klein; +Cc: egcs, java-discuss
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/
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-25 22:49 ` Per Bothner
@ 1999-05-31 14:53 ` Mark Klein
1999-05-31 21:36 ` Mark Klein
1999-05-31 21:36 ` Per Bothner
1 sibling, 1 reply; 26+ messages in thread
From: Mark Klein @ 1999-05-31 14:53 UTC (permalink / raw)
To: Per Bothner; +Cc: egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-31 14:53 ` Mark Klein
@ 1999-05-31 21:36 ` Mark Klein
0 siblings, 0 replies; 26+ messages in thread
From: Mark Klein @ 1999-05-31 21:36 UTC (permalink / raw)
To: Per Bothner; +Cc: egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-25 22:49 ` Per Bothner
1999-05-31 14:53 ` Mark Klein
@ 1999-05-31 21:36 ` Per Bothner
1 sibling, 0 replies; 26+ messages in thread
From: Per Bothner @ 1999-05-31 21:36 UTC (permalink / raw)
To: Mark Klein; +Cc: egcs, java-discuss
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/
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-25 22:19 ` Mark Klein
1999-05-25 22:24 ` Jeffrey A Law
1999-05-25 22:49 ` Per Bothner
@ 1999-05-31 21:36 ` Mark Klein
2 siblings, 0 replies; 26+ messages in thread
From: Mark Klein @ 1999-05-31 21:36 UTC (permalink / raw)
To: law, Per Bothner; +Cc: egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-25 21:50 ` Jeffrey A Law
1999-05-25 22:19 ` Mark Klein
@ 1999-05-31 21:36 ` Jeffrey A Law
1 sibling, 0 replies; 26+ messages in thread
From: Jeffrey A Law @ 1999-05-31 21:36 UTC (permalink / raw)
To: Per Bothner; +Cc: Mark Klein, egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-25 21:00 ` Per Bothner
1999-05-25 21:50 ` Jeffrey A Law
@ 1999-05-31 21:36 ` Per Bothner
1 sibling, 0 replies; 26+ messages in thread
From: Per Bothner @ 1999-05-31 21:36 UTC (permalink / raw)
To: law; +Cc: Mark Klein, egcs, java-discuss
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/
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-25 19:41 ` Jeffrey A Law
1999-05-25 21:00 ` Per Bothner
@ 1999-05-31 21:36 ` Jeffrey A Law
1 sibling, 0 replies; 26+ messages in thread
From: Jeffrey A Law @ 1999-05-31 21:36 UTC (permalink / raw)
To: Mark Klein; +Cc: egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-25 18:33 ` Mark Klein
1999-05-25 19:41 ` Jeffrey A Law
@ 1999-05-31 21:36 ` Mark Klein
1 sibling, 0 replies; 26+ messages in thread
From: Mark Klein @ 1999-05-31 21:36 UTC (permalink / raw)
To: Jeffrey A Law; +Cc: egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: assemble_external on .class files
1999-05-22 14:23 ` Jeffrey A Law
1999-05-22 15:28 ` Mark Klein
1999-05-25 18:33 ` Mark Klein
@ 1999-05-31 21:36 ` Jeffrey A Law
2 siblings, 0 replies; 26+ messages in thread
From: Jeffrey A Law @ 1999-05-31 21:36 UTC (permalink / raw)
To: Mark Klein; +Cc: egcs, java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* assemble_external on .class files
1999-05-20 21:06 Mark Klein
1999-05-22 14:23 ` Jeffrey A Law
@ 1999-05-31 21:36 ` Mark Klein
1 sibling, 0 replies; 26+ messages in thread
From: Mark Klein @ 1999-05-31 21:36 UTC (permalink / raw)
To: egcs; +Cc: java-discuss
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
^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <Mark>]
end of thread, other threads:[~1999-05-31 21:36 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-05-23 11:45 assemble_external on .class files Mark Klein
1999-05-23 19:27 ` Jeffrey A Law
1999-05-31 21:36 ` Jeffrey A Law
1999-05-31 21:36 ` Mark Klein
-- strict thread matches above, loose matches on Subject: below --
1999-05-20 21:06 Mark Klein
1999-05-22 14:23 ` Jeffrey A Law
1999-05-22 15:28 ` Mark Klein
1999-05-31 21:36 ` Mark Klein
1999-05-25 18:33 ` Mark Klein
1999-05-25 19:41 ` Jeffrey A Law
1999-05-25 21:00 ` Per Bothner
1999-05-25 21:50 ` Jeffrey A Law
1999-05-25 22:19 ` Mark Klein
1999-05-25 22:24 ` Jeffrey A Law
1999-05-31 21:36 ` Jeffrey A Law
1999-05-25 22:49 ` Per Bothner
1999-05-31 14:53 ` Mark Klein
1999-05-31 21:36 ` Mark Klein
1999-05-31 21:36 ` Per Bothner
1999-05-31 21:36 ` Mark Klein
1999-05-31 21:36 ` Jeffrey A Law
1999-05-31 21:36 ` Per Bothner
1999-05-31 21:36 ` Jeffrey A Law
1999-05-31 21:36 ` Mark Klein
1999-05-31 21:36 ` Jeffrey A Law
1999-05-31 21:36 ` Mark Klein
[not found] <Mark>
[not found] ` <Klein's>
[not found] ` <message>
[not found] ` <of>
[not found] ` <"Tue,>
[not found] ` <25>
[not found] ` <May>
[not found] ` <1999>
[not found] ` <22:19:07>
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).