[EagleBearerYS]

What

This moves three libkernel_sys stubs into libkernel, the way main places the libkernel_sys functions that libkernel already implements.

• pthread_rwlockattr_settype_np stores types 1 and 2 through its SCE twin scePthreadRwlockattrSettype, and converts the result as the other POSIX rwlock calls do. Any other type, 0 included, and a null attribute or object return EINVAL and store nothing, as BunnyFl measured on firmware 13.42's libkernel. The stored type isn't applied, since scePthreadRwlockInit ignores its attribute, so the debt entry is under Silent stubs.
• scePthreadMutexattrSetkind accepts kinds MutexType::ErrorCheck (1) to MutexType::Adaptive (4) and sets them through scePthreadMutexattrSettype, as FreeBSD 11 libthr's pthread_mutexattr_setkind_np stores the kind as the type. The bounds are the tree's existing MutexType constants. A null or uninitialized attribute returns 0x8001FFFF, sceKernelError(-1), as BunnyFl measured. Other kinds throw through NotImplemented_nid_no_patch: the firmware stores any kind as 16 bits of the type field unchecked, but what a mutex does with such a kind isn't measured.
• scePthreadMutexattrGetkind takes the attribute itself and returns sceKernelError of its kind, 0x80020000 plus the kind, or 0x8001FFFF for a null one, as measured. The firmware returns 0 for kind 0, which no setter here stores, so that case is untested.

Still throwing:

• pthread_mutex_setname_np, pthread_cond_setname_np, pthread_rwlock_setname_np, pthread_barrier_setname_np and sem_setname: a silent stub needs a title that calls them.
• scePthreadMutexIsowned: two conventions are on record, FreeBSD's 1/0 boolean and shadPS4's wrapped 0x80020001.
• scePthreadMain: waits on feat(libkernel_sys): identify the initial pthread #9160's main-thread helper.
• pthread_timedjoin_np and scePthreadTimedjoin: wait on feat(libkernel): implement pthread_timedjoin_np #8890.

Related:

• feat(libkernel): add missing pthread attribute accessors #8373 adds the POSIX pthread_mutexattr_setkind_np/getkind_np and merges cleanly with this PR.
  • Both setkind forms store kinds 1 to 4 as the same MutexType values, and both throw for other kinds.
  • For a null or uninitialized attribute, feat(libkernel): add missing pthread attribute accessors #8373's POSIX form returns -1 with errno EINVAL. The SCE form here returns 0x8001FFFF, as measured.
  • Once feat(libkernel): add missing pthread attribute accessors #8373 lands, scePthreadMutexattrSetkind can keep its attribute check and forward to pthread_mutexattr_setkind_np through PosixThread::ToSce.
• feat(libkernel_sys): implement pthread_set_defaultstacksize_np, scePthreadSetDefaultstacksize and scePthreadSetName #9279 conflicts only where adjacent stubs are deleted from Export.Discovery.cpp.
• feat(libkernel_sys): implement the scePthread scope, atfork and setconcurrency forms #9141 adds GuestKernelSysPthread.cpp, which is why this PR's test file has a separate name.

Tested

• GitHub's Linux and Windows runners (run): guest_kernel_sys_pthread_np_rwlockattr and guest_kernel_sys_pthread_np_kind fail ×2 on both runners with main's stubs and pass ×5 on both.
  • The libkernel suites pass on both.
  • libc's passes on Windows. On Linux it fails precise_wait, a timing test that fails in that run with main's code too.
• Linux (Ubuntu 24.04, gcc 13, CI's configure flags):
  • each test fails with its commit's product files taken from the parent (the stub throws "not implemented"), and passes 10 of 10;
  • the full ctest fails only the three IPv6 tests of that machine;
  • check_test_registration.py and MinGW -fsyntax-only of the changed files are clean.
• fa3cbbe, after harisibrar1's review (run): guest_kernel_sys_pthread_np_rwlockattr gains types 3 and -1, which must throw. With the previous head's Rwlock.cpp it fails on both runners, since both types returned 0; with the change both tests pass 10 runs in a row on both. The libc and libkernel suites pass on Windows (142, 207) and libkernel on Linux (197); libc's timing test precise_wait failed on Linux with and without the change.
• After the merge with main at d6eafa5 (b23cbb5, run): one conflict, in libkernel_sys/Export.Discovery.cpp, where main had removed the pthread_set_defaultstacksize_np discovery stub (now in libkernel_sys/Export.cpp) next to the two stubs this PR removes. The merge keeps all three removals, and this PR's diff against main is unchanged. guest_kernel_sys_pthread_np_rwlockattr, guest_kernel_sys_pthread_np_kind and main's guest_kernel_sys_thread_defaults pass 10 runs in a row on both runners. The libc and libkernel suites pass on Windows (143, 207) and libkernel on Linux (197); libc's precise_wait failed once on Linux.
• e8172f8, after fogydes's review (run): scePthreadMutexattrSetkind's null or uninitialized attribute and its kinds outside 1 to 4 go through NotImplemented_nid_no_patch instead of std::invalid_argument. With the previous head's Mutex.cpp, guest_kernel_sys_pthread_np_kind fails on both runners with the old throw ("Mutex kind 0 is not a mutex type"). With the change both tests pass 10 runs in a row on both. The libc and libkernel suites pass on both (116 and 197 on Linux, 143 and 207 on Windows).
• b801b76, main 3ca07d0 merged in (clean; the PR's own diff is unchanged), on GitHub's runners (run): guest_kernel_sys_pthread_np_kind, guest_kernel_sys_pthread_np_rwlockattr and guest_kernel_sys_thread_defaults pass 10 of 10 on Linux and Windows, none skipped. On its one run with main's implementation, guest_kernel_sys_pthread_np_kind and guest_kernel_sys_pthread_np_rwlockattr fail on both runners and guest_kernel_sys_thread_defaults passes. The libc and libkernel suites pass on both.
• ca39134, BunnyFl's measured cases (comment): the rwlock types, the null attribute in scePthreadMutexattrSetkind and the new scePthreadMutexattrGetkind. Red, the commit's tests on 96c21c0's code (run): on both runners _rwlockattr and _kind fail on exactly the three changed cases (type 0 is stored; the null attribute throws; Getkind is a stub), and guest_kernel_sys_thread_defaults passes. Green (run): the three tests pass 10 runs in a row on Linux and on Windows, none skipped, and the libc and libkernel suites pass on both, run with APS5_SKIP_TIMING_TESTS=1, which relaxes precise_wait's median bounds on GitHub's hosted runners.
• 7b6c3aa, main a145c6a merged in, on GitHub's runners (run). One conflict, in docs/dev/debt/libkernel.md, where main's new sceCoredumpSetUserDataType entry (fix(libkernel): give sceCoredumpSetUserDataType its signature and result #8906) and this PR's pthread_rwlockattr_settype_np entry are added at the same place. The merge keeps both, main's first. The PR's changed lines are the same as before the merge (git diff -U0); only their context in the debt file moved. guest_kernel_sys_pthread_np_kind, guest_kernel_sys_pthread_np_rwlockattr and guest_kernel_sys_thread_defaults pass 10 of 10 on Linux and Windows, none skipped, and the two new tests fail with main's implementation on both. The libc and libkernel suites pass on both. The libc and libkernel suites ran with APS5_SKIP_TIMING_TESTS=1, which relaxes precise_wait's median bounds on GitHub's hosted runners.
• 96c21c0, main 9a030c2 merged in, on GitHub's runners (run). One conflict, in core/libs/CMakeLists.txt, where main's new guest_kernel_sys_module_internal registration and this PR's guest_kernel_sys_pthread_np registrations are added at the same place. The merge keeps both, this PR's first. The PR's other files are unchanged by patch-id, and its changed lines are the same as before the merge; only their context in CMakeLists.txt moved. guest_kernel_sys_pthread_np_kind, guest_kernel_sys_pthread_np_rwlockattr, guest_kernel_sys_thread_defaults and main's guest_kernel_sys_module_internal pass 10 of 10 on Linux and Windows, none skipped, and the two new tests fail with main's implementation on both. The libc and libkernel suites pass on both (117 and 198 on Linux, 144 and 208 on Windows). They ran with APS5_SKIP_TIMING_TESTS=1, which relaxes precise_wait's median bounds on GitHub's hosted runners.
• 3a47ea6, main 50bc72b merged in, on GitHub's runners (run). One conflict, in libkernel_sys/Export.Discovery.cpp, where main had removed the scePthreadResume discovery stub, which it now implements, next to the stubs this PR removes. The merge keeps both removals.
  • The merge also follows main's rule that each export is declared once, in its library's include/Api.hpp. libkernel's Api.hpp declares the three exports with their real signatures, and libkernel_sys's drops its (void) declarations of them. Mutex.cpp takes sceKernelError from libkernel's Api.hpp instead of declaring it, and the test includes the headers instead of its own extern "C" block. The code's behaviour is unchanged.
  • public_headers and the ^guest_kernel_sys tests, 10 runs in a row. Linux: 19 run, 19 pass, 0 skip, 0 fail. Windows: 17 run, 15 pass, 0 skip, 2 fail. This PR's two tests pass on both.
  • The two Windows failures are main's guest_kernel_sys_threads_main and guest_kernel_sys_threads_main_patched, not this PR's tests. In this verify's Windows job they fail with LoadLibraryExW D:/a/AnyPS5/AnyPS5/build/core/libs/libs/unpatched\libkernel_sys.prx failed: 127. main 88f9967, with only a line added that prints that error, fails them the same way there (run). A local Windows build of this merge passes both, built clean and incrementally.
  • Suites: libc and libkernel pass on Linux (144 and 208) and on Windows (171 and 226). The suites ran with APS5_SKIP_TIMING_TESTS=1, which relaxes precise_wait's median bounds on GitHub's hosted runners.
• check_conventions.py passes, with no comment lines added.
• Not tested on a console or with a title.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none. Merge order with orezraey's docs(libkernel): record the text location, unwind info, SoC id and model queries as measured on a PS5 #11253 (adjacent debt entries in docs/dev/debt/libkernel.md): whichever merges second keeps both
• Fixes: none
• Unblocks: none
• GPUs tested: n/a
• AI-assisted: yes

[github-actions]

Progress report (b90d009 → 3a47ea6)

📈 System libraries: 50.1% (+0.01%, +2 implemented, +1 declared, -3 removed functions)

✅ 2 implemented

Library	Name
libkernel	pthread_rwlockattr_settype_np_nid_postfix
libkernel	scePthreadMutexattrGetkind

🆕 1 declared as stubs

Library	Name
libkernel	scePthreadMutexattrSetkind

🗑️ 3 removed

Library	Name
libkernel_sys	pthread_rwlockattr_settype_np_nid_postfix
libkernel_sys	scePthreadMutexattrGetkind
libkernel_sys	scePthreadMutexattrSetkind

Changed libraries (implemented exports)

Library	Before	After	Change
libkernel	683/721 (94.73%)	685/724 (94.61%)	-0.12 pp
libkernel_sys	78/529 (14.74%)	78/526 (14.83%)	+0.08 pp

[harisibrar1]

Checked against main 4a17c71, shadPS4 rwlock.cpp@e0a4667 (L258-289), FreeBSD releng/11.0 thr_mutexattr.c/pthread.h, and ps5-payload-dev/sdk sce_stubs:

• scePthreadMutexattrSetkind looks right to me. Kinds 1..4 map to FreeBSD's ERRORCHECK/RECURSIVE/NORMAL/ADAPTIVE_NP, are stored as the type the way _pthread_mutexattr_setkind_np does it, and actually change locking. Throwing for other kinds and for a null attribute is the conservative choice.
• pthread_rwlockattr_settype_np (Posix/Rwlock.cpp:60) returns 0 for any int, for example settype_np(&attr, 3) or -1. That is because scePthreadRwlockattrSettype stores anything and scePthreadRwlockInit ignores the attribute. The shadPS4 source you cite treats only 0..2 as valid: its gettype_np and settype_np both return POSIX_EINVAL when the stored type is > 2. Since the console result for other values is unknown, could types outside 0..2 throw instead of reporting success?
• The debt entry (libkernel.md:16) says shadPS4 returns EINVAL only for a null or uninitialized attribute, but it also has that type > 2 check. And since 0..2 are stored but never applied, the entry probably belongs under "Silent stubs" rather than "Unknown function info".
• Both names are in ps5-payload-dev/sdk sce_stubs/libkernel.c, so moving them out of libkernel_sys's discovery stubs is supported.

Reviewed with AI assistance (Claude Code); the checks above were run locally on my machine.

[EagleBearerYS]

Thanks, @harisibrar1, agreed on all three. In fa3cbbe:

• pthread_rwlockattr_settype_np stores only types 0 to 2; another type, such as 3 or -1, throws through NotImplemented_nid_no_patch instead of returning 0. The test checks both.
• The debt entry now says what shadPS4's settype_np and gettype_np do: they return EINVAL once the stored type is above 2, and for a null or uninitialized attribute.
• Since types 0 to 2 are stored but never applied, the entry moved to Silent stubs.

On GitHub's runners (run) the extended test fails with the previous head's code and passes 10 runs in a row on Linux and Windows.

[fogydes]

Consistency question; otherwise clean.

scePthreadMutexattrSetkind throws std::invalid_argument for a null/uninitialized attribute and for out-of-range kinds, while its SCE twins in the same file answer the same conditions with SCE_KERNEL_ERROR_EINVAL (scePthreadMutexattrSettype, scePthreadMutexattrSetprotocol). Since the new function delegates the value to Settype anyway, and Settype already redirects every bad input (null attr, unknown value) to EINVAL, the wrappers body could simply be return scePthreadMutexattrSettype(attr, kind); — same observable behavior as far as the siblings go, and no new throw-style the family doesn't share. The debt entry records the throw as unmeasured console behavior, so this is a choice worth an explicit decision rather than an accident.

Verified from the diff and from main: the delegate chain (Setkind → Settype/MutexType), the 1..4-bound match against the MutexType enum and the SCE twin's own switch, and the test's LocksTwice/GUEST_EDEADLK expectations. pthread_rwlockattr_settype_np's throw-on-out-of-range is consistent with the existing scePthreadRwlockattrSettype in src/Rwlock.cpp:177, which the reworked test already covers for the destroyed-attr case.

[EagleBearerYS]

@fogydes thanks for checking the delegate chain. scePthreadMutexattrSetkind doesn't take scePthreadMutexattrSettype's answers for those inputs, because FreeBSD 11 libthr's _pthread_mutexattr_setkind_np, which the debt entry cites, gives neither: it stores an unknown kind unchecked, and for a null attribute it returns -1 with errno EINVAL. The SCE result isn't measured. You're right that std::invalid_argument was a throw style of its own, though. In e8172f8 both cases go through NotImplemented_nid_no_patch, as pthread_rwlockattr_settype_np's unmeasured types do in this PR, and the test expects that (run). If a console measurement shows scePthreadMutexattrSetkind returning SCE_KERNEL_ERROR_EINVAL, it can take that answer.

[MarcZX10]

The current changes address the earlier review findings: rwlock type 3/-1 are no longer silently accepted, the debt entry was corrected and moved under Silent stubs, and mutex attribute invalid inputs now use NotImplemented_nid_no_patch rather than introducing a new std::invalid_argument convention. The body reports focused Windows/Linux failure controls and 10/10 passes on both platforms after the recent changes; the earlier Linux precise_wait failure reproduces on unchanged main. Latest hosted eligibility, conventions and labels checks pass, but product build/test jobs are skipped on this head; the platform run evidence in the body is from the earlier e8172f8078 run and should be refreshed after this push before merge. I did not rerun locally in this environment.

I’ve noticed that holding this PR because of #5239 isn’t necessary. It’s fine for PRs to keep coming in; they’ll be handled in due course. Please disregard my earlier request to hold or defer it.

[EagleBearerYS]

@MarcZX10 run 39750076438 (run) is on e8172f8, the current head, so the Windows and Linux evidence in Tested is for this head. Nothing has been pushed since.

[MarcZX10]

I confirmed the author’s clarification: the focused Windows/Linux runs are on current head e8172f8, so my earlier concern that they were stale was mistaken. I independently ran git diff --check, tools/check_conventions.py against current main, and tools/check_test_registration.py --scripts; all pass (171 scripts registered). The reported focused tests exercise both new entry points and compare against failing stubs; the one Linux precise_wait failure reproduces on unchanged main.

I am withdrawing my earlier #5239 intake hold as a reason to defer this PR. One repository requirement remains: the PR targets d6eafa5, while current main is 15 commits ahead at 8b3a6ba; CONTRIBUTING.md requires a current-main base. The changed pthread and debt files themselves have no intervening main changes, so the rebase appears straightforward. Please update the base before merge and refresh the overlap/conventions check. Hosted product jobs are skipped by path filters; I did not run the full project test suite locally.

[harisibrar1]

Rechecked at e8172f8:

• pthread_rwlockattr_settype_np (Posix/Rwlock.cpp:61) now throws through NotImplemented_nid_no_patch for types outside 0..2, so settype_np(&attr, 3) and -1 no longer report success. The test covers both.
• The debt entry (libkernel.md:8) now records shadPS4's stored-type > 2 EINVAL and sits under Silent stubs. It matches the code: 0..2 are stored but scePthreadRwlockInit ignores them, and a null or uninitialized attribute throws, as scePthreadRwlockattrSettype does.
• Moving scePthreadMutexattrSetkind's bad inputs to NotImplemented_nid_no_patch (Mutex.cpp:142-144) keeps it consistent with the rest of the PR, and its debt entry says so.

Reviewed with AI assistance (Claude Code); the checks above were run locally on my machine.

[EagleBearerYS]

Thanks, @MarcZX10 and @harisibrar1. The branch now has main at 3ca07d0 merged in (b801b76), with the PR's own diff unchanged. On GitHub's runners (run) the three pthread tests pass 10 of 10 on Linux and Windows and fail with main's implementation, and the libc and libkernel suites pass. It's in Tested.

[MarcZX10]

I’ve noticed that my earlier request to hold this PR based on #5239 was unnecessary. It’s fine to keep submitting PRs; maintainers will handle them in due course. Please disregard that request.

[BunnyFl]

I checked both functions against the PS5 firmware 13.42 libkernel and libkernel_sys modules, running each one in an emulator (head 96c21c0). The two modules have the same code for all of them. The console has an answer for each case this PR makes throw.

pthread_rwlockattr_settype_np stores only types 1 and 2 (at offset 4 of the attribute object) and returns 0.

• Every other type returns EINVAL (22) directly and writes nothing, type 0 included. I tried 0, 3, -1 and 0x80000000.
• A null attribute pointer, or one whose object is null, also returns 22.
• scePthreadRwlockattrSettype is the same function, with a non-zero result turned into 0x80020000 + errno. So it gives 0x80020016 for the same inputs.
• So type 0, which this PR stores, is refused. main's scePthreadRwlockattrSettype, which this PR forwards to, stores any type and throws on a null attribute.

scePthreadMutexattrSetkind calls libkernel's pthread_mutexattr_setkind_np.

• That function stores the kind as 16 bits in the attribute's type field, the same field scePthreadMutexattrSettype writes, without checking it, and returns 0. Kinds 0, 5, -1 and 0x12345 all returned 0 (the last stored as 0x2345).
• A null attribute pointer, or one whose object is null, sets errno to 22 and returns -1. The SCE wrapper turns that into 0x8001FFFF.

scePthreadMutexattrGetkind, listed here as still throwing, has a fixed convention too.

• It takes the attribute handle itself, not its address, and reads that 16-bit field. It then converts the result the same way.
• Kind 0 gives 0, and any other kind k gives 0x80020000 + k (kind 1 gives 0x80020001, kind 4 gives 0x80020004).
• A null handle sets errno to 22 and gives 0x8001FFFF.

AI-assisted: yes (Claude Code).

[EagleBearerYS]

@BunnyFl thank you, this caught a real mistake: the PR stored rwlock type 0, which the firmware refuses. ca39134 takes what you measured:

• pthread_rwlockattr_settype_np stores only types 1 and 2. Any other type and a null attribute or object return EINVAL and store nothing.
• scePthreadMutexattrSetkind returns 0x8001FFFF for a null attribute or object.
• scePthreadMutexattrGetkind now exists, with your convention: 0x80020000 plus the kind, or 0x8001FFFF for a null handle.

Kinds outside 1 to 4 still throw in scePthreadMutexattrSetkind: the firmware stores them, but what a mutex does with such a kind isn't measured. Kind 0 in Getkind is untested here, since no setter in the tree stores it. The description and the debt entries credit your comment. scePthreadRwlockattrSettype on main gets the same fix in a separate PR.

[THEMANnt]

Reviewed PR #9632 (head 96c21c0).

Environment: Windows (win32), Python 3.11.9, MinGW64 toolchain.
Checks:

• Baseline, pristine PR, and candidate builds/tests passed (100% for guest_kernel_sys_pthread_np profile).
• Negative control confirmed old stubs failed on baseline head.
• Whitespace and conventions checks passed.

Verification:

• scePthreadMutexattrSetkind and pthread_rwlockattr_settype_np correctly replace stubs.
• Bounds checks and null/destroyed attribute handling verified in source.
• CTest registration and debt documentation updated correctly.

No actionable findings. Local-only tests; no GPU or game execution performed.

[EagleBearerYS]

@MarcZX10 b801b76 merged main 3ca07d0 with the pthread tests 10 of 10 on both runners. Could you re-review?

[EagleBearerYS]

@MarcZX10 this head merges main (96c21c0) and adds ca39134, which takes BunnyFl's firmware measurements of the rwlock types and mutex kinds; its tests fail on the three changed cases with the old code and pass 10 runs in a row on both runners (run). Could you re-review?

Dismissing a stale review: the requested changes were addressed after it (new head) and the merge queue blocks on it. Please request changes again if anything is still open.

[orezraey]

@EagleBearerYS #11253 edits a debt entry next to one this PR changes (PS5 measurements of module and process queries), so git may report a conflict there. Whichever merges second keeps both; I'll rebase #11253 if this one lands first.

[EagleBearerYS]

@orezraey agreed: whichever merges second keeps both entries, and thanks for offering to rebase #11253 if this one lands first. I've recorded that under Depends on here.

[adriadam10]

Checked the rwlock type range (1 and 2 stored, everything else and null EINVAL), scePthreadMutexattrSetkind (1 to 4 through scePthreadMutexattrSettype, other kinds unimplemented, null attribute 0x8001FFFF) and scePthreadMutexattrGetkind against BunnyFl's firmware 13.42 measurements, the removed libkernel_sys stubs, the ctest registration and the debt entries; the new tests pin those values; merged.