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

[H. J. Lu]

On Mon, Apr 18, 2005 at 02:15:59PM -0400, Bryce McKinlay wrote:
> 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.

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.

> 
> 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?

Thanks.


H.J.