[Sunrisepeak]

Probe — temporary, CI only, not to be merged.

Question: can this clangd (llvm-project 23.1.0 + patches/ + overlay/, i.e. the v0.0.17 engine 23.1.0-mcppls.5) be built once per architecture as an ok image (<arch>-openkal), started by the okrun of Linux x86_64/aarch64, macOS arm64 and Windows x64, and what does it cost against the native clangd of the same source?

Method (probe/openkal/, workflow probe-openkal.yml; measured run 40908632199): openkal's compile conventions read from mcpp 2026.10.29.1's compile of a plain unit for <arch>-openkal (openkal-platform 0.17.3, openkal-musl 0.22.6, openkal-llvm-runtime 0.16.6) → a CMake toolchain file; CMake builds only the static libraries clangd links (host tablegen native); mcpp links clangd's main over them and seals the image (okld note + okld check); each system runs the cases with the native clangd (v0.0.17 release) and with the image under mcpp-ide 0.1.1's okrun. --check-locations=false, median of 3.

Result

Stage	x86_64	aarch64
compile (2848 objects, clang + clang-tools-extra + series)	0 errors (with the 3 workarounds below)	0 errors
link + seal by mcpp	ok after __cxa_thread_atexit workaround; 0 imports beyond kal_*	same
image size	71 537 000 B; --strip-all 53 888 816 B (still passes okld check, runs) ; gzip -9 19.2 MB	74 725 776 B
native clangd (same source)	55 306 936 B	—

System (okrun)	--version	freestanding parse (4000 templates)	named module (import m)	module, supervised workers	system C++ std library
Linux x86_64	ok	ok · 2.49 s / 232 MiB (native 2.23 s / 122 MiB)	ok · 0.40 s / 141 MiB (native 0.13 s / 50 MiB)	ok (policy falls back in-process: __linux__ undefined)	SIGSEGV after Building AST... (native ok 1.21 s / 103 MiB)
Linux aarch64	ok	ok · 2.00 s / 231 MiB (native 1.88 s / 122 MiB)	ok · 0.33 s / 145 MiB (native 0.14 s / 49 MiB)	ok (in-process)	SIGSEGV after Building AST... (native ok 0.99 s / 102 MiB)
macOS arm64	ok	ok · 1.56 s / 245 MiB (native 1.10 s / 153 MiB)	ok · 0.46 s / 165 MiB (native 0.25 s / 40 MiB)	—	ok · 1.43 s / 258 MiB (native 1.11 s / 171 MiB)
Windows x64	ok	fails (path style)	fails	—	fails

Windows, every case (also with --resource-dir named):

Testing on source file C:/Users/runneradmin/AppData/Local/Temp/okprobe-…/C:\Users\runneradmin\AppData\Local\Temp\okprobe-…\test.cpp
E Failed to auto-detect resource directory, specify it manually via --resource-dir command line argument
E Couldn't read C:/Users/…/okprobe-…/test.cpp: Invalid argument      (the relative-name case: the name is right, the read fails)

C:\… and C:/… are relative to LLVM's POSIX path style (sys::path::Style::native is decided at compile time), so they are joined to the current directory; the resource directory is the parent of C:\…\clangd.oke, which POSIX style cannot find; and even a well-formed C:/… name fails to be read (EINVAL, below LLVM; not isolated).

What blocked, and whose it is

#	Finding	Side	Probe workaround
1	port/include/features.h defines restrict in C++; clang's TokenKinds.def (C99_KEYWORD(restrict)) expands it → no member named 'kw_restrict'	openkal-musl (fixed in 0.22.7/0.22.8)	-Drestrict=restrict
2	pread links but answers ENOSYS; a configure check cannot see it (HAVE_PREAD found) → every MemoryBuffer::getFile fails	openkal-musl	-DHAVE_PREAD=0
3	file-backed mmap answers ENOSYS (LLVM falls back to reading; no page sharing)	openkal (no file mapping interface)	none needed
4	__cxa_thread_atexit is exported only on __linux__/__Fuchsia__/OPENKAL_TARGET_WINDOWS/__APPLE__ → any image with a thread_local that has a destructor is refused by okld check (minimal repro: thread_local std::string)	openkal-llvm-runtime (libcxxabi/src/cxa_thread_atexit.cpp guard)	definition beside clangd's main
5	LLVM keys OS facts on __linux__ etc.: <machine/endian.h>, getprogpath, is_local	LLVM patch	openkal-llvm.patch
6	getMainExecutable read /proc/self/exe = okrun; must be kal_env_image	LLVM patch	openkal-llvm.patch
7	/proc/self/fd/N names the loader's descriptor N → openFileForRead's real path was the directory	LLVM patch (and a note for openkal-musl)	openkal-llvm.patch (drop TRY_PROC_SELF_FD)
8	path style is compile-time: on Windows every C:\/C:/ name is relative; resource dir not found	LLVM patch (runtime style from kal_env_system)	none — blocks Windows
9	reading a well-formed C:/… name fails EINVAL	openkal-musl / openkal-windows (not isolated)	none
10	SIGSEGV parsing libstdc++ headers on Linux (both arches); macOS SDK headers pass	unknown (not isolated; main stack measured ~8 MiB)	none
11	spawning the own image (module workers) runs the .oke directly → SIGSEGV; needs loader + image (kal_env_loader); getrlimit/setrlimit unavailable (worker address-space limit)	LLVM patch (series 0017) + openkal	not exercised
12	default target triple is compile-time (LLVM_HOST_TRIPLE); a Windows host would default to linux-gnu	LLVM patch	—
13	prebuilt archives passed by [build] ldflags are not link inputs: changing them does not relink	mcpp	delete the image
14	the conventions came from a compile command; the formal route is ${mcpp.contract} (mcpp 2026.10.30.1) and mcpp-plugins deps-cmake	mcpp / plugins	gen_toolchain.py

Cost against native (Linux/macOS, where it runs): parse time +6–42 %; a constant ≈ +90–125 MiB resident (module case 141 vs 50 MiB), consistent with the image's pages being private copies rather than a shared file mapping (#3); start-up ≈ +0.2–0.3 s.

okb of both images: not produced — okld bundle wants one image name per architecture (fixed in the workflow, not rerun). Estimate from the measured images: ≈ 108 MB stored with --strip-all (≈ 39 MB gzip).

Co-authored-by: speak-agent 248744407+speak-agent@users.noreply.github.com

[Sunrisepeak]

Probe concluded (design 2026-10-29 §9.4): clangd stays a native program per system inside the one mcppls payload; the ok-image clangd is not adopted. No change to mcppls-clangd.