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 01:55:35PM -0400, Bryce McKinlay wrote:
>  
>
> > H. J. Lu wrote:
> >
> >    
> >
> > > On Sun, Apr 17, 2005 at 11:33:13PM -0400, Andrew Pinski wrote:
> > >
> > >
> > >      
> > >
> > > > On Apr 17, 2005, at 11:31 PM, H. J. Lu wrote:
> > > >  
> > > >
> > > >        
> > > >
> > > > > make_local_function_alias is introduced in
> > > > >
> > > > > http://gcc.gnu.org/ml/java-patches/2004-q3/msg00618.html
> > > > >
> > > > > Is there a testcase to show it is really needed? I'd like to run it
> > > > > on ia32, x86_64 and ia64 to verify its usage.
> > > > >    
> > > > >
> > > > >          
> > > > This was done so that Java code could avoid GOT code.
> > > >
> > > >  
> > > >
> > > >        
> > > I am not sure if it makes any differences in GOT on ia32, x86_64 and
> > > ia64. Again, I'd like to see a testcase.
> > >
> > >
> > >      
> > Actually, this was done so that the function pointers in GCJ's method 
> > metadata always point to the actual entry point of a function, and not a 
> > PLT stub. Without this, the PC value returned by _Unwind_GetRegionStart 
> > is, in some circumstances[*], not the same as that in the method's 
> > metadata entry. When this happens, libgcj cannot map stack frames to the 
> > appropriate class and method, which is essential for correct stack 
> > traces and the Java security model.
> >
> > Bryce
> >
> > [*] See here for further explanation of the problem: 
> > http://gcc.gnu.org/ml/gcc/2003-12/msg00383.html
> >    
>
> If a function is local, which make_local_function_alias tries to deal
> with, why does it make a difference? Do you have a testcase to show
> that what kind of PLT/GOT changes it makes?
>  

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.

Here is a simple test case. Without make_local_function_alias(), when 
SharedLib is in a shared library, and Main is in the main binary, the 
call to SharedLib.foo() will not appear in the stack trace because the 
_Jv_Method for SharedLib.foo() points at a PLT entry.

Bryce


public class Main
{
 public static void main(String[] args)
 {
   SharedLib.foo();
 }
}

public class SharedLib
{
 public static void foo()
 {
   throw new RuntimeException();
 }
}