Problems with registers save/restore on context switch?

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

This started as an investigation into disabling ancient
powerpc-codegen hack in pkgsrc/lang/perl5/hacks.mk to compile perl
optimized.

When testing optimized perl the test dist/threads/t/libc.t that checks
that perl localtime (which translates to localtime_r(3)) is
thread-safe would sometimes fail.

If you try harder you can actually make localtime in single-threaded
perl script to return bogus values.  Perl uses floating point, and is
unwieldy to debug, so just to rule out the impossible I wrote a simple
C program that calls gmtime_r(3) in a loop.  To my surprise it would
sometimes return bogus values too, though you need to try harder.

Attached program converts time_t t = 1; with gmtime_r(3) in a loop and
checks tm_year of the result, expecting 70.  Sometimes (rarely) it
will see bogus results.

The two most frequent bad times are

    2038-01-19T03:14:08 (t =  0x80000000)
and 1901-12-13T20:45:53 (t = -0x7fffffff)

but times from other years also pop up, if extremely rarely.

Generating additional load seems to help triggering the problem.
Something like

  perl -e 'for (1 .. 10000000) {
    @tm = gmtime 1;
    print join(" ", @tm), "\n" if $tm[5] != 70;
  }'

will provide the load and also test perl manifestation of the problem.

The perl part is actually a bit convoluted b/c

1) you might need to compile perl optimized to make the bug happen, I
   haven't tried it with unoptimized perl

2) perl Configure has a bug that causes it to misdetect
   gmtime/localtime domain.

     $ grep GMTIME /usr/pkg/lib/perl5/5.18.0/*netbsd*/Config_heavy.pl

   should show garbage values instead of correct

     sGMTIME_max='67767976233532799'
     sGMTIME_min='-62167219200'

3) b/c of the configure bug perl doesn't actually use system gmtime_r
   and uses its own code instead (I have that bug fixed locally, so my
   perl does use system gmtime_r).

4) even when correct values are returned by gmtime_r or perl own code
   (as verified with instrumenting perl interpreter with a few ad-hoc
   checks), the perl script above gets wrong results, e.g. year is
   something bogus like 4.50360177485421e+15.  That is, the corruption
   happens later and is not gmtime_r specific.

So far all the symptoms make it look as if under some rare
circumstances registers are not saved/restored correctly on context
switch.  (This might also explain why ntpd have warped my system into
2057 a few times recently).

All this is on mac mini g4 with NetBSD 6.1.

I would appreciate if someone can verify this independently to rule
out bad hardware.  If this is reproducible, help in debugging it
further is appreciated.  I don't know much about ppc.

Thanks in advance.

-uwe