Repository navigation
Conversation
|
I reviewed the caller-stack lifecycle across attribute capture, Linux/Windows thread startup, guest entry trampoline, return/exit/cancellation cleanup, stack-bound tracking, and the new lifecycle/unwind tests. The implementation consistently keeps host startup/TLS on the native thread, switches only for the guest entry, and restores native bounds before teardown; the test matrix described covers the main return, detach/reuse, cleanup and unwind cases. I ran Current main is 262 commits ahead of the merge base and has changed the shared libkernel test CMake file and debt entry; the pthread implementation paths themselves are unchanged. Please refresh those shared files before merge and preserve current registrations/debt. The listed adjacent PRs warrant the stated merge coordination. I found no independent blocker in this pass. |
|
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.
|
|
I reviewed head The live overlap scan identifies comparable shared hunks with #8041 (guard-size queries/attributes), #8477 and #9160 (thread startup), and #9684 (Linux stack placement); its comparisons against #4563 and #7149 are incomplete because those branches conflict with main. #7149 is particularly important to reconcile manually because both change GuestStacks and Windows pthread stack placement. #9573 also touches the pthread attribute/thread files, while #9482 shares the debt entry. The PR currently suggests merging in any order; please identify which behaviors are independent and preserve/retest them together, and add |
65f0cc1 to
b1f5164
Compare
|
Rebased onto Linux on the rebased tree: the full build, the regression (also in 20 repeats), 9 neighbouring tests, ASan and conventions pass. Full suite: 1,826 of 1,848 pass, 19 skip, and the same 3 None of the PRs below needs another one merged first, so
Two of them also meet this PR at run time without a conflict: #9160's new I have read the PR heads but not built the combinations. #7149 with this PR needs a Windows run, mainly to see whether its 256 KiB native stack is enough for caller-stack threads (this PR reserves 1 MiB). |
harisibrar1
left a comment
harisibrar1
left a comment
There was a problem hiding this comment.
Checked against main 3875f8c and FreeBSD 11.4 libthr (thr_create.c create_stack/_pthread_create, thr_attr.c):
- The semantics match libthr. A stack given in the attributes gets guard size 0 and is never freed or reprotected by the library. Both
setstackandsetstackaddrtreat the address as the lowest byte, andsetstackaddrkeeps the attr's current size. The existingEINVALchecks in bothAttr.cppfiles are unchanged and match. - The entry trampoline leaves the guest entry with rsp ≡ 8 mod 16, the same as FreeBSD's
cpu_set_upcall(top&~0xf, minus 8). TheDW_CFA_def_cfa_expressionresolves to the native frame (*(rbp+16)+16), so unwinding back across it reads correctly. - Freeing the stack after
scePthreadJoinis safe. Join returns only afterWaitForSingleObject/pthread_joinon the host thread, so the thread has left the caller stack, as with FreeBSD'sthr_exittid wakeup. - Small question: the non-Windows
StartNativeThreadbranch is also the macOS path, so macOS now runs caller-stack threads too, while the description and the test registration (if(WIN32 OR CMAKE_SYSTEM_NAME STREQUAL "Linux")) cover only Linux and Windows. Could the description mention that macOS gets the same switch untested, or could the test be registered there once macOS links? - I couldn't build or run this here, so I can't confirm the Windows TEB and
__chkstkbehaviour myself. The new debt entry about host code, handlers and probes overrunning below the range reads accurately to me.
Reviewed with AI assistance (Claude Code); the checks above were run locally on my machine.
MarcZX10
left a comment
MarcZX10
left a comment
There was a problem hiding this comment.
The caller-stack implementation and its lifetime/unwind coverage were already reviewed in my earlier comments; the author subsequently rebased to b1f516491827f8e53af5f189d064926a9128f6e2 and reports a passing Linux build, repeated focused tests, neighboring tests, ASan and conventions. Those runs are contributor-reported; hosted product build/test jobs remain skipped.
This branch is no longer current with upstream: tools/check_main_sync.py --base upstream/main --head refs/reviews/pr-9938 reports 1 ahead /278 behind, with Thread.cpp, libkernel/CMakeLists.txt, and docs/dev/debt/libkernel.md changed on both sides since the merge base. The merge is clean, but #9960 has changed Thread.cpp since this branch was based. Please refresh against current main, preserve the caller-stack lifecycle alongside that thread-startup work, and rerun the focused Linux/Windows stack and unwind tests plus conventions on the refreshed head.
The existing overlap feedback on #8041, #7149, #4563 and #9684 also still needs an agreed integration order/dependency where the shared behavior requires it; a general “whichever is ready” statement does not identify dependencies among those specific changes. Please record the agreed order in the checklist. This request is for the repository's current-main and overlap rules, not queue volume.
b1f5164 to
dca8f5b
Compare
|
Thanks for checking it against libthr. macOS: yes, the non-Windows branch of Windows: the TEB bounds were checked in the native runs under Tested, with WinLibs and with MSYS2 UCRT64. |
|
Refreshed onto On the new head, Linux passes the full build, Order: the description now proposes #8041 and #9684 first, then this PR, then #7149 and #4563, with what each step needs, and the checklist says |
|
@BorchBe99 Thanks for spelling out the #9482 interaction in your integration table. I agree with retaining its ended-thread For order, #9684's author has already agreed to #9482 first (#9684 (comment)); keeping that order also fits this PR's existing dependency on #9684. Your comment permits either order, so I am recording the #9482-first preference on my PR, without adding a runtime dependency or importing your stack implementation. If you need to go first, let me know so the later update preserves the guard and adjusts that combined test. I checked the current overlap and that #9482 still merges with main, but have not built the combined supplied-stack branch; no new runtime validation of your changes is claimed. AI-assisted coordination. |
…read stacks Took the PR as is; kept our IsInitialPthread_nid_no_patch and the created-suspended state next to its scePthreadCreate and include changes (only those two hunks conflicted).
…s the threads it creates from pthread_attr_get_np/scePthreadAttrGet attributes a stack of their own, since those attributes now carry the source thread's stack address and boykopovar#9938 honors it, so the copy ran on the stack of the suspended (or sleeping) thread it was copied from and crashed or hung
|
@zaryabzip, one combination with #9573 that my earlier comment missed. On Linux, with both PRs merged onto |
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
@BorchBe99 the order in your description is fine with me: #8041 and #9684 first, then this PR. #9684 doesn't depend on this one. One change for your rebase: #9684 now sizes the AI-assisted (Claude Code). |
dca8f5b to
36a6b5c
Compare
|
Rebased onto
The branch merges cleanly with @NevesHenry thanks. When I rebase onto #9684, its page alignment and the frame-address |
|
@BorchBe99 Thanks for the coordination! That merge order works great for #7565, and moving the MXCSR setup into Aps5CallGuestEntry_nid_no_patch sounds good. |
|
@BorchBe99 I am coordinating #11872 (POSIX read/receive cancellation, head bcf5df1) with this PR under CONTRIBUTING.md. Proposed order: #11872 first, then #9938. Both branches touch the guest-entry area of Thread.cpp. #11872 uses opaque saved-context identities for deferred I/O delivery and retains its native thread/cancellation lifetime rules. With #11872 first, your later rebase should retain those hooks alongside your caller-stack switch, native-bound restoration and exit/unwind order. Combined checks should include your supplied-stack/unwind/cancel cases and guest_io_context/guest_io_signal cases. This proposal does not change your existing #8041/#9684 ordering; I have not run the combined branch. Would you agree to that order and record #11872 in your Depends on line for the ordering? If your PR needs to go first, please say so; I can handle the later conflict resolution on #11872 instead. This is a proposal awaiting your confirmation, not an existing agreement. AI-assisted coordination. |
|
Windows result for head Host: Windows 11 26300, Intel i7-12700K, WinLibs GCC 15.2.0 (x86_64-ucrt-posix-seh, r6), Release, The tree also carried the open PRs #10615 and #10416, all merged cleanly, so the run is a joint one; the tests of this PR are AI-assisted: yes (Claude Code), the runs and the numbers above are from this machine. |
|
@Felipebmaitan agreed: #11872 goes first, and I added it to @maskym thanks for the Windows run. The Windows runs under Tested (WinLibs and MSYS2 UCRT64) used the same tree as this head. |
|
@BorchBe99 thanks for the careful write-up; the trampoline, exit and TEB handling read correctly to me. One concern before merge: with a caller stack, every host call the guest thread makes (graphics submission and shader recompilation, file I/O, the Vulkan driver) now runs on the caller's memory with no margin or guard page below it. On |
… the native exit path
|
@BorchBe99 merge-order request for #12897, my two-line macOS fix in
On Darwin, Proposal: #12897 first, then this PR. It is two lines with no other dependency, and this PR still has open review points. To make the rebase free for you,
Tested on macOS (the macOS PR set from #1 plus that branch):
If you'd rather land first, say so: I'll rebase #12897 onto this PR with the same one-line change and rerun. Either way I'll record the order in #12897's Separately, your |
|
@oneandonlydean thanks. I have no run of a title that sets its own thread stacks, so I can't add that evidence before your A/B run. For detection, this PR could protect the lowest whole 16 KiB page inside the caller's range while the thread runs, so an overrun faults as soon as it touches that page instead of writing into the memory below. The guest then has 16 KiB less of the range than it asked for. Should I add that? @AdnanKhan-ak47 agreed: #12897 goes first, and I added it to |
|
@BorchBe99 #12897 is merged, so this conflicts with The only conflict was in |
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
@AdnanKhan-ak47 thanks for refreshing it. #8477 was merged after your branch and added a conflict in |
|
@BorchBe99 confirming the already-recorded #12682-first order from this stack's side. The replacement reads head is now I inspected your current This stack's current composed-source tests pass 660 focused CTests plus six socket/shared-memory composition cases on the translated Linux container. That is not a combined #9938 runtime result, a caller-stack title run, or native Windows 22621 hang qualification. Your existing #8041/#9684 and other ordering/review requirements are unchanged; no maintainer approval or combined validation is implied. Your branch was not modified. AI-assisted: yes. |
|
@Felipebmaitan thanks for confirming the order and for checking the exit paths. I like this project a lot and opened this PR to support it. I can no longer look after it, though, and I am stopping my work on AnyPS5 until further notice. Anyone is free to use, change or take over the changes here; maintainer edits are enabled on the branch. |
github-actions
Bot
added
libc
libkernel
build
docs
ci
What
scePthreadCreateignored a stack address set in the thread attributes. A thread created with one now runs on that memory, with the given size, on Linux and Windows. This finishes the caller-stack follow-up from #1988. The caller keeps ownership of the memory. Host startup still runs on the native stack, and TLS stays per host thread.Caller stacks report guard size 0. Thread identity and the stack's lifetime survive return, explicit exit, cancellation and key destructors. On Windows the TEB stack bounds cover the caller's range while the thread runs and are set back to the native bounds before it ends; existing context-stack registrations and pins stay. When
longjmp,siglongjmporsetcontextlands on a caller stack, the TEB gets that stack's range, also when a larger registered context stack contains it.A caller stack has no guard page below it; the libkernel debt file records this.
Merge order with the five open PRs that share behavior with this one:
Thread.cppstays as it is.retiredWinStacks. With fix(libkernel): keep a finished Windows thread's stack until it is joined or detached #4563AwaitReapruns after the exit bridge has switched back to the native stack, because the joiner may free the caller's stack once join returns.If one of you needs another order, reply here and I will change
Depends on. #7192 (@Jev1337) and #7565 (@pushkarreddyy) can merge before or after this PR, and so can #14190 (@JJenkx) and #15165 (@ljkx), which share only lines indocs/dev/debt/libkernel.mdand.github/sanitizer-known-failures.txtwith it; this comment lists what the later one keeps. With #7565, its MXCSR setup moves into this PR's version ofAps5CallGuestEntry_nid_no_patch. #12688, #12700 and #12965 (all @Felipebmaitan) build on #12682 and touch this PR's files only through #12682's code. Since #9482 is merged, the new test's joined-thread case expectsESRCHfrompthread_attr_get_np. Since #9573 is merged, this PR also changes its testguest_pthread_create_suspended: two of its threads are created from attributes copied from a live thread, which carry that thread's stack address, so they now get a stack of the test's own (as announced). Since #12897 and #12963 are merged,RunGuestThreadcalls_setjmp, andscePthreadCreatekeeps thependingExceptionreset before this PR's caller-stack lines.Tested
The new regression test covers all three setter paths, small stacks with large TLS, detach and reuse, and mixed cleanup chains including libc
_Thrd_exit. Threads with and without a caller stack catch a host exception and then unwind with the standard unwinder across the entry trampoline to the host stack. On Windows it also checks the TEB range after auc_linkreturn onto a caller stack inside a larger registered context stack.Linux x86_64, GCC 15.3.0. This head merges
mainat5cb015ca(2026-11-03). On it the full default build,libs,public_headersand conventions pass, and so do the 9 pthread tests and the 16 neighbouring tests below, with the regression andguest_pthread_create_suspendedagain in 20 repeats each. The other Linux results are from this PR on0278ca98(mainon 2026-11-02), before its line in.github/sanitizer-known-failures.txt, which no build compiles and onlytools/sanitizer_report.pyand its testtools/tests/test_sanitizer_report.pyread (that test passes with the line):libsand conventions pass. The regression passes, also in 20 repeats, and so do 8 other pthread tests,guest_pthread_create_suspended(also in 20 repeats) and 16 neighbouring tests (libc threads, backtrace, mutex, cancel recovery, user context, memory, fixed mmap, andmain's newer tests of thread defaults, handle lifetime, detach attributes and raised exceptions). Under ASan, 6 of 7 pthread tests and a separate range and lifecycle probe pass. The regression aborts in one case: a thread on a caller stack returns throughuc_linkfrom amakecontextcontext on a larger stack that contains its own.setcontext_nid_postfixends in a[[noreturn]]call since feat(libkernel_sys): finish sched_setscheduler and sigreturn #10838, and ASan, which still takes the caller stack for the current one, ignores the__asan_handle_no_returnthere and then reports astack-buffer-overflowon the stale redzones.makecontextandsetcontexthave no fiber annotations, so this PR lists the test in.github/sanitizer-known-failures.txt;tools/sanitizer_report.pythen counts that run as a known failure. The ASan build of this PR onb90d009dpasses with the same ASan runtime, andmain's ownuc_linktests pass under ASan with and without this PR.agc_driver_scattered_runsneeds a udmabuf limit below two chunks and fails the same way on a clean build of0278ca98.tools/check_skips.pyrejects 3 skips:agc_driver_sparse_dma_buf_importandagc_host_import_sparseskip because this host's udmabufsize_limit_mbis above 1024, andagc_driver_optimize_on_fiberskips in a default build, which leavesANYPS5_ENABLE_SPIRV_TOOLSoff.Windows 11 x64, local native run (not CI), this PR on
0278ca98, the tree of the Linux results above:guest_pthread_create_suspended, and 2 user-context tests pass. The WinLibs run also covers the full build,libs, conventions and 2 memory tests.vulkan_validation_gate_reports,main_sync_renames_test_feature_rename_with_detection_disabled,main_sync_renames_test_main_rename_with_detection_disabledandcheck_compile_test_windows_gcc_response_text_mode_is_not_reinterpretedfail the same way on a clean build of0278ca98.pe_import_firsttimed out once at 10.02 s against its 10 s limit and passes when run alone, with and without this PR.tools/check_skips.py --job windowsrejects 3 skips:guest_fopen_errors, which the clean build of0278ca98skips the same way, and 2 that come from this laptop:long_paths(long paths are disabled in the registry) andguest_video_out_high_frame_rate(the display has only 60 Hz modes).Broken versions of the change fail the regression. On Linux, with the trampoline's CFI damaged (CFA without the final
+16, or no CFA expression), it aborts at the unwind check. On Windows (WinLibs, treeebf12e33), ifGuestStackSwitch_nid_no_patchkeeps the current TEB range whenever it already contains the new stack pointer, it fails at theuc_linkcheck.Not covered: Windows was not run on the merge with
5cb015ca, which brings #14402's thread-name change intoStartNativeThread. The host-bounds check runs on the main test thread and does not see a worker's final TEB state. macOS takes the same stack switch as Linux but was not built or run. Project CI, game compatibility and performance are not tested.Checklist
main; no other open PR implements the same functionsNotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file.mdfiles or images added to the repository (attach them to this PR)🤖 Generated with Claude Code