What is already done

x86-64 routes thread creation through pthread_create when it resolves (an optional import, weakexternal), so glibc makes the thread and owns its fs. PxxPthreadStart installs pxx's own gs block and alt stack in the child, so pxx's own thread-locals are unaffected. See the 2026-09-14 section of devdocs/dev/threading.md.

What is left

PthreadRouteAvailable returns False off x86-64 because PxxPthreadStart uses arch_prctl(ARCH_SET_GS), which is x86-64's way of installing a thread block. Each other target needs its own equivalent in the trampoline — the same one its __pxxclone child leg already uses — and then the route opens with no other change: the weak imports, the handle fields, the create/join dispatch and the DT_NEEDED collapse are all target-independent.

Start by reproducing, not by porting. test/thread_glibc_malloc_two_threads.pas is the repro and i386 is the cheap target: it builds and runs here. A null result there is information — it would mean the hazard needs something i386's libc does differently, and that is worth knowing before four ports.

Why it is prio 45 and not 85

The x86-64 instance was ranked 85 because it aborted the lekkerzeilen demo, on the host everybody develops on. These targets have no demo standing on them and a cross-built program linking a shared library is rare. It is the same defect and a smaller blast radius — rank the reach, not the mechanism.