This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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?


H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]