[M3commit] CVS Update: cm3

[Jay K]

er, I'm just plain wishy-washy.

If it is just Sparc, I think we're ok.

I'll see what Itanium requires "later" (I've had two machines for quite some months, been putting it off.)

 

 - Jay
 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Thu, 26 Nov 2009 18:02:03 +0000
CC: m3commit at elegosoft.com
Subject: Re: [M3commit] CVS Update: cm3



Also I'm ok with the assembly, just that we should be sure to have only one copy of it per processor and probably in separate .s files. I might put that back before long.
 
  - Jay
 


From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Thu, 26 Nov 2009 17:47:59 +0000
CC: m3commit at elegosoft.com
Subject: Re: [M3commit] CVS Update: cm3



I think the backing store might grow up from the same place that the stack grows down, so it is a matter of finding the higher "stackbase". Anyway Itanium will wait.
 
 - Jay

 


From: hosking at cs.purdue.edu
Date: Thu, 26 Nov 2009 12:06:28 -0500
To: jay.krell at cornell.edu
CC: m3commit at elegosoft.com
Subject: Re: [M3commit] CVS Update: cm3




Hmm.  So, maybe it is OK.  What I was concerned about was whether they were safe to call inside the signal handler.  Also, I note that setjmp/longjmp should also be checked for Itanium -- there we also have to worry about the register backing store which is not even in the stack as I understand it.  Take a look at the Boehm collector sources to see how they handle it there.  I'm OK with putting back setjmp/longjmp on the basis of what you've found....


On 25 Nov 2009, at 21:03, Jay K wrote:

> longjmp is MT-Level unsafe.

Tony, I see that now in the docs, but doesn't that sound very wierd and incorrect?
 
 /usr/sfw/bin/gobjdump -D /lib/libc.so > 1.txt
vi 1.txt
 
000314fc <_setjmp>:
   314fc:       c0 22 20 00     clr  [ %o0 ]
   31500:       dc 22 20 04     st  %sp, [ %o0 + 4 ]
   31504:       92 03 e0 08     add  %o7, 8, %o1
   31508:       d2 22 20 08     st  %o1, [ %o0 + 8 ]
   3150c:       fc 22 20 0c     st  %fp, [ %o0 + 0xc ]
   31510:       fe 22 20 10     st  %i7, [ %o0 + 0x10 ]
   31514:       81 c3 e0 08     retl
   31518:       90 10 00 00     mov  %g0, %o0


0003151c <_longjmp>:
    151c:       91 d0 20 03     ta  3
   31520:       d4 02 20 04     ld  [ %o0 + 4 ], %o2
   31524:       e0 1a a0 00     ldd  [ %o2 ], %l0
   31528:       e4 1a a0 08     ldd  [ %o2 + 8 ], %l2
   3152c:       e8 1a a0 10     ldd  [ %o2 + 0x10 ], %l4
   31530:       ec 1a a0 18     ldd  [ %o2 + 0x18 ], %l6
   31534:       f0 1a a0 20     ldd  [ %o2 + 0x20 ], %i0
   31538:       f4 1a a0 28     ldd  [ %o2 + 0x28 ], %i2
   3153c:       f8 1a a0 30     ldd  [ %o2 + 0x30 ], %i4
   31540:       fc 02 20 0c     ld  [ %o0 + 0xc ], %fp
   31544:       9c 10 00 0a     mov  %o2, %sp
   31548:       fe 02 20 10     ld  [ %o0 + 0x10 ], %i7
   3154c:       d6 02 20 08     ld  [ %o0 + 8 ], %o3
   31550:       80 90 00 09     tst  %o1
   31554:       12 80 00 03     bne  31560 <_longjmp+0x44>
   31558:       9e 22 e0 08     sub  %o3, 8, %o7
   3155c:       92 10 20 01     mov  1, %o1
   31560:       81 c3 e0 08     retl
   31564:       90 10 00 09     mov  %o1, %o0

I'll step through calls to them see if they look the same (network problems..)

 - Jay

 
> Date: Thu, 26 Nov 2009 01:31:53 +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 01:31:53
> 
> Modified files:
> cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.i3 
> ThreadPThread.m3 
> ThreadPThreadC.c 
> 
> Log message:
> Restore SPARC SaveRegsInStack implementation.
> longjmp is MT-Level unsafe.
> Not sure what this says about setjmp -- Boehm doesn't appear to process any
> context other than the stacks.
> 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20091126/7c5e7a6b/attachment-0002.html>