PHPフック

                                           

PHP によって提供されるフック

PHP と Zend Engine は、拡張機能開発者が PHP ランタイムを制御できるようにする拡張機能用のさまざまなフックを提供します。 PHP ユーザーランドでは提供できない方法です。

この章では、さまざまなフックと、拡張フックからそれらへの一般的な使用例を示します。

PHP 機能にフックする一般的なパターンは、PHP コアによって提供されるオーバーライド関数ポインターを拡張することです。その後、拡張関数は通常、独自の作業を実行し、元の PHP コア関数を呼び出します。このパターンを使用すると、異なる拡張機能が競合を引き起こすことなく同じフックをオーバーライドできます。

#関連する学習に関する推奨事項:

PHP プログラミングの入門から熟練度まで

#関数の実行へのフックuserland および内部関数の実行は、Zend エンジンの 2 つの関数によって処理され、独自の実装に置き換えることができます。このフックをカバーする拡張機能の主な使用例は、一般的な関数レベルのプロファイリング、デバッグ、アスペクト指向プログラミングです。

フックは

Zend/zend_execute.h

:<pre class="brush:php;toolbar:false;">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);</pre> で定義されていますこれらの関数ポインターを上書きしたい場合は、その他の決定のため、Minit でこれを行う必要があります。ポインタが上書きされるという事実に基づいて、事前に作成されます。

通常の上書きパターンは次のとおりです:

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

をオーバーライドする場合の欠点の 1 つは、ハンドルの代わりに再帰を使用するように Zend 仮想マシン ランタイムの動作が変更されることです。インタプリタループを離れることなく呼び出します。さらに、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

にあります: <pre class="brush:php;toolbar:false;">zend_class_entry *ce = zend_hash_str_find_ptr(CG(class_table), &quot;PDO&quot;, sizeof(&quot;PDO&quot;)-1);if (ce != NULL) { original = zend_hash_str_find_ptr(&amp;ce-&gt;function_table, &quot;exec&quot;, sizeof(&quot;exec&quot;)-1); if (original != NULL) { original_handler_pdo_exec = original-&gt;internal_function.handler; original-&gt;internal_function.handler = my_overwrite_pdo_exec; }}</pre>

抽象構文ツリー (AST) を変更する PHP 7 が PHP コードをコンパイルするとき、まずそれを抽象構文ツリー (AST) に変換し、最後に Opcache に保持されるオペコードを生成します。

zend_ast_process

フックは、コンパイルされたすべてのスクリプトによって呼び出され、AST が解析および作成された後に変更できるようになります。 これは、AST に関する完全な知識が必要なため、使用するのに最も複雑なフックの 1 つです。ここで無効な AST を作成すると、予期しない動作やクラッシュが発生する可能性があります。

このフックを使用するサンプル拡張機能を見てみましょう:

Google Stackdriver PHP デバッガー拡張機能

• AST を使用した Stackdriver ベースの概念実証

スクリプト/ファイルのコンパイルに関する知識 ユーザー スクリプトが

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 コアには、このフックを実装する 2 つの拡張機能 (dtrace と opcache) があります。

- 環境変数

USE_ZEND_DTRACE

を使用して PHP スクリプトを開始し、dtrace サポートを使用して PHP をコンパイルする場合、

dtrace_compile_file が Zend/zend_dtrace に使用されます。 c 。 - Opcache はパフォーマンスを向上させるために op 配列を共有メモリに保存するため、スクリプトがコンパイルされるたびに、最終的な op 配列は再コンパイルされずにキャッシュから提供されます。この実装は ext/opcache/ZendAccelerator.c にあります。
- compile_file という名前のデフォルトの実装は、
Zend/zend_ language_scanner.l のスキャナー コードの一部です。 このフックを実装するユースケースは、オペコードの高速化、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核心和用户态错误处理程序之间的关系很复杂：

1.如果未注册任何用户级错误处理程序，则始终调用zend_error_cb。
2.如果注册了userland错误处理程序，则对于E_ERROR，E_PARSE，E_CORE_ERROR，E_CORE_WARNING，E_COMPILE_ERROR的所有错误和E_COMPILE_WARNING始终调用zend_error_cb挂钩。
3.对于所有其他错误，仅在用户态处理程序失败或返回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;}

##替换操作码处理程序

TODO

以上がPHPフックの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。