Re: PATCH: [4.1 Regression]: java compiler generates wrong code onia64

[Bryce McKinlay <mckinlay at redhat dot com>]

H. J. Lu wrote:

> On Mon, Apr 18, 2005 at 03:57:47PM -0400, Bryce McKinlay wrote:
>  
>
> > > I am not familiar with Java semantics. targetm.binds_local_p will
> > > tell you if a function may be discarded at the link time or overriden
> > > by something else at the run time. If a function is public and defined
> > > within the same compilation unit, it can be discarded at the link time
> > > due to linkonce/comdat and can be overriden by dynamic linker. If it is
> > > discarded or overriden, does a local alias make any more senses for
> > > Java? It seems that
> > >
> > > if (DECL_EXTERNAL (method) || !targetm.binds_local_p (method))
> > >  return method;
> > >
> > > will make sure that an aliase will only be created when the function
> > > is defined within the compilation unit and won't be discarded or
> > > overriden.
> > >
> > >
> > >      
> > Well, this is certainly the behaviour we would like for Java, but AFAIK 
> > we have no way to ensure that something always binds locally.
> >
> > binds_local_p is described as:
> >
> > /* True if EXP names an object for which name resolution must resolve
> >    to the current module.  */
> >
> > It seems to me that, given ELF semantics, a public symbol can always be 
> > overriden by the linker at runtime, thus targetm.binds_local_p will 
> > always be false? If there was some way to force targetm.binds_local_p 
> > then we wouldn't need make_local_function_alias()!
> >
> >    
>
>
> A public symbol can be overriden by the dynamic linker at runtime
> unless it is internal, hidden or protected. If you don't need to export
> it outside of the module, you can mark it hidden. If you have to export
> it outside of the module, you can mark it protected.
>  

Currently, ALL the symbols for Java methods need to be visible outside 
the module. This is because of both a) the need for compatibility with 
the C++ ABI for CNI (CNI allows "private" Java methods to be called from 
C++), and b) continued support for the "old" C++ ABI for Java code.

Using protected symbols everywhere would carry significant overhead, 
apparently - see http://gcc.gnu.org/ml/java-patches/2005-q1/msg00201.html

Bryce