[M3devel] SaveRegsInStack / awkward SignalHandler, etc.

[Jay K]

 > Interix doesn't have SIGINFO 

 

It looks like Interix does something like:

 

 

Has an extra thread waiting for cross thread signals.

That thread uses NtSuspendThread/NtGetThreadContext/NtSetThreadContext/NtResumeThread to send signals.

And some NtQueryInformationThread and NtQueueUserApc.

Not sure exactly.

 

 

And that there's no public way to do this.

And I don't think the sigaction is passed.

Indeed, the register state probably need not be on or accessible via the thread's stack.

(again this is Interix)

 

In newer Interix versions you can have "mixed" posix and win32, then you could use SuspendThread/GetThreadContext/etc.

 

 - Jay

 
> From: jay.krell at cornell.edu
> Date: Fri, 27 Nov 2009 03:32:41 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] SaveRegsInStack / awkward SignalHandler, etc.
> 
> 
> (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
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091127/48f3d141/attachment-0002.html>