[M3commit] CVS Update: cm3

Tony Hosking hosking at cs.purdue.edu
Sun May 9 00:51:18 CEST 2010



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




More information about the M3commit mailing list