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

[Bryce McKinlay]

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();
  }
}