-
David Johnson authored
(This adds overlay support to Ptrace and Xen-Process; adds target API support for reading symbols (not addresses) and placing probes on symbols (not addresses). It adds some really basic support for php's dynamic symbols, but nothing complicated for things like objects and hashes; how to handle those is unclear. Finally, it's available in dumptarget, backtrace, and spf.) The PHP backend assumes it is stacked atop a process-level backend that provides C-symbol-level access to process running the PHP 5.x interpreter. It reads key datastructures to assemble its understanding of PHP-level "debugging symbols"; install function breakpoints; and read symbol values. PHP's compiler and execution engine (zend) is written in C. The PHP backend obtains its "debugging" symbol information by reading parsed and compiled class types and the global function list (which includes both internal, C-level functions aliased with PHP names; and user-written, PHP native functions). It does not support raw memory nor CPU register access, since the PHP language does not provide those constructs. Rather, it allows users to install "breakpoints" on function entry. It does this by placing probes on the underlying target at the C level, on the actual C function that executes a PHP function; when that probe is hit, the PHP target checks its list of "breakpoints" for those associated with the PHP function. The user can then load the PHP function arguments using the target API. The back end also supports unwinding PHP function call stacks. The PHP back end does not yet support global or local variables; nor PHP's more complex "basic" hashtable and object types. We don't implement a strategy for caching debugging symbols, or updating the info as new parts of scripts are compiled and/or executed -- that is nontrivial and time- consuming. Supporting statement breakpoints would also be hard because we cannot easily hook PHP in a single place to implement them. PHP provides PHP debugger extension writers with hooks in the executor to do just that; but those hooks are not really available to us. There are *many* opcode handlers, and finding a point to place a C-level breakpoint to emulate a PHP statement breakpoint is quite hard. We'd probably have a lot of such points! It *does* support either threaded or non-threaded PHP interpreters; this matters to use because each thread keeps its own copies of "global" data structures (like compiler and executor state). That doesn't mean it supports multiple PHP threads :). It supports single-threaded PHP processes where the PHP binary was compiled with multi-thread support. Lots more details in the comments...
c7e2f43d