libs/newlib-cygwin
libs
/
newlib-cygwin
mirror of git://sourceware.org/git/newlib-cygwin.git
4
0
Fork 0
Code Issues Projects Releases Wiki Activity
newlib-cygwin/libgloss/riscv/sys_times.c

43 lines
1.2 KiB
C
Raw Permalink Normal View History

RISC-V: Moved syscalls to separate files to fix aliasing problems.
2017-12-27 04:27:52 +08:00
#include <machine/syscall.h>
#include <sys/types.h>
#include <sys/times.h>
#include <sys/time.h>
#include "internal_syscall.h"
extern int _gettimeofday(struct timeval *, void *);
/* Timing information for current process. From
newlib/libc/include/sys/times.h the tms struct fields are as follows:
- clock_t tms_utime : user clock ticks
- clock_t tms_stime : system clock ticks
- clock_t tms_cutime : children's user clock ticks
- clock_t tms_cstime : children's system clock ticks
Since maven does not currently support processes we set both of the
children's times to zero. Eventually we might want to separately
account for user vs system time, but for now we just return the total
number of cycles since starting the program. */
clock_t
_times(struct tms *buf)
{
RISC-V: Reliably initialize t0 in _times() The current implementation does not reliably initialize t0 once. Additionally the initialization requires two calls to _gettimeofday(). Let's sacrifice a byte to keep the initialization status and reduce the maximum number of calls to _gettimeofday(). This has caused issues in an application that invokes clock(). The problematic situation is as follows: 1) The program calls clock() which calls _times(). 2) _gettimeofday(&t0, 0) puts 0 in t0.tv_usec (because less than 1 us has elapsed since the beginning of time). 3) _gettimeofday(&t, 0) puts 1 in t.tv_usec (since now more than 1 us has elapsed since the beginning of time). 4) That call to clock() returns 1 (the value from step 3 minus the value in step 2). 5) The program does a second call to clock(). 6) The code above still sees 0 in t0 so it tries to update t0 again and _gettimeofday(&t0, 0) puts 1 in t0.tv_usec. 7) The _gettimeofday(&t, 0) puts 1 in t.tv_usec (since less than 1us has elapsed since step 3). 8) clock() returns 0 (step 7 minus step 6) and indicates that time is moving backwards. Signed-off-by: Christoph Muellner <cmuellner@gcc.gnu.org>
2021-08-03 00:46:16 +08:00
static char initialized;
RISC-V: Moved syscalls to separate files to fix aliasing problems.
2017-12-27 04:27:52 +08:00
static struct timeval t0;
struct timeval t;
RISC-V: Reliably initialize t0 in _times() The current implementation does not reliably initialize t0 once. Additionally the initialization requires two calls to _gettimeofday(). Let's sacrifice a byte to keep the initialization status and reduce the maximum number of calls to _gettimeofday(). This has caused issues in an application that invokes clock(). The problematic situation is as follows: 1) The program calls clock() which calls _times(). 2) _gettimeofday(&t0, 0) puts 0 in t0.tv_usec (because less than 1 us has elapsed since the beginning of time). 3) _gettimeofday(&t, 0) puts 1 in t.tv_usec (since now more than 1 us has elapsed since the beginning of time). 4) That call to clock() returns 1 (the value from step 3 minus the value in step 2). 5) The program does a second call to clock(). 6) The code above still sees 0 in t0 so it tries to update t0 again and _gettimeofday(&t0, 0) puts 1 in t0.tv_usec. 7) The _gettimeofday(&t, 0) puts 1 in t.tv_usec (since less than 1us has elapsed since step 3). 8) clock() returns 0 (step 7 minus step 6) and indicates that time is moving backwards. Signed-off-by: Christoph Muellner <cmuellner@gcc.gnu.org>
2021-08-03 00:46:16 +08:00
RISC-V: Moved syscalls to separate files to fix aliasing problems.
2017-12-27 04:27:52 +08:00
_gettimeofday (&t, 0);
RISC-V: Reliably initialize t0 in _times() The current implementation does not reliably initialize t0 once. Additionally the initialization requires two calls to _gettimeofday(). Let's sacrifice a byte to keep the initialization status and reduce the maximum number of calls to _gettimeofday(). This has caused issues in an application that invokes clock(). The problematic situation is as follows: 1) The program calls clock() which calls _times(). 2) _gettimeofday(&t0, 0) puts 0 in t0.tv_usec (because less than 1 us has elapsed since the beginning of time). 3) _gettimeofday(&t, 0) puts 1 in t.tv_usec (since now more than 1 us has elapsed since the beginning of time). 4) That call to clock() returns 1 (the value from step 3 minus the value in step 2). 5) The program does a second call to clock(). 6) The code above still sees 0 in t0 so it tries to update t0 again and _gettimeofday(&t0, 0) puts 1 in t0.tv_usec. 7) The _gettimeofday(&t, 0) puts 1 in t.tv_usec (since less than 1us has elapsed since step 3). 8) clock() returns 0 (step 7 minus step 6) and indicates that time is moving backwards. Signed-off-by: Christoph Muellner <cmuellner@gcc.gnu.org>
2021-08-03 00:46:16 +08:00
// when called for the first time, initialize t0
if (!initialized) {
t0.tv_sec = t.tv_sec;
t0.tv_usec = t.tv_usec;
initialized = 1;
}
RISC-V: Moved syscalls to separate files to fix aliasing problems.
2017-12-27 04:27:52 +08:00
long long utime = (t.tv_sec - t0.tv_sec) * 1000000 + (t.tv_usec - t0.tv_usec);
buf->tms_utime = utime * CLOCKS_PER_SEC / 1000000;
buf->tms_stime = buf->tms_cstime = buf->tms_cutime = 0;
RISC-V: Fixed return code in _times syscall. Upon successful completion, times() shall return the elapsed real time, in clock ticks, since an arbitrary point in the past (for example, system start-up time). Signed-off-by: Kito Cheng <kito.cheng@gmail.com>
2018-07-06 17:03:15 +08:00
return buf->tms_utime;
RISC-V: Moved syscalls to separate files to fix aliasing problems.
2017-12-27 04:27:52 +08:00
}