[M3devel] SaveRegsInStack / awkward SignalHandler, etc.

[Tony Hosking]

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/79cc4046/attachment-0002.html>