gettimeofday seconds rollover problem?

[Joel Sherrill]

Eric Norum wrote:

> What's the current status of this?

Discussion stalled.  Nothing committed AFAIK.

> 1) Have the 'volatile' additions to the _TOD_xxxxx variables been  
> committed?   I think that we all agree that this step is necessary.

I think we do all agree.  Someone noted that any variable accessed and 
potentially modified
between ISR Disable/Enable should also be volatile.  By that logic, we 
have more to add:

_Thread_Heir
_Thread_Do_post_task_switch_extension
_Thread_Dispatch_disable_level
_Priority_Major_bit_map
_Priority_Bit_map
_ISR_Nest_level

I think _Thread_Executing is OK since it only changes as a side-effect 
of a subroutine call.
The contents of many chains change in ISRs so I think the fields in the 
Chain_Node and
Chain_Control structures may need to be marked as volatile.

All of the above is based upon the statement that anything modified by 
an ISR needs
to be volatile.  Those are the most obviously critical items.

> 2) Are the "memory" barriers going to be added to the _ISR_Disable/ 
> Enable/Flash macros?  If so, who's going to make and commit the  
> changes?  If not, are we sure that we are going to have correct code  
> where they're used?  It seems likely that any code protected by  
> _ISR_Disable is going to be acting upon volatile variables but is it  
> reasonable to assume that this will always force the compiler to  
> generate the expected code?


I liked the suggestion that the memory barriers be added to the ISR 
level wrappers not the
CPU specific implementations.

You noted that cc needed to be added to the m68k which has to be CPU 
dependent.

> 3) Are the "memory" barriers going to be added to the  
> _Thread_Dispatch_disable/enable macros?     If so, by whom and why do  
> the arguments against adding the barriers to the interrupt macros not  
> apply here as well?
>
I think the memory barriers need to be added to those macros given the 
argument.  We don't want something
moved outside any critical section so we need to draw our own Maginot 
Line.  I hope ours works well though. :)

> This problem is important enough that it needs to be dealt with quickly.

Yes.  I just don't know that we reached a consensus.   I ended Friday 
with the impression that some volatiles
and memory barriers would resolve the problem.  The cc issue on the m68k 
implementation was orthogonal
to the real problem.

Unless you or Till objects, I would prefer to take the cross-platform 
patches from one of you two.  I know
you two have multiple hardware platforms to test on. 

Any CPU dependent patches to ISR disable/enable code which has been 
identified as a side-effect of this
discussion needs to come from a CPU expert. 

What is the oldest GCC version, this behavior has been observed in?  Can 
we verify that it does or does
not occur in a version prior to that?  I was specifically ask this 
question by a user offline and want to see
what we all know.  They were on a project which locked down an old RTEMS 
version
with a gcc 2.95 variant.

--joel