Skip to content

libkernel: setitimer is absent (PS5MC); branch ready on the alarm timer, never reporting an undelivered signal #3735

Closed

Description

@screamm

libkernel does not export setitimer (NID hPWDGx8ioXQ). PS5MC (PPSA99420) imports it (registry index 472, predicted FAIL: unresolved ELF import hPWDGx8ioXQ from libkernel.prx). The earlier #3293 was closed for reporting success without delivering the signal; this branch never does that.

Branch ready: screamm:feat/libkernel-setitimer (6bef7bf0, one commit on main a11c8f7f). I cannot open it as a PR because of the intake check; anyone eligible is welcome to carry it, keeping the commit as is. getitimer is left to the open #3572; whichever merges second must read the interval this branch stores (alarms.interval), since #3572 reports it as always 0.

  • Built on the existing alarm timer thread, following FreeBSD 11.4 sys/kern/kern_time.c (sys_setitimer, kern_setitimer, realitexpire, itimerfix) and lib/libc/gen/alarm.c (8c639945): EINVAL for an unknown timer or a value/interval with a negative field, tv_usec >= 1000000 or more than INT32_MAX/2 seconds; a null value reads the timer (EFAULT when the output is null too, after the timer check as FreeBSD orders it); a zero value disarms and returns the previous remaining time and interval; a non-zero value arms, re-armed by it_interval on expiry; alarm now clears the interval as FreeBSD's does.
  • What throws, with the reason named: expiry with a guest SIGALRM handler installed (no path runs a guest handler here; alarm already throws the same way), expiry while SIGALRM is blocked (pending signals are not modelled; this also corrects alarm, which wrongly exited in that case), an interval below 1 ms (FreeBSD rounds to tick/16 and the console's hz is unknown), and arming ITIMER_VIRTUAL/ITIMER_PROF (CPU-time accounting is not modelled; reading or disarming them is exact at zero). SIG_IGN drops the expiry and the default disposition exits with 142, as before.
  • New guest_itimer (about 1 s) covers the error cases with the output untouched, disarm returning the previous value, the countdown, re-arm by interval, the CPU timers, the alarm interplay and the throw message at expiry (it_interval 0.250000 s) with the handler never running.

Tested on Windows 11 Pro 26220, WinLibs MinGW-w64 GCC 15.2.0 r7, Ninja, Release, BUILD_TESTING=ON, full build including libs: guest_itimer and guest_signals 3/3 (guest_itimer 10/10 in the worktree); ctest -j8 -E "^agc_driver_|^video_out_flip" 534/537, the failures being the known windows_exceptions (#3411, fixed by #3415), guest_kernel_sys (#3510) and guest_filesystem (#3518); with main'

Activity

  1. ArekatlaNishanthchowdary commented on Oct 11, 2026

    @ArekatlaNishanthchowdary
    Contributor

    Windows verification of screamm:feat/libkernel-setitimer (6bef7bf0b), cherry-picked unchanged onto main a11c8f7f7 as ArekatlaNishanthchowdary:feat/libkernel-setitimer (5d21483ae), authorship kept.

    Windows 11 Pro 26200, WinLibs GCC 15.2.0 r7, Release:

    AI-assisted: yes (Claude Code).

  2. MarcZX10 commented on Oct 12, 2026

    @MarcZX10
    Contributor

    I carried the offered setitimer implementation into PR #4382, preserving the source commit author. I integrated it with current main’s existing getitimer and alarm timer state. Linux Release GCC 12.2 builds of guest_itimer_tests and guest_signal_tests passed; both focused CTests passed 1/1, and conventions/diff checks passed. The PR leaves getitimer as implemented on main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions