[M3commit] CVS Update: cm3

[Tony Hosking]

I guess it is possible, though it would only be problematic for self in RunThread if it got allocated outside the range of xx (i.e., below xx in the stack) in ThreadBase.  Unlikely...

On 23 Nov 2009, at 05:58, jay.krell at cornell.edu wrote:

> Traced in regs is ok. The question is if they can spill to beyond the part of the stack we scan. Again, imagine if RunThread gets inlined into ThreadBase. That is possible and could easily break us, right?  
> 
>  - Jay (phone)
> 
> On Nov 22, 2009, at 5:04 PM, Tony Hosking <hosking at cs.purdue.edu> wrote:
> 
>> On 22 Nov 2009, at 19:29, Jay K wrote:
>> 
>>> Maybe:
>>>  
>>> RunThread:
>>> if stack_grows_down
>>>   stackbase = ADR(self)
>>> else
>>>  stackbase = ADR(self) + BYTESIZE(self)
>>>  
>>> Do we know the backend won't introduce local temporaries on the stack that contain traced pointers?
>> 
>> We don't know that...
>> In fact, we assume that the backend will have traced pointers in regs.
>> 
>>> Or, like, if there are traced temporaries in registers..they could be spilled to the stack..and not within the bounds
>>> described the above?
>>>  
>>>  - Jay
>>>  
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Mon, 23 Nov 2009 00:19:36 +0000
>>> CC: m3commit at elegosoft.com
>>> Subject: Re: [M3commit] CVS Update: cm3
>>> 
>>> You think I should just leave Win32 using the same method?
>>> No point scanning past that?
>>>  
>>> I think, as I was saying the other day, there is a slight danger in the current code.
>>> Imagine an aggressive optimizer inlines RunThread into ThreadBase.
>>> I think when I manually inlined it I caused just such breakage.
>>>  
>>> We need <*NOINLINE*>?
>>>  
>>>  - Jay
>>>  
>>> Subject: Re: [M3commit] CVS Update: cm3
>>> From: hosking at cs.purdue.edu
>>> Date: Sun, 22 Nov 2009 18:52:31 -0500
>>> CC: jkrell at elego.de; m3commit at elegosoft.com
>>> To: jay.krell at cornell.edu
>>> 
>>> It is precise re traced refs.  That's the lowest frame that can hold a traced reference.
>>> 
>>> On 22 Nov 2009, at 16:53, Jay K wrote:
>>> 
>>> The end of the stack isn't precise:
>>>  
>>> C:\dev2\cm3.release_branch_cm3_5_8\m3-libs\m3core\src\thread\POSIX\ThreadPosix.m3(1058):    self.stackbase := ADR(xx);
>>>  
>>> "stack" here:
>>>  
>>> void
>>> ProcessContext(Context *c, void *stack,
>>>         void (*p) (void *start, void *stop))
>>> {
>>>   if (stack < c->uc.uc_stack.ss_sp)
>>>     p(stack, c->uc.uc_stack.ss_sp);
>>>   else
>>>     p(c->uc.uc_stack.ss_sp, stack);
>>> #ifdef __APPLE__
>>>   p(&(c->uc.uc_mcontext[0]), &(c->uc.uc_mcontext[1]));
>>> #else
>>>   p(&c[0], &c[1]);
>>> #endif
>>> }
>>> 
>>>  - Jay
>>> 
>>>  
>>> > From: hosking at cs.purdue.edu
>>> > Date: Sun, 22 Nov 2009 13:41:26 -0500
>>> > To: jkrell at elego.de
>>> > CC: m3commit at elegosoft.com
>>> > Subject: Re: [M3commit] CVS Update: cm3
>>> > 
>>> > > Note that ThreadPosix.m3 could also implement such precise stackbase.
>>> > 
>>> > ThreadPosix *does* implement a precise stack base. It's obtained from the ucontext set in the thread switch routine (swapcontext).
>>> > 
>>> > > ThreadPThread.m3 probably often could, like with the functions on OpenBSD (broken) and FreeBSD, etc.
>>> > 
>>> 
>>> 
>> 

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