[xecedemon]

What

Reverts sceNetResolverConnectCreate, sceNetResolverConnect, sceNetResolverConnectAbort and sceNetResolverConnectDestroy to NotImplemented_nid_no_patch stubs. Firmware 13.42's libSceNet.sprx implements the family (before sceNetInit it returns 0x804101C8 with errno 200; Create under the library lock rejects non-zero flags or a null connection with 0x80410116 and otherwise fills the caller's 0x1f0-byte block, name lookups at +0x1c4/+0x1c0; Destroy shares the init check; Connect and Abort match in size and prologue, bodies untraced), so per the repo rule the exports keep throwing until that behaviour is implemented rather than inventing an unsupported result. shadPS4's RESOLVER_ENOSUPPORT is a PS4 stub, not evidence for the PS5 module. core/libs/tests/GuestNetResolverConnect.cpp becomes a pin test asserting each of the four reports not implemented, before sceNetInit and after it, and the resolver-connect debt entry in docs/dev/debt/libSceNet.md records the disassembly facts.

Tested

Linux; cmake --build build --target libSceNet guest_net_resolver_connect_tests; ctest --test-dir build -R net green (43/43, including the rewritten guest_net_resolver_connect pin test); python3 tools/check_conventions.py --base origin/main passes. Not tested on a console.

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
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• Fixes: none
• Unblocks: none
• GPUs tested: n/a
• AI-assisted: yes

[github-actions]

Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.

Pull request	Shared files not compared
PR 5836	core/libs/prx/libSceNet/CMakeLists.txt core/libs/prx/libSceNet/Export.cpp docs/dev/debt/libSceNet.md
PR 9948	core/libs/prx/libSceNet/Export.cpp docs/dev/debt/libSceNet.md
PR 12104	docs/dev/debt/libSceNet.md
PR 12682	core/libs/prx/libSceNet/Export.cpp
PR 12683	core/libs/prx/libSceNet/Export.cpp docs/dev/debt/libSceNet.md
PR 12688	core/libs/prx/libSceNet/Export.cpp
PR 12700	core/libs/prx/libSceNet/Export.cpp
PR 12918	core/libs/prx/libSceNet/Export.cpp docs/dev/debt/libSceNet.md
PR 12965	core/libs/prx/libSceNet/Export.cpp
PR 14212	docs/dev/debt/libSceNet.md
PR 14213	core/libs/prx/libSceNet/CMakeLists.txt core/libs/prx/libSceNet/Export.cpp docs/dev/debt/libSceNet.md
PR 14310	core/libs/prx/libSceNet/CMakeLists.txt core/libs/prx/libSceNet/Export.cpp

[BunnyFl]

The PS5 module implements these four functions, so RESOLVER_ENOSUPPORT for every input is behaviour the console doesn't have.

Firmware 13.42's libSceNet.sprx (sha256 3d30fe383092f56a7ffb9d6fc9573f534348c74f26ed6b5e6c1ae26c5679a77d), read from disassembly only, not measured on a console:

0x3c10 sceNetResolverConnectCreate (V5q6gvEJpw4)
  3c1e: cmpl [0x440a0], 0 ; je 3c7c        ; 3c7c: *errno = 200 ; return 0x804101c8 (not initialised)
  3c69: call 0xd010(name, ?, connection, flags) under the library lock
  3c8e: on a negative result, errno = low byte of an 0x8041_01xx code, else 205
0xd010 (create body)
  d010: flags != 0 || connection == NULL -> 0x80410116 (EINVAL)
  d039..d0ab: clears 0x1f0 bytes of *connection
  d0bc: call 0x74c0(name, 0x1c, ...) ; stores the result at connection+0x1c4
  d0dc: call 0x74c0(name, 2, ...)    ; stores the result at connection+0x1c0
  d0fd: call 0x9fb0(name, 0x1000, 0) ...
0x3eb0 sceNetResolverConnectDestroy (QFPjG6rqeZg)
  same init check (0x804101c8, errno 200), then call 0xd780(connection) under the lock

sceNetResolverConnect (0x3cf0) and sceNetResolverConnectAbort (0x3de0) have the same size and prologue shape. I didn't trace their bodies.

1. Before sceNetInit and after sceNetTerm, the console returns 0x804101C8 with errno 200, not 0x804101E3. The test pins ENOSUPPORT in both states.
2. After init, Create rejects non-zero flags or a null connection with 0x80410116, and otherwise fills the caller's 0x1f0-byte block and opens resources. So "writes nothing for every input" and the 0x80000000/1 flag cases don't match either.
3. The shadPS4 position is a PS4 stub, not evidence for the PS5 module. Since the module does real work here, the repo rule is to keep throwing NotImplemented_nid_no_patch until it's implemented, rather than inventing an unsupported result. The debt entry could record the facts above instead: the init check, the flags/null check, and the 0x1f0-byte block.

The other new debt entries for the remaining pending exports don't conflict with this. I haven't checked their individual claims against the module.

[oneandonlydean]

Hi xecedemon,

Thanks for working through the libSceNet backlog; the new debt entries are a real help.

One point blocks this one, reviewed at 638cf21:

sceNetResolverConnectAbort, sceNetResolverConnectCreate, sceNetResolverConnect and sceNetResolverConnectDestroy now return RESOLVER_ENOSUPPORT for every input (core/libs/prx/libSceNet/Export.cpp lines 2703-2717). The console does support these calls, so this is an answer the console would not give. The contributing rule is "Every function either does exactly what it is supposed to or throws", and the agent rule says an export you cannot implement calls NotImplemented_nid_no_patch(__func__). The shadPS4 stub you cite is a PS4 emulator's own choice ("Not implemented. Fail rather than report success"), not console behaviour, so it does not carry over as a source.

Could you keep the four exports on NotImplemented_nid_no_patch(__func__), drop GuestNetResolverConnect.cpp and its CMake block (it would only pin the made-up error), and keep the resolver-connect debt entry (docs/dev/debt/libSceNet.md line 105) as a description of what is unknown? The other new debt entries look good as they are.

Small one while you're there: the shadPS4 links use blob/main, so the line numbers will drift. Pinning them to a commit (for example d4ea43b9ff7369365a2dcf9b15315c65aeb7f6f9, where the resolver-connect stubs are lines 2070-2093) keeps them stable.

[maskym]

Windows result for head 638cf21dbe, merged alone into main a4eca2a056 (the PR's Tested section names no Windows run).

Host: Windows 11 26300, Intel i7-12700K, WinLibs GCC 15.2.0 (x86_64-ucrt-posix-seh, r6), Release, BUILD_TESTING=ON, Ninja. Build clean.

guest_net_resolver_connect, the test this PR adds or extends, passes 3 of 3 runs. Not run on a PS5.

AI-assisted: yes (Claude Code), the runs and the numbers above are from this machine.

[xecedemon]

Agreed on all three points, and thanks for tracing the bodies — the reading is decisive. The module clearly does real work here (the init check, the flags/null rejection with 0x80410116, the 0x1f0-byte fill), so per the repo rule the four exports are back to NotImplemented_nid_no_patch stubs and the RESOLVER_ENOSUPPORT constant is gone; Export.cpp is now byte-identical to main. The test no longer pins any error value or storage behaviour — it pins that each of the four reports not implemented, before sceNetInit and after it. The debt entry records exactly the facts you listed (init check → 0x804101C8 errno 200; Create's flags/null check and the 0x1f0-byte block with name lookups at +0x1c4/+0x1c0; Destroy sharing the init check; Connect/Abort matching in size and prologue, bodies untraced) with provenance to your reading, and notes shadPS4's position is a PS4 stub rather than PS5 evidence. The full net suite (43 tests) is green and the conventions check passes.

[maskym]

Windows result for head 90d0372c91, merged alone into main 086c0686c8 (the PR's Tested section names no Windows run).

Host: Windows 11 26300, Intel i7-12700K, WinLibs GCC 15.2.0 (x86_64-ucrt-posix-seh, r6), Release, BUILD_TESTING=ON, Ninja. Build clean.

guest_net_resolver_connect, the test this PR adds or extends, passes 3 of 3 runs. Not run on a PS5.

AI-assisted: yes (Claude Code), the runs and the numbers above are from this machine.