[PATCH] CPU-time clocks

[Corinna Vinschen]

On May 17 04:10, Yaakov (Cygwin/X) wrote:
> On Tue, 2011-05-17 at 07:58 +0200, Corinna Vinschen wrote:
> > Thank you.  You can apply it, but while I was looking into it,
> > this occured to me:
> > 
> > This conversion arithmetic from FILETIME to long long happens a lot
> > in times.cc, even though it's absolutely not necessary.
> > 
> > The FILETIME struct is actually a LARGE_INTEGER in which just the
> > QuadPart member is missing, unfortunately.  What we can do is to
> > replace the bit shifting stuff with a simple cast:
> > 
> >   x = ((PLARGE_INTEGER) &kernel_time)->QuadPart
> >       + ((PLARGE_INTEGER) &user_time)->QuadPart;
> 
> The MSDN docs on FILETIME[1] state:
> 
> > Do not cast a pointer to a FILETIME structure to either a ULARGE_INTEGER*
> > or __int64* value because it can cause alignment faults on 64-bit Windows.
> 
> As I am by no means an expert on Win32 programming, I take that at face
> value.

I don't think that has anything to do with Win32, it's a potential CPU
problem.  Why this should be the case beats me, though.  Maybe 8 byte
values are supposed to be 8 byte aligned on x86_64.  However, in 32 bit
mode it's definitely no problem.  I tested it:

  FILETIME x;
  printf ("&x = %p\n", &x);
  ((LARGE_INTEGER *) &x)->QuadPart = 0x123456789abcdefLL;
  printf ("x = %llx\n", ((LARGE_INTEGER *) &x)->QuadPart);

  ==>

  &x = 0x28ccb4
  x = 123456789abcdef

If that would have been a problem, we should see a core dump.

> > Alternatively we can define kernel_time etc as LARGE_INTEGER and cast in
> > the call to GetProcessTimes or just call NtQueryInformationProcess.
> 
> I have chosen the latter.  Revised patch attached.

Thanks, please apply.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat