[M3devel] SaveRegsInStack / awkward SignalHandler, etc.

[Jay K]

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/2a5aa8f3/attachment-0002.html>