gettimeofday seconds rollover problem?

[Chris Johns]

Joel Sherrill wrote:
>
> I agree.  If volatile is sufficient, then I don't want to do anything else.
> 

What audit process are we going to use to know we have 100% kernel 
coverage ?

My understanding is a barrier provides this. I see volatile as having 
possible leaks (which we should fix). To be honest I do not have a clear 
enough picture to forcefully comment further.

FWIW FreeBSD for the i386 port has in src/sys/i386/include/cpufunc.h:

static __inline void
disable_intr(void)
{
	__asm __volatile("cli" : : : "memory");
}

static __inline void
enable_intr(void)
{
	__asm __volatile("sti");
}:

  [ Note, the barrier is only on disable ]

These systems are concerned about SMP issues and here ordering is a 
larger more complex problem.

>
> Can those who have been looking at the generated code try volatile on 
> the list of variables I proposed?
> 

I have played with a barrier, and volatile _Thread_Heir. I tried all 
combinations and the results have 'v' for volatile _Thread_Heir and 'b' 
for the barrier. The result with gcc 4.1.0 for the Coldfire av5282 BSP are:

$ m68k-rtems4.7-size minimum.nxe
    text    data     bss     dec     hex filename
   81072    2480    6832   90384   16110 minimum.nxe
$ m68k-rtems4.7-size minimum-v.nxe
    text    data     bss     dec     hex filename
   81056    2480    6832   90368   16100 minimum-v.nxe
$ m68k-rtems4.7-size minimum-b.nxe
    text    data     bss     dec     hex filename
   81056    2480    6832   90368   16100 minimum-b.nxe
$ m68k-rtems4.7-size minimum-bv.nxe
    text    data     bss     dec     hex filename
   81040    2480    6832   90352   160f0 minimum-bv.nxe

I am now looking to see what code changes. Not an easy diff to do but I 
am making progress. I will also rerun the tests to confirm the results. 
I would like to understand this a little more.

Regards
Chris