gettimeofday seconds rollover problem?

[Joel Sherrill]

Thomas Rauscher wrote:

>>From: Thomas Doerfler [mailto:Thomas.Doerfler at imd-systems.de] 
>>Sent: Thursday, February 23, 2006 10:11 AM
>>To: Andrew Sinclair
>>Cc: rtems-users; Chris Johns; Joel Sherrill; Ian Caddy
>>Subject: Re: gettimeofday seconds rollover problem?
>>
>>Hi,
>>
>>wow, we really got a problem here. According to Andrews 
>>quoting, GCC can 
>>move around "rtems_disable_interrupt" and "rtems_enable_interrupt" in 
>>the current implementation (a macro that contains "volatile" 
>>asm), and 
>>therefore the usual way to block a short critical section 
>>does not work 
>>reliable.
>>
>>Even making the _TOD* vairables volatile (which should be 
>>done anyway, I 
>>think), will not fix this problem, because their usage might still be 
>>moved out of the irq-disabled section.
>>
>>One solution might be to reimplement rtems_dis/enable_interrupt as a 
>>(non-inline) function. Then GCC will have no idea what is going on in 
>>these functions, they might even change e.g. the global _TOD* 
>>variables 
>>(even when they are not volatile), and therefore GCC would be 
>>forced to 
>>read these variables exactly at the location specified in source code.
>>
>>The advantage of this solution would be, that ALL critical sections 
>>useing rtems_dis/enable_interrupt would be save again. The 
>>disadvantage 
>>would be, that these statements will be executed slower due to the 
>>subroutine call and the register save/restore operations needed.
>>
>>Any comments on my sugestion?
>>    
>>
>
>The following macro is used in the Linux kernel. It tells the
>compiler that the asm statement globbers memory in an
>unpredictable way. The compiler cannot schedule instructions
>over this barrier and has to forget all memory values kept in 
>registers.
>
>/* Optimization barrier */
>/* The "volatile" is due to gcc bugs */
>#define barrier() __asm__ __volatile__("": : :"memory")
>
>I hope, this helps.
>
>  
>
Please give me some feedback on what works.  Unfortunately, this is going to
have to be worked into EVERY port on at least interrupt 
disable/enable/flash.

What other inline asm's could it impact?

This looks like a forcing factor for a new 4.6 release. :(

>Regards,
>Thomas Rauscher
>
>--
>Thomas Rauscher
>LOYTEC electronics GmbH
>
>  
>