gettimeofday seconds rollover problem?
joel.sherrill at oarcorp.com
Thu Feb 23 12:24:51 UTC 2006
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.
Please give me some feedback on what works. Unfortunately, this is going to
have to be worked into EVERY port on at least interrupt
What other inline asm's could it impact?
This looks like a forcing factor for a new 4.6 release. :(
>LOYTEC electronics GmbH
More information about the users