[M3devel] SaveRegsInStack

Tony Hosking hosking at cs.purdue.edu
Sun Nov 22 20:00:03 CET 2009


On 21 Nov 2009, at 22:32, Jay K wrote:

> It doesn't.
> Nevertheless, head and release are both broken by me, I'm probably going to roll things "way" back relative to today and proceed forward again, ignoring SOLsun for a bit and testing more as I go. I might take a break for a few hours first.
> (I only got onto SOLsun because my SOLgnu became broken and I had a backup, but that's bogus.)

I had verified the compile with Solaris CC on my Sun box.  Here's the compiler version:

niagara 62 $ cc -V
cc: Sun C 5.10 SunOS_sparc 2009/06/03

>  
> I /assume/ the main problems prior to today are:
>   - cond/mu mixup
>   - SOLsun broken (perhaps depending cc version) 
>  
> Where does ta 3 put the registers?

You should read up on SPARC hardware register windows.  They flush to the stack (which has space allocated for the register save/restores but normally unused).

>  ta 3 is expensive, and occurs either during gc or exception handling, so I kind of think if replace it with setjmp/longjmp, we're ok, and simpler/more portable (highly subjective).

Yes, so long as you do longjmp you should get the register window flush.

>  
>  - Jay
>  
> Subject: Re: [M3devel] SaveRegsInStack
> From: hosking at cs.purdue.edu
> Date: Sat, 21 Nov 2009 22:17:59 -0500
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> I had checked this with cc and it worked for me.
> 
> On 21 Nov 2009, at 19:12, Jay K wrote:
> 
> SOLsun doesn't like the current source:
>  
> C compiler failed compiling: ../src/runtime/SOLsun/RTStackC.c
> new source -> compiling ThreadPThreadC.c
> "../src/thread/PTHREAD/ThreadPThreadC.c", line 310: asm statement illegal outside function
> "../src/thread/PTHREAD/ThreadPThreadC.c", line 316: asm statement illegal outside function
> "../src/thread/PTHREAD/ThreadPThreadC.c", line 317: asm statement illegal outside function
> "../src/thread/PTHREAD/ThreadPThreadC.c", line 325: asm statement illegal outside function
> "../src/thread/PTHREAD/ThreadPThreadC.c", line 326: asm statement illegal outside function
> "../src/thread/PTHREAD/ThreadPThreadC.c", line 327: asm statement illegal outside function
> "../src/thread/PTHREAD/ThreadPThreadC.c", line 349: cannot recover from previous
> 
>  - Jay
>  
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] SaveRegsInStack
> Date: Sat, 21 Nov 2009 23:45:42 +0000
> 
> (or RTMachineC.c)
>  
>  - Jay
>  
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 21 Nov 2009 23:40:03 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] SaveRegsInStack
> 
>  > No, those don't have the desired effect on SPARC.
>  
> ok. I was somewhat guessing.
>  
>  > Why wouldn't SPARC* all have stack walkers?
>  
> Because I'm lazy and doubt anyone cares much about SPARC{32,64}_{LINUX,FREEBSD,NETBSD}, SPARC64_SOLARIS.
> ? But I can maybe try it at some point.
>  
> I also expect the way to go is use libunwind for nearly all targets, even probably SPARC*.
>  
>  > It would be good to have it in one place for *all* SPARC targets.  Where to put it
>  
> How about a new src/runtime/common/RTStackC.c, compiled on all platforms but with #ifdefs (the same #ifdefs as are currently used, but revisiting them at some point, the NETBSD and such seem suspicious).
> I think I'll do that shortly.
>  
> There is also TARGET_ARCH defined in the config files.
> We could do
> if exist(TARGET_ARCH/m3makefile)
>   include_dir(TARGET_ARCH)
> end
>  
> (similarly there is TARGET_OS).
>  
>  - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Sat, 21 Nov 2009 17:02:23 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] SaveRegsInStack
> 
> On 21 Nov 2009, at 15:38, Jay K wrote:
> 
> Tony, it bugs me that we have three copies of this code.
> Would it be reasonable and not very inefficient
> and maybe somewhat portable to replace it with
> setjmp or getcontext or alloca(1)?
> 
> No, those don't have the desired effect on SPARC.
> 
>  Or can we go back to having RTStack call RTMachine?
> (Imagine if SPARC* all had stack walkers, though I
> doubt that will happen, other than via libunwind.)
> 
> Why wouldn't SPARC* all have stack walkers?  Their stack frames are trivial to unwind.
> I agree that it is annoying to have multiple copies of this code.  It would be good to have it in one place for *all* SPARC targets.  Where to put it?
> 
>  
> 
>  - Jay
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091122/eb9a2400/attachment-0002.html>


More information about the M3devel mailing list