[M3devel] SaveRegsInStack

[Jay K]

Oh I thought I was current with SunStudio 12 but I'm out of date:

 

-bash-3.00$ cc -V
cc: Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12
usage: cc [ options] files.  Use 'cc -flags' for details

 

 - Jay
 


Subject: Re: [M3devel] SaveRegsInStack
From: hosking at cs.purdue.edu
Date: Sun, 22 Nov 2009 14:00:03 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu




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