php内核分析(七)-扩展

简介:

这里阅读的php版本为PHP-7.1.0 RC3,阅读代码的平台为linux。

我们研究下反射这个扩展。

反射这个扩展目录是存在在:ext/reflection。其实里面的代码很简单。一个.h文件,一个 .c文件。

我们先看下.c文件中,会看到很多ZEND_METHOD

ZEND_METHOD(reflection_function, getReturnType)
{
     ...
}

对应的宏:

#define ZEND_METHOD(classname, name)     ZEND_NAMED_FUNCTION(ZEND_MN(classname##_##name))
#define ZEND_NAMED_FUNCTION(name)          void name(INTERNAL_FUNCTION_PARAMETERS)
#define ZEND_MN(name) zim_##name
#define INTERNAL_FUNCTION_PARAMETERS zend_execute_data *execute_data, zval *return_value

这里的##代表的是连接,展开实际上就是:

void zim_reflection_function_getReturnType(zend_execute_data *execute_data, zval *return_value)

总而言之,我们这里是使用ZEND_METHOD定义了一个函数zim_reflection_function_getReturnType,那从执行代码是怎么调用到这里的呢?

好吧,所以我们这里是看不到扩展的调用堆栈的。那我们用gdb看下调用堆栈。

写个使用反射扩展的脚本:

  1 <?php
  2
  3 class B
  4 {
  5     public function test(): B
  6     {
  7
  8     }
  9 }
10
11 function getB(): B
12 {
13
14 }
15
16 $rc = new ReflectionMethod('B', 'test');
17 var_dump((string)$rc->getReturnType(), $rc->getReturnType());
18
19 $rc = new ReflectionFunction('getB');
20 var_dump((string)$rc->getReturnType(), $rc->getReturnType());

使用gdb进行打点,我们看了下getReturnType的扩展定义,里面有个在扩展代码中的函数reflection_type_factory,就使用这个打点了。

(gdb) b reflection_type_factory

(gdb) run -f /home/xiaoju/software/php7/demo/echo.php

(gdb) s

(gdb) bt
#0  reflection_type_factory (fptr=0x7ffff6004210, closure_object=0x0, arg_info=0x7ffff6079048,
    object=0x7ffff60140d0) at /home/xiaoju/webroot/php-src/php-src-master/ext/reflection/php_reflection.c:1280
#1  0x0000000000760d23 in ZEND_DO_FCALL_SPEC_RETVAL_USED_HANDLER (execute_data=0x7ffff6014030)
    at /home/xiaoju/webroot/php-src/php-src-master/Zend/zend_vm_execute.h:1097
#2  0x000000000073fc88 in execute_ex (ex=<value optimized out>)
    at /home/xiaoju/webroot/php-src/php-src-master/Zend/zend_vm_execute.h:432
#3  0x000000000078b670 in zend_execute (op_array=0x7ffff60782a0, return_value=<value optimized out>)
    at /home/xiaoju/webroot/php-src/php-src-master/Zend/zend_vm_execute.h:474
#4  0x00000000006e48a3 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /home/xiaoju/webroot/php-src/php-src-master/Zend/zend.c:1464
#5  0x0000000000684870 in php_execute_script (primary_file=0x7fffffffe090)
    at /home/xiaoju/webroot/php-src/php-src-master/main/main.c:2541
#6  0x000000000078e9ea in do_cli (argc=3, argv=0xee1bc0)
    at /home/xiaoju/webroot/php-src/php-src-master/sapi/cli/php_cli.c:994
#7  0x000000000078f1ea in main (argc=3, argv=0xee1bc0)
    at /home/xiaoju/webroot/php-src/php-src-master/sapi/cli/php_cli.c:1387
(gdb)

好了,很清晰可以看到这个脉络:

main->do_cli->php_execute_scripts->zend_execute->execute_ex->ZEND_DO_FCALL_SPEC_RETVAL_USED_HANDLER->reflection_type_factory

对于main, do_cli, php_execute_scripts, zend_execute, execute_ex 根据前面的main函数分析,我们很容易能够理解各个函数的作用。换句话说,execute_ex才是实际上调用opcode最终最重要的函数。

对照这个脚本的opcode:

L1-21 {main}() /home/xiaoju/software/php7/demo/echo.php - 0x7fd6a127f000 + 30 ops
L3    #0     NOP
L11   #1     NOP
L16   #2     NEW                     "ReflectionMethod"                        @1
L16   #3     SEND_VAL_EX             "B"                  1
L16   #4     SEND_VAL_EX             "test"               2
L16   #5     DO_FCALL
L16   #6     ASSIGN                  $rc                  @1
L17   #7     INIT_FCALL              112                  "var_dump"
L17   #8     INIT_METHOD_CALL        $rc                  "getReturnType"
L17   #9     DO_FCALL                                                          @4
L17   #10    CAST                    @4                                        ~5
L17   #11    SEND_VAL                ~5                   1
L17   #12    INIT_METHOD_CALL        $rc                  "getReturnType"
L17   #13    DO_FCALL                                                          @6
L17   #14    SEND_VAR                @6                   2
L17   #15    DO_ICALL
L19   #16    NEW                     "ReflectionFunction"                      @8
L19   #17    SEND_VAL_EX             "getB"               1
L19   #18    DO_FCALL
L19   #19    ASSIGN                  $rc                  @8
L20   #20    INIT_FCALL              112                  "var_dump"
L20   #21    INIT_METHOD_CALL        $rc                  "getReturnType"
L20   #22    DO_FCALL                                                          @11
L20   #23    CAST                    @11                                       ~12
L20   #24    SEND_VAL                ~12                  1
L20   #25    INIT_METHOD_CALL        $rc                  "getReturnType"
L20   #26    DO_FCALL                                                          @13
L20   #27    SEND_VAR                @13                  2
L20   #28    DO_ICALL
L21   #29    RETURN                  1

可以看到这个$rc->getReturnType()相对应的opcode是在#9 DO_FCALL

好了,我们从execute_ex开始跟,可以简化成:

// 最核心的执行opcode的函数
ZEND_API void execute_ex(zend_execute_data *ex)
{
     ...
     while (1) {
          int ret;
          if (UNEXPECTED((ret = ((opcode_handler_t)OPLINE->handler)(ZEND_OPCODE_HANDLER_ARGS_PASSTHRU)) != 0)) {
              ...
          }

     }
    ...
}

这里的handler每个opcode的op对应一个handler,比如 DO_FCALL对应的handler就是ZEND_DO_FCALL_SPEC_RETVAL_USED_HANDLER(和刚才的bt现显示的堆栈一样)

简化下伪代码如下:

// DO_FCALL这个opcode对应的处理函数
static ZEND_OPCODE_HANDLER_RET ZEND_FASTCALL ZEND_DO_FCALL_SPEC_RETVAL_USED_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
     ...
     if (EXPECTED(fbc->type == ZEND_USER_FUNCTION)) {  // 如果是用户定义的函数
          ...
        zend_execute_ex(call);
        ...
     } else if (EXPECTED(fbc->type < ZEND_USER_FUNCTION)) { // 如果是内部函数
          ...
          if (!zend_execute_internal) {
               fbc->internal_function.handler(call, ret);  // 执行这个internal_function所定义的handler函数,这个就是实际的调用方法了,命名为:zim_[class]_function_[function]
          } else {
               zend_execute_internal(call, ret);
          }
        ...

     } else { /* ZEND_OVERLOADED_FUNCTION */
          ...
          if (UNEXPECTED(!zend_do_fcall_overloaded(fbc, call, ret))) {
               HANDLE_EXCEPTION();
          }
        ...
     }

fcall_end:
     ...
     ZEND_VM_SET_OPCODE(opline + 1);
     ZEND_VM_CONTINUE(); // 下一条op
}

可以看到,这个函数里面就有一个fbc->internal_function.handler,这里的internal_function对应的函数名就是zim_reflection_function_getReturnType,和我们扩展模块里面定义的函数对应上了。可以说,这里就进入了扩展里面了。


本文转自轩脉刃博客园博客,原文链接:http://www.cnblogs.com/yjf512/p/6120856.html,如需转载请自行联系原作者

相关实践学习
阿里云图数据库GDB入门与应用
图数据库(Graph Database,简称GDB)是一种支持Property Graph图模型、用于处理高度连接数据查询与存储的实时、可靠的在线数据库服务。它支持Apache TinkerPop Gremlin查询语言,可以帮您快速构建基于高度连接的数据集的应用程序。GDB非常适合社交网络、欺诈检测、推荐引擎、实时图谱、网络/IT运营这类高度互连数据集的场景。 GDB由阿里云自主研发,具备如下优势: 标准图查询语言:支持属性图,高度兼容Gremlin图查询语言。 高度优化的自研引擎:高度优化的自研图计算层和存储层,云盘多副本保障数据超高可靠,支持ACID事务。 服务高可用:支持高可用实例,节点故障迅速转移,保障业务连续性。 易运维:提供备份恢复、自动升级、监控告警、故障切换等丰富的运维功能,大幅降低运维成本。 产品主页:https://www.aliyun.com/product/gdb
相关文章
|
3月前
|
设计模式 数据库连接 PHP
PHP中的设计模式:提升代码的可维护性与扩展性在软件开发过程中,设计模式是开发者们经常用到的工具之一。它们提供了经过验证的解决方案,可以帮助我们解决常见的软件设计问题。本文将介绍PHP中常用的设计模式,以及如何利用这些模式来提高代码的可维护性和扩展性。我们将从基础的设计模式入手,逐步深入到更复杂的应用场景。通过实际案例分析,读者可以更好地理解如何在PHP开发中应用这些设计模式,从而写出更加高效、灵活和易于维护的代码。
本文探讨了PHP中常用的设计模式及其在实际项目中的应用。内容涵盖设计模式的基本概念、分类和具体使用场景,重点介绍了单例模式、工厂模式和观察者模式等常见模式。通过具体的代码示例,展示了如何在PHP项目中有效利用设计模式来提升代码的可维护性和扩展性。文章还讨论了设计模式的选择原则和注意事项,帮助开发者在不同情境下做出最佳决策。
|
3月前
|
设计模式 算法 数据库连接
PHP中的设计模式:提高代码的可维护性与扩展性本文旨在探讨PHP中常见的设计模式及其应用,帮助开发者编写出更加灵活、可维护和易于扩展的代码。通过深入浅出的解释和实例演示,我们将了解如何使用设计模式解决实际开发中的问题,并提升代码质量。
在软件开发过程中,设计模式是一套经过验证的解决方案模板,用于处理常见的软件设计问题。PHP作为流行的服务器端脚本语言,也有其特定的设计模式应用。本文将重点介绍几种PHP中常用的设计模式,包括单例模式、工厂模式和策略模式,并通过实际代码示例展示它们的具体用法。同时,我们还将讨论如何在实际项目中合理选择和应用这些设计模式,以提升代码的可维护性和扩展性。
69 4
|
2月前
|
NoSQL 安全 Linux
MongoDB PHP 扩展
10月更文挑战第19天
13 0
MongoDB PHP 扩展
|
3月前
|
监控 IDE PHP
php xdebug的配置、调试、跟踪、调优、分析
php xdebug的配置、调试、跟踪、调优、分析
|
3月前
|
缓存 监控 算法
分析慢日志文件来优化 PHP 脚本的性能
分析慢日志文件来优化 PHP 脚本的性能
|
3月前
|
设计模式 存储 算法
PHP中的设计模式:策略模式的深入解析与应用在软件开发的浩瀚海洋中,PHP以其独特的魅力和强大的功能吸引了无数开发者。作为一门历史悠久且广泛应用的编程语言,PHP不仅拥有丰富的内置函数和扩展库,还支持面向对象编程(OOP),为开发者提供了灵活而强大的工具集。在PHP的众多特性中,设计模式的应用尤为引人注目,它们如同精雕细琢的宝石,镶嵌在代码的肌理之中,让程序更加优雅、高效且易于维护。今天,我们就来深入探讨PHP中使用频率颇高的一种设计模式——策略模式。
本文旨在深入探讨PHP中的策略模式,从定义到实现,再到应用场景,全面剖析其在PHP编程中的应用价值。策略模式作为一种行为型设计模式,允许在运行时根据不同情况选择不同的算法或行为,极大地提高了代码的灵活性和可维护性。通过实例分析,本文将展示如何在PHP项目中有效利用策略模式来解决实际问题,并提升代码质量。
|
4月前
|
安全 前端开发 PHP
构建与验证表单:传统PHP与Laravel框架的比较分析——探索Web开发中表单处理的优化策略和最佳实践
【8月更文挑战第31天】在 Web 开发中,表单构建与数据验证至关重要。传统 PHP 方法需手动处理 HTML 表单和数据验证,而 Laravel 框架则提供了一种更现代、高效的解决方案。本文通过对比传统 PHP 和 Laravel 的方法,探讨表单构建与验证的最佳实践。Laravel 通过简洁的语法糖、内置的数据过滤和验证机制,显著提升了代码的安全性和可维护性,适用于大型项目或需要快速开发的场景。然而,在追求灵活性的小型项目中,直接使用 PHP 仍是不错的选择。了解两者的优劣,有助于开发者根据项目需求做出最佳决策。
41 0
|
4月前
|
安全 前端开发 PHP
PHP与现代Web开发:构建高效和可扩展的应用程序
【8月更文挑战第29天】在这篇文章中,我们将深入探讨PHP如何适应现代Web开发的需求。我们将通过实际案例分析,揭示PHP的核心优势,并展示如何利用这些优势来构建高性能、可扩展的Web应用。文章不仅提供理论知识,还包括具体的代码示例,旨在帮助开发者更好地理解和运用PHP解决实际问题。
|
4月前
|
SQL 关系型数据库 MySQL
PHP与数据库交互的艺术:深入探讨PDO扩展
【8月更文挑战第28天】在数字信息时代的海洋里,PHP作为一艘灵活的帆船,承载着无数网站和应用的梦想。而PDO扩展,则是这艘帆船上不可或缺的导航仪,指引着数据安全与效率的航向。本文将带你领略PHP与数据库交互的艺术,深入浅出地探索PDO的世界,从连接数据库到执行复杂的查询,每一步都清晰可见。我们将一起航行在这段奇妙的旅程上,解锁数据的奥秘,体验编程的乐趣。
71 1
|
4月前
|
安全 Java 云计算
JSF 应用究竟何去何从?云端部署能否成为其全新突破点?快来一探究竟!
【8月更文挑战第31天】本文介绍了将JavaServer Faces(JSF)应用部署到云平台的过程。首先,根据成本、功能、可靠性和安全性选择合适的云平台。接着,展示了构建简单JSF应用的示例代码。最后,以AWS Elastic Beanstalk为例,详细说明了部署流程。部署至云端可提升应用的可用性、扩展性和安全性。
50 0