This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
Re: [PATCH] CPU-time clocks
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