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 04:25:11PM -0400, Bryce McKinlay wrote:
> 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
> 

I understand. That is one reason why I proposed

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


H.J.