You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DX: debuggable binaries — DWARF line info via LLVM DIBuilder, PHP-level stack traces with file:line on uncaught exceptions, phpc build --debug, --asan, and a phpc profile that maps perf samples back to PHP functions (lib/JIT/AotDebugSymbols.php, lib/JIT/Context.php, lib/AOT/Linker.php) #36394
Tooling: · developer experience when something goes wrong · child of #36379
Why
When an AOT binary misbehaves today the user gets phpc: fatal signal (segfault) after c:main_before_php or a 672 KB IR dump. There is no line info in the binary (AotDebugSymbols.php exists but emits no DWARF), uncaught exceptions print no PHP trace with file:line under AOT, and profiling shows PHPCompiler_ext_standard_… symbols with no mapping to user code. Every wave-1 diagnosis needed objdump and /proc — that is not a workflow users will follow.
Deliverable
--debug: emit DICompileUnit/DISubprogram/DILocation for user functions and statements via the bound LLVMDIBuilder* API (in ffi/llvm9.php), keep symbols, no -s; gdb/perf show file.php:line.
Uncaught exception / fatal under AOT prints the Zend-shaped trace (#0 file(line): fn()), including for exceptions crossing helper units; debug_backtrace() returns file/line/function.
phpc profile <binary> [args]: runs under perf record, resolves symbols through a generated symbol → PHP function map, prints a flat + callgraph report; documented in docs/performance.md.
Crash handler: on SIGSEGV/SIGABRT print the PHP-level trace of the current frame stack (frame pointers are kept in debug builds) before exiting 139.
Category
Tooling:· developer experience when something goes wrong · child of #36379Why
When an AOT binary misbehaves today the user gets
phpc: fatal signal (segfault) after c:main_before_phpor a 672 KB IR dump. There is no line info in the binary (AotDebugSymbols.phpexists but emits no DWARF), uncaught exceptions print no PHP trace with file:line under AOT, and profiling showsPHPCompiler_ext_standard_…symbols with no mapping to user code. Every wave-1 diagnosis neededobjdumpand/proc— that is not a workflow users will follow.Deliverable
--debug: emitDICompileUnit/DISubprogram/DILocationfor user functions and statements via the boundLLVMDIBuilder*API (inffi/llvm9.php), keep symbols, no-s;gdb/perfshowfile.php:line.#0 file(line): fn()), including for exceptions crossing helper units;debug_backtrace()returns file/line/function.--asan: link with-fsanitize=addressruntime and the runtime's own allocations instrumented (poison on free); used by Stdlib: count, array_key_exists, is_object and VM fixes #19's CI job.phpc profile <binary> [args]: runs underperf record, resolves symbols through a generatedsymbol → PHP functionmap, prints a flat + callgraph report; documented indocs/performance.md.Done when
gdbon a--debughello showshello.php:1; uncaught-exception trace matches Zend on the Stdlib: floatval, boolval, gettype(null) and expanded PHPT specs #5 corpusphpc profileoutput forbenchmarks/v2/nbodynames the PHP function at the top; documented