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

["H. J. Lu" <hjl at lucon dot org>]

On Mon, Apr 18, 2005 at 01:09:33PM -0700, 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.
> 
> 

Here is something I wrote for linker

http://sourceware.org/ml/binutils/2005-03/msg00087.html

Basically, it may be a good idea to export a hidden symbol.


H.J.