gettimeofday seconds rollover problem?

[Chris Johns]

Eric Norum wrote:
> On Feb 23, 2006, at 2:24 PM, Till Straumann wrote:
> 
>> One moment, folks -- I'm not sure the "memory" approach is best
>> for all architectures. On CPUs with many registers, making
>> rtems_interrupt_enable()/disable a real subroutine might be cheaper.
>>

I think for the m68k targets having the calls in lined is still the way 
to go.

>> In any case, I believe that declaring the relevant global variables
>> 'volatile' is the correct way to deal with this problem.
> 
> 
> I agree that  _TOD_Current and _TOD_Seconds_since_epoch should be  
> declared volatile since they are certainly updated by code in a way  
> that is not apparent to the optimizer.

I also agree. I have added RTEMS_VOLATILE to 
sccore/include/rtems/system.h and changed tod.h. Joel, should I commit 
this change ?

> However, I'm concerned that  
> there are other places where code may be unexpectedly hoisted outside  
> an enable/disable pair.   Adding the "memory" seems prudent.

I would like to see the barrier added. I would be concerned we miss a 
place that should be handled that is not.

I also wonder if the compiler can move accesses to a volatile object to 
a place it thinks is ok while still making sure the object access is 
performed. I see we have 2 issues that should be addressed. In the case 
of gettimeofday I tested volatile variables and/or a barrier and the 
same code was generated, how-ever a newer compiler may need both.

> 
> Notice that the compiler is quite happy to use after the enable/ disable 
> the value which was saved in d0 before the enable/disable.   How has 
> adding the "memory" hurt anything?
> 

Do we only need the barrier on the "enable" interrupts ?

> Even if we don't add "memory" to the list of clobbered registers I  
> think that we should add "cc" since the condition codes really do get  
> mangled by the interrupt enable/disable operation.
> 

Yes.

Regards
Chris