PHP 提供的钩子
PHP 和 Zend Engine 为扩展提供了许多不同的钩子, 这些扩展允许扩展开发人员以 PHP userland 无法提供的方式控制 PHP 运行时.
本章将展示各种钩子和从扩展钩子到它们的常见用例.
钩子到 PHP 功能的一般模式是 PHP 核心提供的扩展覆盖函数指针. 然后扩展函数通常执行自己的工作并调用原始 PHP 核心函数. 使用此模式, 不同的扩展可以覆盖同一个钩子而不会导致冲突.
挂钩到函数的执行
userland 和内部函数的执行由 Zend 引擎中的两个函数处理, 您可以用自己的实现替换这两个函数. 覆盖此钩子的扩展的主要用例是通用函数级评测, 调试和面向方面的编程.
钩子在 Zend/zend_execute.h 中定义:
ZEND_API extern void (*zend_execute_ex)(zend_execute_data *execute_data);ZEND_API extern void (*zend_execute_internal)(zend_execute_data *execute_data, zval *return_value);
如果要覆盖这些函数指针, 则必须在 Minit 中执行此操作, 因为 Zend Engine 中的其他决策是根据指针是否被覆盖这一事实提前做出的.
覆盖的通常模式是这样的:
- static void (*original_zend_execute_ex) (zend_execute_data *execute_data);static void (*original_zend_execute_internal) (zend_execute_data *execute_data, zval *return_value);void my_execute_internal(zend_execute_data *execute_data, zval *return_value);void my_execute_ex (zend_execute_data *execute_data);PHP_MINIT_FUNCTION(my_extension){
- REGISTER_INI_ENTRIES();
- original_zend_execute_internal = zend_execute_internal;
- zend_execute_internal = my_execute_internal;
- original_zend_execute_ex = zend_execute_ex;
- zend_execute_ex = my_execute_ex;
- return SUCCESS;}PHP_MSHUTDOWN_FUNCTION(my_extension){
- zend_execute_internal = original_zend_execute_internal;
- zend_execute_ex = original_zend_execute_ex;
- return SUCCESS;}
覆盖 zend_execute_ex 的一个缺点是它将 Zend Virtual Machine 运行时的行为更改为使用递归, 而不是在不离开解释器循环的情况下处理调用. 此外, 没有覆盖 zend_execute_ex 的 PHP 引擎也可以生成更优化的函数调用操作码.
这些挂钩对性能非常敏感, 具体取决于原始函数封装代码的复杂性.
覆盖内部功能
在覆盖执行钩子时, 扩展可以记录每个函数调用, 你还可以覆盖用户域, 核心和扩展函数 (和方法) 的各个函数指针. 如果扩展仅需要访问特定的内部函数调用, 则具有更好的性能特征.
- #if PHP_VERSION_ID <70200typedef void (*zif_handler)(INTERNAL_FUNCTION_PARAMETERS);#endif
- zif_handler original_handler_var_dump;ZEND_NAMED_FUNCTION(my_overwrite_var_dump){
- // 如果我们想调用原始函数
- original_handler_var_dump(INTERNAL_FUNCTION_PARAM_PASSTHRU);}PHP_MINIT_FUNCTION(my_extension){
- zend_function *original;
- original = zend_hash_str_find_ptr(EG(function_table), "var_dump", sizeof("var_dump")-1);
- if (original != NULL) {
- original_handler_var_dump = original->internal_function.handler;
- original->internal_function.handler = my_overwrite_var_dump;
- }}
覆盖类方法时, 可以在 zend_class_entry 上找到函数表:
- zend_class_entry *ce = zend_hash_str_find_ptr(CG(class_table), "PDO", sizeof("PDO")-1);if (ce != NULL) {
- original = zend_hash_str_find_ptr(&ce->function_table, "exec", sizeof("exec")-1);
- if (original != NULL) {
- original_handler_pdo_exec = original->internal_function.handler;
- original->internal_function.handler = my_overwrite_pdo_exec;
- }}
修改抽象语法树(AST)
当 PHP 7 编译 PHP 代码时, 它会先将其转换为抽象语法树(AST), 然后最终生成持久存储在 Opcache 中的操作码. zend_ast_process 钩子会被每个已编译的脚本调用, 并允许你在解析和创建 AST 之后修改 AST.
这是要使用的最复杂的钩子之一, 因为它需要完全了解 AST. 在此处创建无效的 AST 可能会导致异常行为或崩溃.
最好看看使用此钩子的示例扩展:
Google Stackdriver PHP 调试器扩展
基于 Stackdriver 的带有 AST 的概念验证器
熟悉脚本 / 文件编译
每当用户脚本调用 include/require 或其对应的 include_once/require_once 时, PHP 内核都会在指针 zend_compile_file 处调用该函数处理此请求. 参数是文件句柄, 结果是 zend_op_array.
zend_op_array * my_extension_compile_file(zend_file_handle * file_handle,int 类型);
PHP 核心中有两个扩展实现了此挂钩: dtrace 和 opcache.
如果您使用环境变量 USE_ZEND_DTRACE 启动 PHP 脚本并使用 dtrace 支持编译了 PHP, 则 dtrace_compile_file 用于 Zend / zend_dtrace.c.
Opcache 将操作数组存储在共享内存中以获得更好的性能, 因此, 每当脚本被编译时, 其最终的操作数组都会从缓存中得到服务, 而不是重新编译. 您可以在 ext / opcache / ZendAccelerator.c 中找到此实现.
名为 compile_file 的默认实现是 Zend / zend_language_scanner.l 中扫描程序代码的一部分.
实施此挂钩的用例是 Opcode Accelerating,PHP 代码加密 / 解密, 调试或概要分析.
您可以随时在执行 PHP 进程时替换该挂钩, 并且替换后编译的所有 PHP 脚本都将由该挂钩的实现处理.
始终调用原始函数指针非常重要, 否则 PHP 将无法再编译脚本, 并且 Opcache 将不再起作用.
此处的扩展覆盖顺序也很重要, 因为您需要知道是要在 Opcache 之前还是之后注册钩子, 因为 Opcache 如果在其共享内存缓存中找到操作码数组条目, 则不会调用原始函数指针. Opcache 将其钩子注册为启动后钩子, 该钩子在扩展的 minit 阶段之后运行, 因此默认情况下, 缓存脚本时将不再调用该钩子.
调用错误处理程序时的通知
与 PHP 用户区 set_error_handler()函数类似, 扩展可以通过实现 zend_error_cb 钩子将自身注册为错误处理程序:
ZEND_API void(* zend_error_cb)(int 类型, const char * error_filename,const uint32_t error_lineno,const char * format,va_list args);
type 变量对应于 E _ * 错误常量, 该常量在 PHP 用户区中也可用.
PHP 核心和用户态错误处理程序之间的关系很复杂:
如果未注册任何用户级错误处理程序, 则始终调用 zend_error_cb.
如果注册了 userland 错误处理程序, 则对于 E_ERROR,E_PARSE,E_CORE_ERROR,E_CORE_WARNING,E_COMPILE_ERROR 的所有错误和 E_COMPILE_WARNING 始终调用 zend_error_cb 挂钩.
对于所有其他错误, 仅在用户态处理程序失败或返回 false 时调用 zend_error_cb.
另外, 由于 Xdebug 自身复杂的实现, 它以不调用以前注册的内部处理程序的方式覆盖错误处理程序.
因此, 覆盖此挂钩不是很可靠.
再次覆盖应该以尊重原始处理程序的方式进行, 除非您想完全替换它:
- void(* original_zend_error_cb)(int 类型, const char * error_filename,const uint error_lineno,const char * format,va_list args);void my_error_cb(int 类型, const char * error_filename,const uint error_lineno,const char * format,va_list args){
- // 我的特殊错误处理
- original_zend_error_cb(type,error_filename,error_lineno,format,args);}PHP_MINIT_FUNCTION(my_extension){
- original_zend_error_cb = zend_error_cb;
- zend_error_cb = my_error_cb;
- return SUCCESS;}PHP_MSHUTDOWN(my_extension){
- zend_error_cb = original_zend_error_cb;}
该挂钩主要用于为异常跟踪或应用程序性能管理软件实施集中式异常跟踪.
引发异常时的通知
每当 PHP Core 或 Userland 代码引发异常时, 都会调用 zend_throw_exception_hook 并将异常作为参数.
这个钩子的签名非常简单:
- void my_throw_exception_hook(zval * exception){
- if(original_zend_throw_exception_hook!= NULL){
- original_zend_throw_exception_hook(exception);
- }}
该挂钩没有默认实现, 如果未被扩展覆盖, 则指向 NULL.
- static void(* original_zend_throw_exception_hook)(zval * ex);void my_throw_exception_hook(zval * exception);PHP_MINIT_FUNCTION(my_extension){
- original_zend_throw_exception_hook = zend_throw_exception_hook;
- zend_throw_exception_hook = my_throw_exception_hook;
- return SUCCESS;}
如果实现此挂钩, 请注意无论是否捕获到异常, 都会调用此挂钩. 将异常临时存储在此处, 然后将其与错误处理程序挂钩的实现结合起来以检查异常是否未被捕获并导致脚本停止, 仍然有用.
实现此挂钩的用例包括调试, 日志记录和异常跟踪.
挂接到 eval()
PHPeval 不是内部函数, 而是一种特殊的语言构造. 因此, 您无法通过 zend_execute_internal 或通过覆盖其函数指针来连接它.
挂钩到 eval 的用例并不多, 您可以将其用于概要分析或出于安全目的. 如果更改其行为, 请注意可能需要评估其他扩展名. 一个示例是 Xdebug, 它使用它执行断点条件.
extern ZEND_API zend_op_array *(* zend_compile_string)(zval * source_string,char * filename);
挂入垃圾收集器
当可收集对象的数量达到一定阈值时, 引擎本身会调用 gc_collect_cycles()或隐式地触发 PHP 垃圾收集器.
为了使您了解垃圾收集器的工作方式或分析其性能, 可以覆盖执行垃圾收集操作的函数指针挂钩. 从理论上讲, 您可以在此处实现自己的垃圾收集算法, 但是如果有必要对引擎进行其他更改, 则这可能实际上并不可行.
- int(* original_gc_collect_cycles)(无效);int my_gc_collect_cycles(无效){
- original_gc_collect_cycles();}PHP_MINIT_FUNCTION(my_extension){
- original_gc_collect_cycles = gc_collect_cycles;
- gc_collect_cycles = my_gc_collect_cycles;
- return SUCCESS;}
覆盖中断处理程序
当执行器全局 EG(vm_interrupt)设置为 1 时, 将调用一次中断处理程序. 在执行用户域代码期间, 将在常规检查点对它进行检查. 引擎使用此挂钩通过信号处理程序实现 PHP 执行超时, 该信号处理程序在达到超时持续时间后将中断设置为 1.
当更安全地清理或实现自己的超时处理时, 这有助于将信号处理推迟到运行时执行的后期. 通过设置此挂钩, 您不会意外禁用 PHP 的超时检查, 因为它具有自定义处理的优先级, 该优先级高于对 zend_interrupt_function 的任何覆盖.
- ZEND_API void(* original_interrupt_function)(zend_execute_data * execute_data);void my_interrupt_function(zend_execute_data * execute_data){
- if(original_interrupt_function!= NULL){
- original_interrupt_function(execute_data);
- }}PHP_MINIT_FUNCTION(my_extension){
- original_interrupt_function = zend_interrupt_function;
- zend_interrupt_function = my_interrupt_function;
- return SUCCESS;}
来源: https://www.cnblogs.com/it-abu/p/13400026.html