This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: assemble_external on .class files
- To: Jeffrey A Law <law at upchuck dot cygnus dot com>
- Subject: Re: assemble_external on .class files
- From: Mark Klein <mklein at dis dot com>
- Date: Tue, 25 May 1999 18:32:55 -0700
- Cc: egcs at egcs dot cygnus dot com,java-discuss at sourceware dot cygnus dot com
- References: <Your message of Thu, 20 May 1999 21:05:52 PDT. <4.1.19990520204749.00c7fa90@garfield.dis.com>
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