[M3commit] CVS Update: cm3

[Tony Hosking]

I think we can argue that a programmer should program around this using TRY...FINALLY (i.e., even if they used FloatMode).

So, I think we are safe with jmpbuf instead of sigjmpbuf.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 8 May 2010, at 18:56, Jay K wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100508/9df8c30a/attachment-0002.html>