Re: PATCH: [4.1 Regression]: java compiler generates wrong code onia64

[Bryce McKinlay <mckinlay at redhat dot com>]

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