[MarcZX10]

What

Adds the missing execve export as an explicit unsupported-operation throw, matching execvp while process-image replacement is not modeled. This removes the unverified argument and path checks and does not change execv.

guest_execvp retains its execvp checks and verifies that execve throws. The debt entry records that console behavior for argument and path errors is unknown. No title unblock is claimed.

Tested

Linux x86-64, GCC 12.2.0, CMake/Ninja Release:

• Built guest_execvp_tests.
• CTest guest_execvp passed (1/1).
• tools/check_conventions.py --base upstream/main passed.
• Test-registration checks passed (18/18), and git diff --check passed.
• Open-PR overlap scan found no other implementation of execve; the only matching export was this PR.

Not tested on Windows, a console, or a title.

Checklist

• Based on current main; no other open PR implements the same function
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw; no silent stubs added
• No investigation notes or images added to the repository
• No third-party code added
• Generic behavior, not title-specific
• Depends on: none
• Unblocks: none confirmed
• AI-assisted: yes

[github-actions]

Progress report (a252fcd → cdf4b17)

📉 System libraries: 87.98% (-0.02%, +1 declared functions)

🆕 1 declared as stubs

Library	Name
libkernel	execve_nid_postfix

[MarcZX10]

Local Linux validation is complete: GCC 12.2.0 Release/Ninja built guest_execvp_tests, and CTest guest_execvp passed 1/1. The conventions check and git diff --check also pass on current main. GitHub eligibility and intake checks pass; the remaining CI jobs are pending.

[oneandonlydean]

Does PPSA97358 stop on the execve import on main? #3558 calls it a predicted stop, not one seen in a run; please quote the line. If it does, a throwing execve like execvp on main is enough: no title reaches the checks in executableError (its fork returns ENOSYS), so please drop them and leave execv as it is.

[xXPBSXx]

Windows test of head 6f50566f4 merged onto current main (fa0cc752a, clean merge; built together with four other open PRs, so the run is for the combination): Windows 10 (19045), MinGW-w64 GCC 15.2.0 (WinLibs r7), Release, full build 0 errors, -j2.

guest_execvp (the test this PR changes) passes. The seven tests of the five PRs (guest_coredump_user_data, guest_np_web_api2, guest_execvp, guest_math, guest_wide_conversion, guest_wide_strings, guest_character) all pass.

Not checked: that the test fails without the change, Linux, a title run.

AI-assisted (Claude Code).

[MarcZX10]

I cannot confirm that PPSA97358 stops at execve: #3558 records a predicted stop, and I do not have a current-main run or the requested unresolved-import log line. The Windows report above covers the guest_execvp test, not a title run. I therefore cannot claim this PR unblocks PPSA97358; I have not changed the PR on that unsupported assumption.

[adriadam10]

Thanks for the carry. Dean's request from 2026-10-12 is still open, and the extra logic has no evidence behind it:

• executableError (core/libs/prx/libkernel/System/src/Process.cpp:172-187) adds EFAULT/ENOENT/ENOTDIR/EACCES, PATH_MAX and ARG_MAX handling. No title reaches it: the execv callers cited run in a fork child, and fork returns ENOSYS. Please drop it.
• Leave execv as it is on main and make execve a plain throwing export like execvp (NotImplemented_nid_no_patch("execve: executable replacement")), with guest_execvp covering only that throw.
• If you can quote the unresolved execve import for PPSA97358 (loader log or import table), add it to the PR body. #3558 only predicts it, so the body should not say this unblocks the title.
• Update the docs/dev/debt/libkernel.md line to match the smaller change.

Happy to re-review once pushed.

[MarcZX10]

Implemented the requested narrowing in c73a09d58, rebased on current main (5d50886ee). The PR now adds only the execve throwing export; it removes the execv change and the unverified argument/path checks. guest_execvp retains the existing execvp checks and verifies the execve throw. I also removed the unsupported title-unblock claim and updated the debt entry.

On Linux x86-64 with GCC 12.2.0, guest_execvp_tests builds and CTest guest_execvp passes (1/1). Conventions, test registration (18/18), and whitespace checks pass. No Windows, console, or title run was performed.

[MarcZX10]

@adriadam10 I pushed the requested narrowing and updated the regression, debt entry, and PR description. The Linux guest_execvp test, conventions, test registration, and diff checks pass on the current head. When convenient, please re-review.

[adriadam10]

Thanks for narrowing it. One thing was off: the diff renamed execv_nid_postfix to execve_nid_postfix, so execv was removed from main (and its debt line), although the description says it is unchanged. I added these as commits on your branch:

• restored the throwing execv export in Process.cpp and its line in docs/dev/debt/libkernel.md;
• guest_execvp now also checks that execv throws;
• rebased on current main.

Built and ran the libkernel/libs ctest scope on the merged tree (146 tests, green; guest_execvp passes). Merging once the full Build is green.

[p3n1cillin]

Title run with this PR: Windows 11, MinGW GCC 15.2.0 (WinLibs), Release. Built on main 3faa9cb40 merged with this PR and the other open PRs that the catalog titles need (#4377, #4379, #4374, #4383, #3798, #4863, #4105, my #5013/#5061/#5078/#5098/#5009 and the carries #5183/#5186, plus screamm's chroot branch from #3632); every title converted from its catalog release, eboot.bin kept in app0, 60 s runs.

• XPSemu (PPSA97358): with this PR, feat(libkernel): implement pthread_atfork registration #4377 and feat(libkernel): add getdtablesize #5061 it loads (no absent imports), then stops on getrlimit: unsupported resource 8 (feat(libkernel): report RLIMIT_NOFILE through getrlimit #5187) and after that on the fixed 0x400000 GOT read of Ruffle, VLC and XPSemu read their GOT at a fixed 0x400000 base from app0/imports.txt and fault once all imports load #4013.

AI-assisted (Claude Code).