[M3devel] SaveRegsInStack

Jay K jay.krell at cornell.edu
Sun Nov 22 06:02:53 CET 2009


The registers are spilled..to the stack right?..by virtue of longjmp issuing ta 3.

Which, while I haven't thought it through, I bet must be done.

You can see various refererences to flushrs in IA64 setjmp/longjmp as well.

(In college Professer Teitelbaum tricked me on a test with "implement setjmp/longjmp for sparc." I implemented them years ago for the simple 65816 but I failed to consider register windows..)

 

 

> http://www.sics.se/~psm/sparcstack.html

 

 

"Writing a library for multithreaded execution is an example that requires explicit flushing, as is longjmp()."

 

 > http://blogs.sun.com/d/entry/flush_register_windows

 

"Note that setjmp and longjmp which are sometimes used as part of code to implement context switching already have the appropriate flushes in them. "

 

 

So I contend:

 

void SaveRegsInStack(void)

{

#if defined(__sparc) || defined(__ia64__)

  jmpbuf j;

  if (!setjmp(j)) longjmp(j, 1);

#endif

}

 

It might not be ideal, but given that ta 3 is expensive anyway, and in one of the users there is already a setjmp call, I think it is pretty reasonable.

 

 

Once things are working better, unless you disagree, I'll make this change in ThreadPThreadC.c and RTStackC.c.

ThreadPThreadC.c already has a setjmp.

The ProcessMe/ProcessLive interaction will change slightly.

ProcessMe will pass stackbase to ProcessLive.

stack_grows_down will be in C to be accessible to ProcessLive.

I had this all written but have to back up and restore general health..

 

 

I've seen code that does ta 83 instead of ta 3 on Linux.

But I've also seen that that isn't right.

This way we can sweep all these issues away fairly well, for all sparc32, sparc64, and ia64 targets.

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Sat, 21 Nov 2009 22:19:12 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] SaveRegsInStack




Are we sure that &jb is a sufficient sp?  What about other registers saved by the "ta 3"?  They don't necessarily end up in jb.


On 21 Nov 2009, at 20:11, Jay K wrote:


Tony,
Looking at the disassembly of /usr/lib/libc.so and /usr/lib/sparcv9/libc.so, both longjmps contain ta  3.
So how about:
void *RTStack__SaveRegsInStack(void)
{
  jmp_buf jb;
  if (setjmp(jb))
  {
    longjmp(jb, 1); /* contains ta 3 */
    abort(); /* unreachable */
  }
  else
  {
    return &jb;
  }
}
 
Too wasteful?
 
 - Jay


 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sun, 22 Nov 2009 00:12:44 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] SaveRegsInStack

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


More information about the M3devel mailing list