[M3devel] SaveRegsInStack / awkward SignalHandler, etc.

Fri Nov 27 04:32:41 CET 2009

(ok, I can see sigsuspend's setjmp is useful for regwindows, in order to enable longjmp, in order to flush registers, since SaveRegsInStack is all gone now)

 - Jay

From: jay.krell at cornell.edu
CC: hosking at cs.purdue.edu; m3devel at elegosoft.com
Subject: RE: [M3devel] SaveRegsInStack / awkward SignalHandler, etc.
Date: Fri, 27 Nov 2009 03:28:56 +0000

Yes thanks that seems better.
I'm not sure I follow it all yet. So the below questions might be nonsense resulting from misunderstanding.

The setjmp in sigsuspend seems redundant with stashing the context in SignalHandler.
  Doesn't it?

That would be to capture the context of the signal handler, not just the interrupted code?
  But we don't care? Except maybe on regwindows? But the setjmp data isn't in the described stack.

Interix doesn't have SIGINFO, but I don't test Interix often (months), and I doubt that should veto a reasonable approach for all other platforms. I have to experiment with Interix to see what to do. (what thread/stack signals are delivered on, if registers are available, if "direct suspend" is available, if user threads are viable with get/set/make/swapcontext, if user threads are viable with fibers)

If there's any advantage, getcontext can substitute for setjmp on non-registerwindows machines.
You know that.

Btw, I looked into the "jmpbuf obfuscation" in glibc, I was worried it might break some of our usage. But it seems ok. They don't obfuscate everything, just like sp and pc, which, like, obviously, are very useful for typical setjmp/longjmp usage, but not really useful at all for our purposes of looking for more pointers to scan, since pc isn't interesting and sp we endevour to get differently.

 - Jay

From: jay.krell at cornell.edu
To: jayk123 at hotmail.com
Subject: Re: [M3devel] SaveRegsInStack / awkward SignalHandler, etc.
Date: Thu, 26 Nov 2009 20:25:35 -0500
CC: hosking at cs.purdue.edu; jay.krell at cornell.edu; m3devel at elegosoft.com

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/20091127/a5f9c676/attachment-0002.html>