[M3devel] SaveRegsInStack / awkward SignalHandler, etc.

[jay.krell at cornell.edu]

Oops no i am not up to date yet, later..

  - Jay (phone)

On Nov 26, 2009, at 7:36 PM, jayk123 at hotmail.com wrote:

> (sorry I know it sounds rude)
> I already had & my comments had it in mind.
>
>  - Jay (phone)
>
> On Nov 26, 2009, at 3:59 PM, Tony Hosking <hosking at cs.purdue.edu>  
> wrote:
>
>> Take a look at the latest and see what you think.
>>
>> On 26 Nov 2009, at 15:01, Jay K wrote:
>>
>>> Ok I guess. Then the setjmp should be under #ifdef  
>>> M3_REGISTER_WINDOWS. ?
>>> (In ProcessOther, not ProcessLive.)
>>> Wait...doesn't ProcessLive need a setjmp or getcontext??
>>> I can buy the notion that:
>>>
>>>  > The heap references we are interested in will be somewhere on  
>>> the stack.
>>>
>>>
>>> You are certain?
>>> This is the main difference.
>>>
>>>
>>> Also, if we can be so loose about it, then the extra function call  
>>> isn't needed either, right?
>>> Just the old ADR(xx) (or ADR(me) or ADR(errno), no need for  
>>> another variable).
>>>
>>>
>>> My approach as I said was more well defined, but as you say, maybe  
>>> no need for it.
>>>
>>>
>>> (Itanium looks easy enough; setjmp/longjmp to flush registers,  
>>> getcontext to get the current bsp, get the current bsp in thread  
>>> create and then scan between that and whatever getcontext returns  
>>> later, and __libc_ia64_something_or_other for the first thread,  
>>> and a hardcoded constant on FreeBSD/IA64 -- this per a quick read  
>>> of the Ruby code it turns out.. HP-UX and VMS on IA64 TBD..Windows  
>>> is probably trivial, what with compiler intrinsics...)
>>>
>>>
>>>  - Jay
>>>
>>> Subject: Re: SaveRegsInStack / awkward SignalHandler, etc.
>>> From: hosking at cs.purdue.edu
>>> Date: Thu, 26 Nov 2009 14:21:14 -0500
>>> CC: m3devel at elegosoft.com
>>> To: jay.krell at cornell.edu
>>>
>>> On 26 Nov 2009, at 14:11, Jay K wrote:
>>>
>>> Tony I agree my code was "awkward" (what I'd really like is for  
>>> cm3 to output .h files
>>> so that interop can be "natural", reliable, clear, idiomatic,  
>>> correct.. but until then..)
>>> (And if such .h files were output, I'd just write the entire  
>>> signal handler in C.)
>>>
>>> However I found the meaning and correctness of my code clearer.
>>> In particular I was getting the registers into the stack keeping
>>> the stack below their location.
>>>
>>>
>>> In your case, you know, sem_post/sigsuspend will overwrite part of  
>>> that.
>>>
>>> We don't care that it is overwritten.   We just need a reasonable  
>>> approximation of the top of the stack.  The heap references we are  
>>> interested in will be somewhere on the stack.
>>>
>>>  Now, I grant, it isn't all clear -- your code has a high chance  
>>> of being correct.
>>> The (current) registers probably are already higher up the signal  
>>> call stack.
>>> So the stack pointer for the signal handler itself probably  
>>> suffices -- what
>>> you were using prior to yesterday.
>>>
>>> Right.  We just needed to make sure that the Windows were saved on  
>>> SPARC.
>>>
>>>  "Briefly: I like the way I had it." (except, again, yes the C <=>  
>>> Modula-3 interop is "awkard").
>>>
>>> I had problems with the blurring of the ActState enumeration  
>>> across the C/M3 boundary.
>>>
>>>
>>> ?
>>>
>>>  - Jay
>>>
>>>
>>> > Date: Thu, 26 Nov 2009 19:44:24 +0000
>>> > To: m3commit at elegosoft.com
>>> > From: hosking at elego.de
>>> > Subject: [M3commit] CVS Update: cm3
>>> >
>>> > CVSROOT: /usr/cvs
>>> > Changes by: hosking at birch. 09/11/26 19:44:24
>>> >
>>> > Modified files:
>>> > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.i3
>>> > ThreadPThread.m3
>>> > ThreadPThreadC.c
>>> >
>>> > Log message:
>>> > Refactor slightly to avoid need for awkward SignalHandlerC call.
>>> >
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091126/b1252cdd/attachment-0002.html>