[M3commit] CVS Update: cm3

[Jay K]

The sparc stack walker I don't think restores signal mask.


void RTStack__Unwind (Frame* target)
{
  greg_t *reg = target->ctxt.uc_mcontext.gregs;

  RTStack__SaveRegsInStack();

  if (target->lock != FrameLock) abort();
  reg[REG_PC] = (greg_t)target->pc + 8;/* for return address */
  reg[REG_nPC] = reg[REG_PC] + 4;
  reg[REG_SP] = (greg_t)target->sp;
  reg[REG_O7] = target->sp->fr_savpc;
  setcontext(&target->ctxt);
}


The longjmp function in Csetjmp.i3 is called "ulongjmp" I guess either "u" for user" or "u" for underscore.
Both, but esp. the second, implying an original intent to not restore signal mask?
But I'm not sure.


I understand that there is a big tension here between correctness at all costs, unclear obligation to the user,
and performance.  Signal mask could even perhaps be something that doesn't take a kernel call to save/restore.
It could be in some user-accessible per-thread area. ? It might be worth checking..


 - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: jkrell at elego.de; m3commit at elegosoft.com
> Subject: RE: [M3commit] CVS Update: cm3
> Date: Sat, 8 May 2010 22:56:37 +0000
>
>
> Is "proper" saving/restoring as much as we can think of, or is it fast, or is it matching Ada and C++, or .. ?
> Ada and C++ (gnat and g++) have often/historically used setjmp/longjmp.
>   configure -enable-sjlj-exceptions
> It might be interesting to see if they try to avoid the signal mask versions when they use setjmp/longjmp.
> Lately they use table-based unwinding on platforms that they can -- which is to say, I *really* doubt
> they save/restore the signal mask, but they might.
>
>
>  - Jay
>
> ----------------------------------------
>> Subject: Re: [M3commit] CVS Update: cm3
>> From: hosking at cs.purdue.edu
>> Date: Sat, 8 May 2010 18:51:18 -0400
>> CC: jkrell at elego.de; m3commit at elegosoft.com
>> To: jay.krell at cornell.edu
>>
>>
>>
>> On 8 May 2010, at 18:38, Jay K wrote:
>>
>>> Or, understood, you really think we might throw around a signal mask change?
>>
>> It's possible.
>>
>>> Realize also that sigsetjmp or setjmp, whichever we use, is called incredibly often, and sigsetjmp is likely
>>> much much slower. Also notice..this I'll have to check...have we ever called sigsetjmp?
>>> Well, no, I doubt it. But maybe setjmp vs. _setjmp.
>>> Again though, this can be significantly slow.
>>>
>>>
>>> Ultimately as well...see..I started this email without a firm opinion, but now I'm "firming" toward the change I made.
>>> Consider C++ exceptions. Consider libunwind. Consider the SPARC stack walker (which I have to look at).
>>> Do they save/restore signal masks? I doubt it. Maybe. We can look into it. But I doubt it.
>>
>> We should confirm.
>>
>>> Raising an exception can indeed by slow. But entering a function with finally (or destructors) should not be overly so.
>>
>> Ultimately, we should use proper stack unwinding wherever possible.
>>
>>>
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Sat, 8 May 2010 18:28:36 -0400
>>>> To: jkrell at elego.de
>>>> CC: m3commit at elegosoft.com
>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>
>>>> Ah, now I remember. sigjmpbuf is important for unwinding on exception to make sure that if we unwind through a frame where the programmer changed the signal mask that we also restore the signal mask of the caller. I think you also probably break things like FloatMode by not restoring the signal mask properly.
>>>>
>>>> On 9 May 2010, at 00:09, Jay Krell wrote:
>>>>
>>>>> CVSROOT: /usr/cvs
>>>>> Changes by: jkrell at birch. 10/05/09 00:09:58
>>>>>
>>>>> Modified files:
>>>>> cm3/m3-sys/m3middle/src/: Target.i3 Target.m3
>>>>>
>>>>> Log message:
>>>>> add SPARC32_SOLARIS
>>>>>
>>>>> correct jmpbuf sizes for I386_SOLARIS, AMD64_SOLARIS
>>>>> notice again that jmpbuf is much much smaller than sigjmpbuf,
>>>>> and this is jmpbuf; specifically:
>>>>> I386_SOLARIS jmpbuf 40 bytes with 4 align
>>>>> AMD64_SOLARIS jmpbuf 64 bytes with 8 align
>>>>> I386_SOLARIS sigjmpbuf 512 bytes with 4 align
>>>>> AMD64_SOLARIS sigjmpbuf 1024 bytes with 8 align
>>>>>
>>>>> remove some level of heap allocation of calling conventions
>>>>>
>>>>> accept all calling conventions for all targets
>>>>> Only NT386 has calling conventions, and it *highly* likely
>>>>> the only target ever to have them, therefore the mechanism
>>>>> does not need to be further generalized. (MIPS32 has two
>>>>> ABIs, but those will probably be two targets)
>>>>> This might let us save some unnecessary forking of *.i3 files.
>>>>> The initialization here can be further streamlined.
>>>>>
>>>>> shrink SOLgnu/SOLsun from sigjmpbuf to jmpbuf
>>>>> I'm not sure we use this though since we have a stack walker.
>>>>> fix SPARC64_SOLARIS too to be smaller
>>>>>
>>>>> SPARC32_SOLARIS
>>>>> jmpbuf size: 48
>>>>> sigjmpbuf size: 76
>>>>> alignment: 4 4
>>>>>
>>>>> SPARC64_SOLARIS
>>>>> jmpbuf size: 96
>>>>> sigjmpbuf size: 152
>>>>> alignment: 8 8
>>>>
>>>
>>
>