[p3n1cillin]

What

VLC for PS5 (PPSA85300, catalog build) fails to load on current main (bb9a4d8a2), now that readdir_r (#3635) is in:

FAIL: unresolved ELF import sZuwaDPATKs from libkernel.prx

sZuwaDPATKs is getdtablesize. This is the half of #4386 that was dropped from it; @oneandonlydean said there that it "can go in after #3635, since PPSA85300 stops at sZuwaDPATKs once readdir_r is in".

The export throws (NotImplemented_nid_no_patch). FreeBSD returns the smaller of the RLIMIT_NOFILE soft limit and maxfilesperproc (sys_getdtablesize). Neither value is known for the console, and AnyPS5's getrlimit(RLIMIT_NOFILE) already throws for the same reason. VLC's only caller is a closefrom loop (libc_stubs.c#L66-L72). As @AchrafReyani traced in #4386, it runs only in the child of a spawn helper whose fork fails with ENOSYS, so the call is never made. Recorded under Unknown function info in docs/dev/debt/libkernel.md.

Tested

• VLC PPSA85300 on Windows 11 (MinGW GCC 15.2.0), relinked from the catalog release: before, the load fails as above. After, it loads, opens /app0/vlc-ps5.log and writes its load address marker. It then faults in report_unresolved_imports() (platform_ps5.c), which reads its own GOT slots at the console's fixed load address (EBOOT_BASE 0x400000) instead of the image's. That is a load-address assumption of the title, not a library call.
• guest_getrlimit now also requires getdtablesize to throw. All 124 libkernel tests pass on Windows; Linux was not built locally.
• python tools/check_conventions.py --base origin/main passes.

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
• Unblocks: VLC for PS5 (PPSA85300) load; part of libkernel: pthread_atfork, mlockall and getdtablesize are absent (XPSemu, VLC); branch ready #3628
• AI-assisted: yes

🤖 Generated with Claude Code

[github-actions]

Progress report (75690a1 → c580053)

📉 System libraries: 88.19% (-0.03%, +1 declared functions)

🆕 1 declared as stubs

Library	Name
libkernel	getdtablesize_nid_postfix

[coltken95]

Linux validation (Ubuntu 24.04, GCC 13.3, Release), this PR's commit on main at 77b9f72: guest_getrlimit passes. With main's sources and this PR's test, the test does not link (getdtablesize is not exported), so it covers the new export.

AI-assisted: yes

[p3n1cillin]

Linux run of this change: Ubuntu in WSL2, GCC 15.2.0, Ninja Release, BUILD_TESTING=ON, full build. Built from a local integration head a14a49d8d, which is main 5d50886ee with this PR and my other open library PRs merged (#5013, #5009, #5061, #5078, #5098; no conflicts). All 121 libkernel tests and all 68 libc tests pass, including guest_system_configuration, guest_getrlimit and guest_select. Not run alone on Linux; no title run on Linux.

[babyhuey]

XPSemu (PPSA97358, catalog release) now stops here on main: since #4377 merged, main 18c438b stops it at the unresolved import sZuwaDPATKs (getdtablesize), on Linux (Ubuntu 24.04, GCC 13, Release, headless). With this PR (8fce4b8, clean merge) every import resolves, and guest_getrlimit passes.

Its later stops, with this PR merged locally, for whoever picks them up:

1. Without a fixed base it faults on its GOT read at 0x400000 + offset (Ruffle, VLC and XPSemu read their GOT at a fixed 0x400000 base from app0/imports.txt and fault once all imports load #4013), as described in feat(relinker): load Linux executables at a fixed base #4593.
2. Relinked with feat(relinker): load Linux executables at a fixed base #4593's --linux-fixed-base 0x400000, it stops at getrlimit: unsupported resource 8 (RLIMIT_NOFILE), which is feat(libkernel): report RLIMIT_NOFILE through getrlimit #5187.
3. With feat(libkernel): report RLIMIT_NOFILE through getrlimit #5187 too, xemu starts. It loads its BIOS files and builds shaders, then fails a GPU check in its own geometry-shader probe: radv/ps5: the GPU has not reached submission 2 (at 1) in 10 s, vk_result = -4, assertion in hw/xbox/nv2a/pgraph/vk/gpuprops.c:456 (render_geom_shader_triangles). That run was headless, so it may differ with a display.

[LeandroLP23]

Windows/AMD title runs for both titles that stop here. Setup: Windows 11 (26300), Radeon 860M, WinLibs GCC 15.2.0, Release. Head 8fce4b843 merged onto current main 665ad7da7, catalog builds, 2 runs of 40 s each.

Conflict: since #4374 merged, this branch conflicts with main in core/libs/prx/libkernel/System/src/Process.cpp. getpriority_nid_postfix and getdtablesize_nid_postfix are added at the same place. For these runs I kept both functions; nothing else conflicted.

Title	main	main + this PR
XPSemu (PPSA97358 Alpha-2.1)	FAIL: unresolved ELF import sZuwaDPATKs from libkernel.prx, exit 0xc0000139	Loads, then 2 of 2 runs fault 3 s in: read of 0x000000000339c6e0 at PPSA97358.exe+0xc88d9f
VLC (PPSA85300 0.4)	Same unresolved import	Loads, then 2 of 2 runs fault 3 s in: read of 0x0000000003a2b2c8 at PPSA85300.exe+0xf94c4

Both faults read a small address, a GOT offset plus the console's fixed 0x400000 base. That is the #4013 load-address assumption the description names, now reached by XPSemu as well. Neither title reached the getdtablesize throw in these runs.

guest_getrlimit passes.

AI-assisted: yes (Claude Code)

[p3n1cillin]

Rebased onto main c7601b797 (head 9be93156b). The Process.cpp conflict with #4374 is resolved by keeping both getpriority and getdtablesize, as @LeandroLP23 did, and nothing else changed. On Windows (MinGW GCC 15, Release) it builds, all 128 libkernel tests pass, and the conventions check passes. Thanks for the AMD runs: the later XPSemu and VLC faults are the #4013 fixed-base assumption, which --windows-fixed-base 0x400000 (#4140) avoids.

[MarcZX10]

One convention point on getdtablesize_nid_postfix: this export is intentionally unimplemented, so CONTRIBUTING.md asks it to call NotImplemented_nid_no_patch(__func__). The current custom string is descriptive, but the function name should come from __func__; the debt entry can keep the explanation about the unknown console descriptor limit.

[MarcZX10]

The overlap notice with #5545 is an adjacent edit in Process.cpp: #5061 adds getdtablesize, while #5545 adds setpriority. They have no semantic dependency, but whichever lands second may need to rebase the neighboring additions. Both PRs remain open.

[oneandonlydean]

Pushed one commit switching the throw to NotImplemented_nid_no_patch(__func__), as asked above. Merging once the full build is green.