[Bug fortran/53456] Add time support for VxWorks

["burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53456

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |UNCONFIRMED
     Ever Confirmed|1                           |0

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-05-23 15:36:26 UTC ---
(In reply to comment #4)
> VxWorks does not provide the process time in most versions and for most
> cases. In fact, many VxWorks applications are not processes in the
> traditional sense but instead tasks/threads spawned by the kernel in kernel
> space.

That's not different to, e.g., RTEMS which only allows for a single process but
multiple threads.


> If returning an error is the preferred behavior for gf_cputime, then the code
> as is should work.

I think returning "-1" is a sensible choice as the information is not
available.

An alternative would be: clock_gettime with CLOCK_MONOTONIC - but the starting
point is not defined; in case of VxWorks it seems to be the elapsed since
system startup, which would be a reasonable choice. However, POSIX allows other
choices, for instance since the (Unix) epoch.  [Plus CLOCK_MONOTONIC seems to
be valid only in VxWorks 6.x but not in 5.x]

(Another choice - available in 5.x - would be to use tickGet(), but that can be
reset via tickSet and has probably some other issues.)

Thus, instead of creating a special case for VxWorks, relying on 0 == start up
time, and papering over the difference between kernel startup vs. program
startup, returning -1 seems to be best.


Note: Fortran provides SYSTEM_CLOCK which - with libgfortran - calls
clock_gettime (using CLOCK_MONOTONIC if available and CLOCK_REALTIME if not) -
or as fall back, it calls gf_gettime (which calls gettimeofday, clock_gettime
w/ CLOCK_REALTIME, or time().)