Pekka Enberg wrote: > Tomasz Grabiec wrote: > > Dnia 2009-11-17, wto o godzinie 16:39 +0200, Pekka Enberg pisze: > >> Tomek Grabiec wrote: > >>> The function was setting elem to the init_stack_trace_elem_current()'s > >>> frame which is error prone because after function returns its stack > >>> frame might be overriden by another function calls done from the > >>> caller. > >>> > >>> A fix for that is to make init_stack_trace_elem_current() set elem to > >>> the caller's frame. We must make it a macro becasue we can't rely on > >>> __builtin_frame_address(1) because of gcc optimizations. > >> We still have few instances of __builtin_frame_address() in the code. I > >> guess we need to fix those up as well? > > > > We must only be carefull about __builtin_frame_address(x) when x > 0. > > It is safe to call __builtin_frame_address(0). It is also safe to > > call __builtin_frame_address(x) for x>0 when it's used inside a function > > which is directly called from JIT and from JIT only. > > Yeah, I meant that we have few instances of __builtin_frame_address(1) > that probably need fixing.
I went through __builtin_frame_address() uses, and the only one that seems invalid to me is the one in trace_magic_trampoline() in jit/trace-jit.c. Is there another use you're worried about? Tomek ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Jatovm-devel mailing list Jatovm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jatovm-devel
