[M3commit] CVS Update: cm3

[Jay K]

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
>>>
>>
>