gettimeofday seconds rollover problem?

[Thomas Rauscher]

> 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.

Regards,
Thomas Rauscher

--
Thomas Rauscher
LOYTEC electronics GmbH