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

[Bryce McKinlay]

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"

>>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
>>
>>    
>>
>
>How should I setup your testcase? Can you make a tar file such that
>I can untar it and type make to see the result?
>  
>

Actually, try this test case:

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

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

The following commands should build & run it:

gcj SharedLib.java --shared -o libshared.so
gcj Main.java --main=Main -lshared -L.
LD_LIBRARY_PATH=/path/to/libgcj/lib:. ./a.out

You should see (with gcc HEAD):

Exception in thread "main" java.lang.RuntimeException
   at SharedLib.foo (libshared.so)
   at Main.main (a.out)

Symptom of this "PLT bug" occuring is the SharedLib.foo line is missing.

Bryce