[LLVMdev] setjmp - longjmp

[Khaled ElWazeer]

Actually my problem is solved when I added "__sigsetjmp" to this list.

Thanks,
-Khaled

On Tue, Oct 4, 2011 at 10:27 PM, Khaled ElWazeer
<khalid.alwazeer at gmail.com>wrote:

>
> That code should do it, but I realized you only detect setjmp functions by
> name. My code is calling "__sigsetjmp" not "segsetjmp". You only support
> these functions:
>
>   static const char *ReturnsTwiceFns[] = {
>     "_setjmp",
>     "setjmp",
>     "sigsetjmp",
>     "setjmp_syscall",
>     "savectx",
>     "qsetjmp",
>     "vfork",
>     "getcontext"
>   };
>
> I think if I add mine to this list, it should work. I will try that.
>
> Thanks,
> -Khaled
>
>
> On Tue, Oct 4, 2011 at 7:15 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:
>
>>
>> On Oct 4, 2011, at 3:53 PM, Eli Friedman wrote:
>>
>> > On Tue, Oct 4, 2011 at 3:10 PM, Khaled ElWazeer
>> > <khalid.alwazeer at gmail.com> wrote:
>> >> Hi,
>> >>
>> >> I have some code which has sigsetjmp / longjmp. After a longjmp,
>> unreachable
>> >> is inserted, which is fine. The problem is that in the backend before
>> >> calling longjmp, some register was spilled to a stack location which is
>> live
>> >> across the jmp. I mean, it will be live after jumping. The stack
>> location
>> >> was initialized before the call to setjmp, and is used afterwards.
>> >>
>> >> Is there any bug in handling such a case? I mean, how do LLVM knows
>> about
>> >> CFG in case of longjmp / setjmp calls?
>> >
>> > No, no handling; we just don't inline anything into functions which
>> > call setjmp, and hope we get lucky.  In practice, that's generally
>> > good enough, given the restrictions on functions that call setjmp, but
>> > there are probably some subtle bugs nobody has discovered yet.
>>
>> We already disable stack slot sharing in functions that
>> callsFunctionThatReturnsTwice():
>>
>>  // If there are calls to setjmp or sigsetjmp, don't perform stack slot
>>  // coloring. The stack could be modified before the longjmp is executed,
>>  // resulting in the wrong value being used afterwards. (See
>>  // <rdar://problem/8007500>.)
>>  if (MF.callsSetJmp())
>>    return false;
>>
>> It might be possible for register coalescing to break something as well.
>>
>> /jakob
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111004/ee7543b4/attachment.html>