[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
gettimeofday seconds rollover problem?
- Date: Thu, 23 Feb 2006 06:25:31 -0600
- From: joel.sherrill at oarcorp.com (Joel Sherrill)
- Subject: gettimeofday seconds rollover problem?
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?
>>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"
>>therefore the usual way to block a short critical section
>>does not work
>>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*
>>(even when they are not volatile), and therefore GCC would be
>>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
>>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
>/* Optimization barrier */
>/* The "volatile" is due to gcc bugs */
>#define barrier() __asm__ __volatile__("": : :"memory")
>I hope, this helps.
Is this just a gcc 3.x issue or is it an issue with newer compilers.
>LOYTEC electronics GmbH