Enable process and thread CPU time clocks

Enable process and thread CPU time clocks

The support for these was recently added to the core runtime.

BUG= https://code.google.com/p/nativeclient/issues/detail?id=3629
TEST= trybots
R=mcgrathr@chromium.org

Committed: https://git.chromium.org/gitweb?p=native_client/nacl-glibc.git;a=commit;h=8ec02f0

[Roland McGrath, 2013-08-14 18:40:09]

Need clock_getres too.

Note that we do not really support the general cases (pthread_getcpuclockid) via
the TCB, so now we have CLOCK_THREAD_CPUTIME_ID that behaves completely
differently from pthread_getcpuclockid(pthread_self()).  This merits at least a
comment somewhere.

https://codereview.chromium.org/22802003/diff/1/sysdeps/nacl/clock_gettime.c
File sysdeps/nacl/clock_gettime.c (right):

https://codereview.chromium.org/22802003/diff/1/sysdeps/nacl/clock_gettime.c#...
sysdeps/nacl/clock_gettime.c:23: #define HANDLED_REALTIME
#define HANDLED_CPUTIME

[Petr Hosek, 2013-08-15 21:04:23]

https://codereview.chromium.org/22802003/diff/1/sysdeps/nacl/clock_gettime.c
File sysdeps/nacl/clock_gettime.c (right):

https://codereview.chromium.org/22802003/diff/1/sysdeps/nacl/clock_gettime.c#...
sysdeps/nacl/clock_gettime.c:23: #define HANDLED_REALTIME
On 2013/08/14 18:40:10, Roland McGrath wrote:
> #define HANDLED_CPUTIME

Added.

[Roland McGrath, 2013-08-15 21:18:38]

The code itself LGTM from inspection.
But please say some more about what actual testing you have done or will do for
this.  If there is no test that can distinguish before vs. after this change,
then we don't have adequate coverage.

[Petr Hosek, 2013-08-15 23:30:54]

On 2013/08/15 21:18:38, Roland McGrath wrote:
> The code itself LGTM from inspection.
> But please say some more about what actual testing you have done or will do
for
> this.  If there is no test that can distinguish before vs. after this change,
> then we don't have adequate coverage.

Would it be sufficient to extend the tests/clock tests to cover the new clocks
in the same commit which will update TOOL_REVISIONS? This will test that the
syscalls are present and working both in newlib and glibc; the correctness is
already checked by the TCB tests.

[Roland McGrath, 2013-08-15 23:53:28]

On 2013/08/15 23:30:54, Petr Hosek wrote:
> On 2013/08/15 21:18:38, Roland McGrath wrote:
> > The code itself LGTM from inspection.
> > But please say some more about what actual testing you have done or will do
> for
> > this.  If there is no test that can distinguish before vs. after this
change,
> > then we don't have adequate coverage.
> 
> Would it be sufficient to extend the tests/clock tests to cover the new clocks
> in the same commit which will update TOOL_REVISIONS?

That's generally fine.

> This will test that the
> syscalls are present and working both in newlib and glibc; the correctness is
> already checked by the TCB tests.

Unfortunately the status quo ante in glibc is a libc-internal implementation of
those clocks using rdtsc.
So a test for mere successful return values from the calls would work already.
I'm not sure off hand how you can write a test that won't admit the old glibc
implementation.

[Petr Hosek, 2013-08-17 00:20:14]

On 2013/08/15 23:53:28, Roland McGrath wrote:
> On 2013/08/15 23:30:54, Petr Hosek wrote:
> > On 2013/08/15 21:18:38, Roland McGrath wrote:
> > > The code itself LGTM from inspection.
> > > But please say some more about what actual testing you have done or will
do
> > for
> > > this.  If there is no test that can distinguish before vs. after this
> change,
> > > then we don't have adequate coverage.
> > 
> > Would it be sufficient to extend the tests/clock tests to cover the new
clocks
> > in the same commit which will update TOOL_REVISIONS?
> 
> That's generally fine.
> 
> > This will test that the
> > syscalls are present and working both in newlib and glibc; the correctness
is
> > already checked by the TCB tests.
> 
> Unfortunately the status quo ante in glibc is a libc-internal implementation
of
> those clocks using rdtsc.
> So a test for mere successful return values from the calls would work already.
> I'm not sure off hand how you can write a test that won't admit the old glibc
> implementation.

I have tested the current glibc implementation and clock_gettime/clock_getres is
failing for both process and thread CPU clocks while with this change everything
seems to be working as expected. That ensures that the wiring is functional, I
will
also add a test similar to the one in TCB to test the correctness.

[Petr Hosek, 2013-08-17 19:40:10]

Committed patchset #2 manually as r8ec02f0 (presubmit successful).