Tomasz Grabiec wrote:
>>>> 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?
Oh, I didn't look too carefully but the one in throw_from_signal_bh()
looks suspicious. Is it really safe to use __builtin_frame_address(2)?
Pekka
------------------------------------------------------------------------------
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
