RTEMS | Tests needed for CLOCK_MONOTONIC (#3889)

[subrata singh (@nonpremiumguy)]

subrata singh commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3889#note_149273


Hello mentors @joel and @gedare,

While writing this test I found a bug in `timer_settime()`:
when `flags == TIMER_ABSTIME`, it unconditionally calls `_TOD_Get()` (`CLOCK_REALTIME`) before fetching the timer object, regardless of the timer's `clock_type`.
This means `TIMER_ABSTIME` with `CLOCK_MONOTONIC` always returns `EINVAL` because monotonic uptime (seconds since boot)
is always less than wall clock time (Unix epoch). `_Timespec_Greater_than( &now, &normalize.it_value )` always evaluates to true.
I verified this by running the test on the ERC32 simulator.
I have commented out the remaining time check with a `TODO` and set the `.scn` file to expect this `EINVAL` failure for now so the test completes cleanly.
To fix this in `timersettime.c`, the absolute to relative conversion block needs to be moved down inside the section (after `ptimer = _POSIX_Timer_Get(...)`) 
so we can check `ptimer->clock_type`. Then we can fetch the correct time (e.g., `_Timecounter_Nanouptime`).

Current - clock_type unknown here, always uses `_TOD_Get()`

```c
if ( flags == TIMER_ABSTIME ) {
    _TOD_Get( &now );  // wrong for CLOCK_MONOTONIC
    //subtract...
}
ptimer = _POSIX_Timer_Get( timerid, &lock_context );  // late
```
The fix: move the conversion block to after _POSIX_Timer_Get()
so ptimer->clock_type is available.
```c
ptimer = _POSIX_Timer_Get( timerid, &lock_context );
if ( ptimer != NULL ) {
    if ( flags == TIMER_ABSTIME ) {
        if ( ptimer->clock_type == CLOCK_MONOTONIC )
            _Timecounter_Nanouptime( &now );
        else
            _TOD_Get( &now );
        //subtract
    }
}
```
I can try to submit a patch for `timersettime.c` if this is confirmed as unintended behavior.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3889#note_149273
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260430/71ef151c/attachment.htm>