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

H. J. Lu hjl@lucon.org
Mon Apr 18 19:34:00 GMT 2005


On Mon, Apr 18, 2005 at 12:16:10PM -0700, H. J. Lu wrote:
> On Mon, Apr 18, 2005 at 03:03:02PM -0400, Bryce McKinlay wrote:
> > H. J. Lu wrote:
> > 
> > >>The function pointers in the GCJ method metadata (_Jv_Method) are always 
> > >>local, except in the case of CNI functions. But, even local function 
> > >>references in a .so will point at PLT entries if the function is also 
> > >>referenced from the main binary.
> > >>   
> > >>
> > >
> > >Whan you said "local function", did you mean
> > >
> > >1. A local data variable with function type. Or
> > >2. A function symbol which isn't visible to the outside. Or
> > >3. A global data variable with function type pointing to a local
> > >function.
> > >
> > >I ran into a very tricky issue. But I don't have a testcase. This
> > >problem may be related.
> > > 
> > >
> > I mean "a reference to a function which is public (visible to the 
> > outside) and defined within the same compilation unit"
> 
> That makes senses now. For me, "local function" means a different
> thing :-). If you want to know if a function will be bound locally
> at the run time, you should use targetm.binds_local_p. I think this
> patch is correct.
> 
> 
> H.J.
> ---
> 2005-04-18  H.J. Lu  <hongjiu.lu@intel.com>
> 
> 	PR java/21070
> 	* class.c (make_local_function_alias): Use targetm.binds_local_p
> 	to check if a function is bound locally.
> 

Second thought. Since you can only create an aliase for a symbol
defined within the same file, targetm.binds_local_p alone may not be
suitable for this purpose.


H.J.



More information about the Java-patches mailing list