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 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.


H.J.